WEBVTT

00:00:00.120 --> 00:00:07.980
games are going to look better and play better thanks to this new tech powered

00:00:05.400 --> 00:00:12.120
by The Humble SSD that might not make any sense like for years we have been

00:00:10.320 --> 00:00:16.500
saying that storage speed does not matter for gaming but now that

00:00:13.740 --> 00:00:22.439
Microsoft's direct storage API has finally been released to developers that

00:00:19.260 --> 00:00:25.980
changes it's now possible for your GPU

00:00:22.439 --> 00:00:27.420
to load data directly from your SSD and

00:00:25.980 --> 00:00:32.340
it's only a matter of time before games support it but why does it matter where

00:00:30.240 --> 00:00:36.480
your GPU gets its data from and how is this going to make your games better and

00:00:34.739 --> 00:00:41.579
how am I going to load this sponsor segue directly into your brain dot Tech

00:00:38.940 --> 00:00:45.120
last year dot Tech domains gave away a ton of awesome prizes with their break

00:00:43.140 --> 00:00:49.140
the code puzzle contest and this year they're going to take it to a whole new

00:00:46.920 --> 00:00:53.180
level try and break the code to win today using the link down below

00:00:59.780 --> 00:01:04.860
in my opinion direct storage and Sony's

00:01:02.879 --> 00:01:09.299
equivalent have always been underrated because we can't turn it off we can't do

00:01:07.200 --> 00:01:13.799
a side by side to see how much of a difference it makes so it's always been

00:01:11.520 --> 00:01:18.780
this weird nebulous thing that we can't feel you know and now that it's finally

00:01:16.740 --> 00:01:23.640
on the PC we can get some real answers now we don't have games to test right

00:01:21.299 --> 00:01:27.960
now but Microsoft did give us a peek at what it can do first there's a simple

00:01:25.799 --> 00:01:31.860
hello direct storage that's designed to get developers acquainted with the API

00:01:29.700 --> 00:01:35.880
but more importantly there's a Mini Engine model viewer this is intended to

00:01:34.439 --> 00:01:39.900
show developers the difference direct storage can make when loading assets

00:01:37.740 --> 00:01:44.040
with a real world example why don't we have a look for ourselves

00:01:41.340 --> 00:01:48.780
is the model viewer what this lets us do is basically show the difference between

00:01:46.619 --> 00:01:53.759
direct storage and not direct storage so the SE two commands that I'm cycling

00:01:50.579 --> 00:01:56.579
between here have the non-direct storage

00:01:53.759 --> 00:02:00.119
and direct storage versions respectively so let's launch the non-direct storage

00:01:58.560 --> 00:02:05.640
version first and see how long that takes to load

00:02:02.520 --> 00:02:07.560
okay not too bad and we can look around

00:02:05.640 --> 00:02:12.120
it's not a very complicated scene it's actually quite

00:02:09.300 --> 00:02:16.379
uh quite small for what it is it's not like the Unreal Engine 5 demo

00:02:14.819 --> 00:02:21.860
but it is a whole bunch of assets they're

00:02:19.140 --> 00:02:29.180
just loaded in here we can see that took 0.33 seconds for everything to start up

00:02:24.720 --> 00:02:29.180
now let's go with direct storage

00:02:29.340 --> 00:02:37.080
okay you can see the same thing is happening

00:02:32.760 --> 00:02:37.080
here we've got the the same overall

00:02:37.200 --> 00:02:46.019
set of assets and if we get out

00:02:41.780 --> 00:02:48.840
0.08 seconds I cannot overstate how much

00:02:46.019 --> 00:02:57.180
of a difference that is this one little scene just 52.4 Megs uncompressed is

00:02:52.379 --> 00:02:59.459
loading nearly three times faster now

00:02:57.180 --> 00:03:04.980
true we're talking fractions of a second here but expand that out to hundreds of

00:03:01.920 --> 00:03:07.560
Megs even multiple gigs of assets loaded

00:03:04.980 --> 00:03:14.040
by modern games and that's a lot of time saved but now I have two questions first

00:03:11.280 --> 00:03:18.599
how does it save so much time on the same hardware and second how will it

00:03:16.560 --> 00:03:22.019
scale with those more detailed game environments in order to understand

00:03:20.400 --> 00:03:26.280
what's going on here we have to understand how assets are loaded into

00:03:23.640 --> 00:03:30.780
video memory the reality on PC up until today has been that the asset is first

00:03:28.140 --> 00:03:35.099
read from Storage to the CPU then Place into system memory your RAM from there

00:03:32.819 --> 00:03:39.300
it's copied through the CPU again to the GPU now this sounds like a roundabout

00:03:37.200 --> 00:03:43.560
process and as we've seen in our demo it definitely slows things down but up

00:03:41.580 --> 00:03:47.159
until the mid-2000s this wasn't a major issue because you'd usually load

00:03:45.299 --> 00:03:51.900
everything you needed all at once what changed streaming assets as open worlds

00:03:49.920 --> 00:03:56.640
became larger and as consoles available video memory shrank in comparison to PCS

00:03:54.360 --> 00:04:00.780
it became increasingly common to need to use more textures and 3D models than

00:03:58.739 --> 00:04:05.340
could be held in memory at once this was foreseen as early as 2001 when Sony

00:04:03.239 --> 00:04:08.819
filed a patent to seamlessly load game worlds as boundaries are crossed

00:04:07.200 --> 00:04:12.180
eliminating the need for reloading screens fast forward to today and

00:04:10.739 --> 00:04:16.560
loading screens are seen as an unnecessary inconvenience in an age

00:04:14.040 --> 00:04:21.060
where seamless asset streaming is the norm you usually only see the first one

00:04:18.660 --> 00:04:24.840
and then again when you die or when you fast travel ever notice how today's

00:04:22.800 --> 00:04:29.040
games connect areas with elevators or tunnels or hallways yeah that's why

00:04:27.360 --> 00:04:32.580
there have been attempts to help with this over the years compression was one

00:04:30.960 --> 00:04:36.600
of the first such Concepts introduced and in fact one of the earliest methods

00:04:34.380 --> 00:04:40.080
is still in use today prior to that you had to either shrink the dimensions or

00:04:38.460 --> 00:04:43.860
use a color map to reduce the memory footprint of textures and after its

00:04:42.300 --> 00:04:48.780
introduction and adoption by the industry it enabled larger more detailed

00:04:46.500 --> 00:04:52.680
assets to be loaded more quickly even if they still had to be copied from the CPU

00:04:50.400 --> 00:04:57.900
to the GPU compression paved the way for graphics to LEAP out of the crunchy 90s

00:04:54.900 --> 00:04:59.880
visuals and into Brown muddy 2000s

00:04:57.900 --> 00:05:03.540
visuals hey it was good for the time it also paved the way for another attempt

00:05:01.380 --> 00:05:07.620
to improve performance this time in the same way that direct storage does by

00:05:05.460 --> 00:05:11.639
cutting the CPU out as much as possible texture atlases effectively rounded up

00:05:09.960 --> 00:05:15.540
all the little textures a scene would need and then plopped them into one

00:05:13.500 --> 00:05:18.540
giant texture the end result being a dramatic reduction in the number of

00:05:16.800 --> 00:05:23.100
textures that needed to be copied to the GPU and more importantly for the time

00:05:21.000 --> 00:05:26.639
the number of draw calls that had to be made sounds like a great solution what

00:05:25.199 --> 00:05:32.160
do we need direct store search for him all right well texture atlases have some

00:05:29.520 --> 00:05:35.820
drawbacks you can't tile them colors will blend together around the edges of

00:05:33.720 --> 00:05:40.199
each subtexture in the atlas and perhaps most importantly swapping one or two

00:05:38.340 --> 00:05:44.880
individual textures requires swapping out the whole Atlas which is really

00:05:42.960 --> 00:05:49.020
inefficient since they're so big the nail in the coffin texture atlases were

00:05:47.400 --> 00:05:53.520
becoming a thing around the same time that streaming assets became popular

00:05:51.300 --> 00:05:58.139
talk about bad timing direct storage solves all of those problems it allows

00:05:56.520 --> 00:06:02.400
the GPU to read directly from Storage without any intervention for the CPU

00:06:00.000 --> 00:06:07.320
meaning that an entire copy step is just being removed from the pipeline for each

00:06:04.440 --> 00:06:11.759
and every asset loaded this way which as we've seen leads to a significant

00:06:09.360 --> 00:06:16.080
reduction in load times that means that not only can game worlds be larger and

00:06:14.100 --> 00:06:20.280
more detailed with shorter or even no loading hallways but you won't need a

00:06:18.479 --> 00:06:24.300
massive GPU for it either since lower end gpus with less vram will be able to

00:06:22.440 --> 00:06:28.319
swap Assets in and out more efficiently I can see game engines becoming more

00:06:26.580 --> 00:06:32.280
aggressive in terms of how they tweak asset streaming according to available

00:06:29.639 --> 00:06:36.600
vram how maximize the effect and I could see you in a swaget from ltdstore.com

00:06:34.440 --> 00:06:39.600
seriously it's comfortable for most of the year and doesn't look half bad

00:06:37.860 --> 00:06:45.180
either but what about our second question will direct storage scale for

00:06:42.479 --> 00:06:50.639
larger assets well for it to be able to the GPU first needs to fetch the assets

00:06:47.639 --> 00:06:53.940
and decompress them this is a problem

00:06:50.639 --> 00:06:56.460
well yes I said before that gpus support

00:06:53.940 --> 00:07:02.400
compressed assets this is a different type of compression with games being as

00:06:59.699 --> 00:07:06.900
massive as they are assets are typically stuffed into giant compressed archives

00:07:04.620 --> 00:07:11.160
to save space and for more efficient distribution prior to direct storage the

00:07:09.060 --> 00:07:15.000
CPU handle all of this and that was fine because it was all going through the CPU

00:07:12.600 --> 00:07:18.720
anyway unfortunately direct storage in its current form doesn't include a way

00:07:16.680 --> 00:07:23.460
for the GPU to do that decompression at least not on PC but it is possible

00:07:21.440 --> 00:07:28.380
NVIDIA has something similar to how Sony's dedicated PS5 Hardware handles

00:07:25.680 --> 00:07:32.520
this which they call rtxio when it's enabled decompression via custom hard

00:07:30.240 --> 00:07:38.220
Hardware Via the GPU itself will be significantly faster than it is via the

00:07:34.919 --> 00:07:40.680
CPU at all full stop and as a bonus it's

00:07:38.220 --> 00:07:44.460
decompressed straight to video memory so that performance boost we saw earlier

00:07:42.360 --> 00:07:49.259
will be Amplified because we're skipping two steps instead of just one but as

00:07:47.340 --> 00:07:53.460
long as data has to pass through the CPU direct storage won't be super useful

00:07:51.300 --> 00:07:57.240
Microsoft says that fixing this is a priority so hopefully we'll see it

00:07:55.020 --> 00:08:02.880
before games go live the alternative is games that ship with uncompressed assets

00:07:59.880 --> 00:08:05.880
which I mean with how big Call of Duty

00:08:02.880 --> 00:08:08.340
has gotten with compression I sure hope

00:08:05.880 --> 00:08:12.780
you got a big SSD why is it taking so long though Microsoft has had Direct

00:08:10.080 --> 00:08:18.419
storage on Xbox for ages now and we're still getting table scraps on PC well

00:08:15.900 --> 00:08:22.139
it's easier to implement a brand new API like this on a fixed platform that you

00:08:20.460 --> 00:08:25.800
can control both the hardware and operating system for and consoles are

00:08:24.240 --> 00:08:30.300
usually the platforms with the greatest initial lead asset streaming for example

00:08:28.500 --> 00:08:34.440
was to my recollection anyway for seriously explored on consoles at a time

00:08:32.700 --> 00:08:39.539
when the available vram compared to contemporary PCS was laughable

00:08:37.500 --> 00:08:43.800
regardless it was a problem at the end of every generation since then and even

00:08:41.940 --> 00:08:48.899
the 8 to 10 gigs of memory that the Xbox series is and the PS5 have is going to

00:08:46.680 --> 00:08:53.700
seem extremely Limited in five to ten years to stay relevant for longer than

00:08:50.820 --> 00:08:57.959
the Xbox One and PS4 did they need tech like direct storage that will offer game

00:08:55.740 --> 00:09:03.120
developers the flexibility they need to crank up the visual Fidelity or create

00:09:00.000 --> 00:09:04.920
ever more sprawling open worlds We crave

00:09:03.120 --> 00:09:10.320
supporting direct storage on both Windows 10 and 11 is also no easy feat

00:09:07.620 --> 00:09:13.800
but Microsoft says that Windows 11 will work better thanks to enhancements to

00:09:11.880 --> 00:09:17.040
the storage subsystem something that we're going to have to test in more

00:09:15.060 --> 00:09:21.779
detail when games get released get subscribed so you don't miss that by the

00:09:18.540 --> 00:09:23.459
way and that's really it it'll be a

00:09:21.779 --> 00:09:28.260
while yet before we see games coming out with support on PC but it's getting

00:09:25.320 --> 00:09:33.420
really close you guys and when it does finally drop it's legit going to change

00:09:31.080 --> 00:09:37.860
the way the games are made won't change my sponsor Segways though NZXT their new

00:09:36.360 --> 00:09:41.339
function mechanical keyboards are perfect for those looking to join the

00:09:39.600 --> 00:09:45.899
mechanical keyboard Community you can choose between mini 10 keyless 10

00:09:43.440 --> 00:09:50.339
keyless and full size models all the keyboards come with hot swappable switch

00:09:47.700 --> 00:09:55.500
sockets a detachable USBC keyboard cable and per key RGB plus they're rated for

00:09:53.399 --> 00:09:58.920
up to 50 million key presses the NZXT function retail keyboards come with the

00:09:57.300 --> 00:10:03.480
option of white or black colors with gadaron red key switches but countries

00:10:01.080 --> 00:10:07.019
with NZXT build can choose from five different kinds of switches and a

00:10:05.279 --> 00:10:11.279
variety of color options for a custom look to match your desk learn more and

00:10:09.420 --> 00:10:15.300
purchase your own NZXT function keyboard using the link below thanks for watching

00:10:13.800 --> 00:10:19.440
guys go check out our recent video on the Radeon Pro SSG for an earlier

00:10:17.459 --> 00:10:24.800
approach to this kind of thing different purpose and didn't quite catch on but

00:10:21.360 --> 00:10:24.800
hey you never know what the future holds