WEBVTT

00:00:07.439 --> 00:00:15.639
hi guys um Jensen's gone right um I wanted to ask I want to ask what you

00:00:12.840 --> 00:00:21.560
guys thought of mantel um just to see since you guys are considered luminaries

00:00:17.520 --> 00:00:25.320
and large developers uh what you guys

00:00:21.560 --> 00:00:28.400
think oh you guys start okay I mean I

00:00:25.320 --> 00:00:31.400
know my opinion on it is I in terms of

00:00:28.400 --> 00:00:32.680
action I question Nidia have a response

00:00:31.400 --> 00:00:36.960
to mandle and I think that's unequivocally know they should you know

00:00:35.000 --> 00:00:40.559
it would be I think a horrible mistake if some reason you know somehow NVIDIA

00:00:38.719 --> 00:00:46.600
got panicked by this and made some lower level NVIDIA API you know you already

00:00:43.680 --> 00:00:50.680
have very good low-level access through the the GPU extensions that Nidia has

00:00:48.680 --> 00:00:54.960
always rolled out know ahead of anywhere else give you as much performance as you

00:00:52.960 --> 00:01:01.440
want to trade the inconvenience of doing Invidia proprietary stuff on them now

00:00:58.359 --> 00:01:03.359
mantle is inde AMD has talked many times

00:01:01.440 --> 00:01:08.520
in the past about close to the metal type architectures and it only ever

00:01:06.560 --> 00:01:14.320
became interesting because of their dual console if it was just a way to to do on

00:01:11.400 --> 00:01:19.439
the PC be a little bit more uh you know lower level for them I couldn't have

00:01:15.880 --> 00:01:21.119
cared less I the landscape does matter

00:01:19.439 --> 00:01:25.320
that they have both the major console WIS with a similar architecture that you

00:01:22.799 --> 00:01:30.799
can get on the PC developers will be making systems architectural changes

00:01:27.880 --> 00:01:35.159
that favor those um so I think it it's not a stupid thing

00:01:32.920 --> 00:01:38.920
for AMD to be doing at this point there's some benefits that they can reap

00:01:36.880 --> 00:01:45.600
from it it could have implications for steam steam box type things there um but

00:01:42.759 --> 00:01:50.040
I they're probably if Microsoft and Sony both embraced it that would be very very

00:01:47.799 --> 00:01:53.960
powerful for AMD but it doesn't look like they're going to at least Microsoft

00:01:51.799 --> 00:01:59.840
from the you know words that they're mouthing so I I mean if I was still

00:01:57.320 --> 00:02:05.439
doing all of the you know all of the B major technology coding for I for nextg

00:02:02.960 --> 00:02:09.520
game stuff I probably would not be embracing mantle right now uh but it

00:02:08.200 --> 00:02:13.400
would be there would be days when it would be extremely tempting but when I

00:02:11.720 --> 00:02:17.480
would dispassionately step back and look at it I probably wouldn't come down on

00:02:15.800 --> 00:02:21.319
the side of saying it's it's worth the effort there obviously others come to

00:02:19.519 --> 00:02:27.840
different conclusions sure uh there's some good

00:02:23.720 --> 00:02:30.480
ideas and the we really liked the idea

00:02:27.840 --> 00:02:35.440
of having low level low overhead access to the GPU I mean if you look back at

00:02:32.840 --> 00:02:39.879
what's in both directex and openl there's a lot of overhead in those apis

00:02:37.360 --> 00:02:44.000
and the multiple layers of them and the fact that they date back to you know the

00:02:41.720 --> 00:02:47.959
old STI model of Hardware rendering which is very very different than the

00:02:45.800 --> 00:02:53.159
modern Shader based programming model that we have now you know where you have

00:02:50.000 --> 00:02:54.959
potentially unified memory and a lot of

00:02:53.159 --> 00:02:59.000
processing power available in the GPU and lots of ways of sharing data that go

00:02:56.840 --> 00:03:02.519
beyond just calling a ton of API functions for everything little thing

00:03:00.239 --> 00:03:07.319
you want to do uh so there are good ideas there I hope that uh really helps

00:03:05.599 --> 00:03:11.959
the openg go committee and Microsoft shape their future apis I me if you ask

00:03:10.360 --> 00:03:17.959
me would I much prefer to have a low-level API for accessing the GPU the

00:03:14.640 --> 00:03:20.640
answer is yes but five of them each for

00:03:17.959 --> 00:03:25.519
different uh hardware architectures and vendor and operating systems absolutely

00:03:23.319 --> 00:03:31.000
not that is the wrong direction for the industry to go um and to have yet

00:03:29.000 --> 00:03:35.640
another AP and the PC that's still different than the standard PC DirectX

00:03:33.080 --> 00:03:40.439
API and it's different than the open GL op es that exists on Mac and Android and

00:03:38.879 --> 00:03:44.560
iOS and it's different than the PlayStation 3 PlayStation 4's lowlevel

00:03:43.000 --> 00:03:51.319
rendering API and it's different than what Microsoft provides in Xbox I I

00:03:47.720 --> 00:03:54.879
don't think it's a a good

00:03:51.319 --> 00:03:54.879
idea yeah

00:03:56.799 --> 00:04:01.560
so no one of the key things about it is

00:04:00.079 --> 00:04:06.200
and one of the main reasons we're doing is that it's not a replacement uh

00:04:03.920 --> 00:04:10.799
there's it's not designed that way at all uh the idea is that we we can solve

00:04:09.439 --> 00:04:13.760
some of the long-term problems that we've actually been having on the PCS

00:04:12.599 --> 00:04:19.440
platform all the stuff we've been talking about today of getting robust

00:04:16.400 --> 00:04:21.519
performance consoles type type of of of

00:04:19.440 --> 00:04:25.400
robust stable performance uh those are things we can experiment and work with

00:04:23.720 --> 00:04:30.240
with M we do that with d3d and we do that with GL also of course uh this is

00:04:27.880 --> 00:04:33.600
another Avenue you can see uh it's also really interesting of just essentially

00:04:31.680 --> 00:04:36.440
opening up something that we're quite familiar with already we've been

00:04:34.840 --> 00:04:40.120
spending well essentially last two years working on the nexan consoles and the

00:04:38.240 --> 00:04:46.400
architectures are the same we intimately familiar with with with those architectures and it's a good fit there

00:04:42.919 --> 00:04:48.039
just as as described and I see even

00:04:46.400 --> 00:04:53.320
though we're not done with our work with it and is definitely not not not done

00:04:50.759 --> 00:04:57.280
yet either to be to be shipped out uh I still see it as a as a success even

00:04:55.560 --> 00:05:01.600
right now actually just because of these conversations and the amount of things

00:04:59.240 --> 00:05:06.919
that actually the amount of developments and the amount of sort of both

00:05:04.000 --> 00:05:12.720
enthusiasm and even the opposite of enthusiasm all the type of um it's been

00:05:10.479 --> 00:05:17.199
bit stale you could say in in especially in the PC graphics Microsoft they switch

00:05:14.720 --> 00:05:22.639
Focus for for quite some time over to to other things which they probably really

00:05:19.479 --> 00:05:24.400
didn't need to do uh but I I think now

00:05:22.639 --> 00:05:27.720
going forward it's a really exciting opportunity both on the on the pieces

00:05:26.160 --> 00:05:32.400
basis and stuff we're experimenting with mental and learning on the Souls but

00:05:30.160 --> 00:05:34.919
also mobile as we discussed before of of okay what should be the future Graphics

00:05:33.759 --> 00:05:41.120
pipelines there there's a lot of movement in all of these things and it's it's just good to have lots of different

00:05:38.759 --> 00:05:45.759
Avenues to experiment uh and actually hopefully deliver concrete value uh in

00:05:43.960 --> 00:05:49.680
things but I completely agree with both John and Tim that if NVIDIA would do

00:05:47.880 --> 00:05:54.600
their own API and then Intel would do an API and then qu would do an API that's

00:05:53.000 --> 00:05:59.960
not a future want to be that that would be a bad future uh that would be very

00:05:57.080 --> 00:06:05.280
very a lot of work you mark moft and Kronos does play an important part of

00:06:02.039 --> 00:06:07.880
all of all this and um I hope M will be

00:06:05.280 --> 00:06:11.720
quite influential in in in in many these aspects also and what we're doing right

00:06:09.599 --> 00:06:17.880
now also specifically with with DD is is just a start um thank you yeah you

00:06:15.840 --> 00:06:22.400
you've used the API where we've just read the spe or the marketing materials

00:06:20.160 --> 00:06:26.479
um what would you say is the the two questions what do you think is the cost

00:06:24.280 --> 00:06:29.919
of like in man years or whatever of implementing manal support in

00:06:28.319 --> 00:06:34.199
Battlefield and what do you think it's the ultimate gain on PC like could you

00:06:31.759 --> 00:06:38.440
try to quantify that it it's it is too early to quantify we've been very busy

00:06:36.000 --> 00:06:43.800
just making sure our game works overall and actually sh sh shipping it out we're

00:06:40.759 --> 00:06:45.400
almost done with it uh so it's too early

00:06:43.800 --> 00:06:49.960
to say we'll have a lot more information in November mid November talk more about

00:06:48.120 --> 00:06:54.440
it and it will be interesting to see I think it's important also to one one

00:06:51.880 --> 00:06:57.520
thing that people well General people that are not developers it can be

00:06:56.360 --> 00:07:01.520
difficult to understand that when it comes to bits it's actually it's not not

00:06:59.599 --> 00:07:06.360
like the ball okay we solve this one we're done go home and the game Run as

00:07:03.319 --> 00:07:08.280
well and ball next is like wack you you

00:07:06.360 --> 00:07:12.000
find fix one and then you thought that that was the thing you made that four

00:07:09.680 --> 00:07:16.599
times faster and then the next B shows up after 10% of that Improvement of

00:07:14.840 --> 00:07:21.919
course the biggest issue is that really you have to architect your large scale

00:07:18.479 --> 00:07:23.080
Vision to take maximum Advantage no API

00:07:21.919 --> 00:07:27.440
just all of a sudden really makes a dramatic difference on things because if

00:07:25.479 --> 00:07:31.840
you buil a good game engine to you know to any API even if you magically made

00:07:30.000 --> 00:07:35.360
all that API overhead vanish it doesn't make that much of a difference it's the

00:07:33.800 --> 00:07:39.720
possibility of do I mean there's stuff on the gcns that I'm very excited about

00:07:38.039 --> 00:07:43.759
some of the asynchronous pipeline cues for different things that would be great

00:07:41.240 --> 00:07:48.080
to you know to take direct direct control over but then that's you know

00:07:46.360 --> 00:07:52.720
you either design for that or you don't design for that it will be a gradual

00:07:50.560 --> 00:07:57.599
approach also of sure we're doing Bel before it's not like Bel before is only

00:07:55.440 --> 00:08:01.280
dedicated for a specific API and specific platform it's it's it's it's a

00:07:59.560 --> 00:08:04.919
rich game there you want to work with something and and deliver concrete

00:08:03.319 --> 00:08:08.159
benefits and evaluate and then go forward and and and see where we are and

00:08:06.800 --> 00:08:12.199
hopefully in the future will design games based on many of the concepts that

00:08:10.039 --> 00:08:15.680
we're proving out a lot earlier now than what we can do otherwise and I think

00:08:14.080 --> 00:08:20.560
that that's actually a good change for the entire industry even though people

00:08:17.759 --> 00:08:25.039
sometimes do get stuck up on on like the the overall thing thinking again oh the

00:08:22.759 --> 00:08:28.680
same discussion as I had before of okay is mobile will replace all the PC no

00:08:27.199 --> 00:08:32.599
that's that will not happen same that will not replace all of the ex or all of

00:08:30.319 --> 00:08:36.719
the Y that they're complimentary well actually when use m is not complimentary

00:08:34.519 --> 00:08:41.640
but it's compliment in the in the actual industry over all uh and you want that

00:08:39.839 --> 00:08:46.240
competitiveness not necessarily by having five different apis but having

00:08:43.480 --> 00:08:50.640
movement uh uh I think that's really really interesting cool I thanks I

00:08:48.399 --> 00:08:58.200
appreciate it lot can you tell us tell us how much they pay for you to use

00:08:53.959 --> 00:09:00.680
it actually that's let's let keep

00:08:58.200 --> 00:09:04.880
having no I can answer a couple questions uh they didn't have to pay us

00:09:03.200 --> 00:09:09.640
anything to use it I've been pitching these type of ideas for for many many

00:09:06.800 --> 00:09:14.880
years for every single vendor uh and it's actually talking just about my my

00:09:12.240 --> 00:09:18.720
own egoistic view of solving my own specific problems is that we see a lot

00:09:17.040 --> 00:09:22.200
of stalls we see a lot of performance performance gone missing in many areas

00:09:20.760 --> 00:09:26.680
that we actually want to get at that performance we want to learn how to

00:09:24.079 --> 00:09:30.640
program a a machine on on a on a lower level that that has actually a really

00:09:28.839 --> 00:09:36.399
really good architecture for for that and I think that's something that will

00:09:32.839 --> 00:09:38.399
will sort of roll out going forward also

00:09:36.399 --> 00:09:41.640
okay so it's good as an R&D platform for developers you me with and John you

00:09:40.079 --> 00:09:44.839
were talking about the desire to have front bu for Access or something like

00:09:43.160 --> 00:09:49.640
that lower level API would be more likely to provide that I think it's also

00:09:46.760 --> 00:09:52.959
good if it pushes Microsoft and open go folks to improve their drivers by

00:09:51.519 --> 00:09:57.760
realizing that hey you can actually achieve a lot more performance on PC

00:09:55.399 --> 00:10:00.920
what the more lowlevel techniques um I think it would only be bad if the

00:09:59.360 --> 00:10:07.600
outcome of this is that now we have to deal with five vendor specific apis for

00:10:03.240 --> 00:10:09.839
AG GP yeah and also the vision for for

00:10:07.600 --> 00:10:14.040
mantle well it can play out many ways you don't really you can't really say

00:10:11.480 --> 00:10:18.320
for for sure uh but the vision for mantle is that it will it can become a

00:10:16.959 --> 00:10:23.120
an API also that's something we're completely open for and something is open for also it's just that that's not

00:10:21.519 --> 00:10:27.920
the right way to go at it initially there are those Aven Ed already with

00:10:24.680 --> 00:10:30.040
cronas and with these this is open API

00:10:27.920 --> 00:10:34.560
it wouldn't be a lowlevel well well actually I don't yeah I don't

00:10:32.760 --> 00:10:40.720
fully agree sure you can make an API that's completely down to the level sort

00:10:36.360 --> 00:10:42.200
of what you like on P we worked it was a

00:10:40.720 --> 00:10:48.480
very very thin abstraction now but it was completely specific with that architecture I do think the way modern

00:10:45.360 --> 00:10:52.000
gpus work is is quite different from

00:10:48.480 --> 00:10:53.519
from how the DX or you absolutely the G

00:10:52.000 --> 00:10:57.360
design was from from the beginning there there are extensions at Le in De Land

00:10:55.160 --> 00:11:01.079
where you can access many things but there there are commonalities between

00:10:59.800 --> 00:11:05.360
like binding for example that's an awesome thing that has been working on

00:11:03.480 --> 00:11:09.839
with with with G that is really the future for all GPS and if you ask the

00:11:07.480 --> 00:11:14.160
different vendors uh even people even vendors perhaps on mobile space that do

00:11:11.480 --> 00:11:18.360
not have it yet they believe that is the future well now I'm talking for all

00:11:16.000 --> 00:11:24.200
mobile MERS not but it makes sense as as a modern design

00:11:21.440 --> 00:11:27.680
for that uh and you see some some convergence towards things that are

00:11:26.079 --> 00:11:31.800
generally the designed and then some people are some Des

00:11:29.480 --> 00:11:35.560
will come a little bit later for that but when it's a great fit for for for

00:11:33.959 --> 00:11:39.959
key hardware and it's great fit for developers then I think well that's the

00:11:37.440 --> 00:11:44.480
way will go like my point about unified memory is absolutely here and we really

00:11:41.800 --> 00:11:49.160
need to get get down to gpus are just peers on the same memory pool as the CPU

00:11:47.399 --> 00:11:54.720
and we really need like documented texture layouts and not noticing that

00:11:52.160 --> 00:11:58.639
everything is coming soc's also so even the GPU is a combination of tons of

00:11:57.200 --> 00:12:03.120
different processors a significant amount of process either if it's an bet

00:12:00.959 --> 00:12:07.160
GPU or if it's an mgpu there's quite a lot of quite independent engines there

00:12:05.519 --> 00:12:10.680
and that's something that's hidden from us now the GPU is something that you

00:12:08.920 --> 00:12:14.079
from the CPU you prepare your commands you just give it to them and it has a

00:12:12.760 --> 00:12:18.240
driver that tries to figure out which goes where that's just generally good

00:12:16.440 --> 00:12:20.800
design to expose those things of living if you're trying to do something picky

00:12:19.519 --> 00:12:24.240
like using the hardware video decompression stuff or then you know

00:12:22.639 --> 00:12:30.440
re-encoding there you have to V to forand new API to get that Capt even

00:12:28.320 --> 00:12:34.760
even even like compute for example compute is well one of the best use

00:12:32.680 --> 00:12:41.000
cases compute is for graphics which is kind of uh yeah feels a little bit weird

00:12:38.279 --> 00:12:44.519
but but it's not like you want to use it both tightly coupled with your with your

00:12:43.320 --> 00:12:48.760
graphics and you want to use it completely separately that CPU drives

00:12:47.040 --> 00:12:53.240
for for loading this and stuff and you want to have background tests that that

00:12:50.680 --> 00:12:56.480
have U well can have really highly to see and run in the background and just

00:12:54.519 --> 00:13:00.480
eat up whatever Victor units that are free on your GPU that's also generally

00:12:58.240 --> 00:13:03.920
good design for even in the GPU space I'm hitting on these issues where I want

00:13:01.839 --> 00:13:07.959
GPU task scheduling and we have no concept of prioritization between GPU

00:13:06.079 --> 00:13:12.519
SKS where know we need to be able to specify time slices and priorities and

00:13:10.560 --> 00:13:16.920
you know it's down being a CPU scheduler for a finite re and well like they take

00:13:15.160 --> 00:13:21.519
quite a lot of time until we find a convergence to a a definite model there

00:13:19.880 --> 00:13:24.680
and but in the meantime it's good to have a couple of models both from

00:13:23.079 --> 00:13:29.839
hardware and from software sort of competing or or or being tested there uh

00:13:27.440 --> 00:13:33.519
and see what sort of what's come s that because I do think there will be quite

00:13:31.360 --> 00:13:38.760
interesting conver there's clearly a large map of

00:13:36.079 --> 00:13:45.839
enthusiasm in the panel for gsync um is it thus fair to say that

00:13:42.000 --> 00:13:45.839
you'll be playing the games that you're

00:13:47.480 --> 00:13:50.480
developing

00:13:51.839 --> 00:13:59.480
wow well if NVIDIA they have gsync they

00:13:56.399 --> 00:14:03.480
have I have to say they have the

00:13:59.480 --> 00:14:04.959
you don't you don't have M at all um it

00:14:03.480 --> 00:14:12.320
starts getting a little bit tricky in my view yeah NVIDIA had mantle

00:14:09.199 --> 00:14:13.399
and we had gsync or we had ideally all

00:14:12.320 --> 00:14:17.440
vendors should have alls that would be the best solution

00:14:15.360 --> 00:14:20.320
that the best solution for the industry but I think what you're seeing if you

00:14:18.560 --> 00:14:25.320
look at it from a practic point of view you'll have first mover first mover uh

00:14:22.959 --> 00:14:28.440
advantages for the for the companies that invest r& the effort and I should

00:14:26.959 --> 00:14:37.000
bring something out uh something out there uh so I'll play the game on Clos so

00:14:33.800 --> 00:14:39.160
forious reasons is the GC software side

00:14:37.000 --> 00:14:42.959
of things and Hardware side on the the card is that going to be licensable to

00:14:41.000 --> 00:14:46.240
like our Intel and afd going to be able to yeah we haven't precluded the notion

00:14:44.480 --> 00:14:49.920
of it frankly you know we're first is trying to get it going get the ecosystem

00:14:48.279 --> 00:14:53.720
going get the display guys going we had to change the GPU architectur get it

00:14:51.680 --> 00:15:01.759
going and then every included any in the future that sounds like a softw

00:14:57.680 --> 00:15:05.560
thinking yeah if only that pesky GC had

00:15:01.759 --> 00:15:08.079
thing I'm just kidding I know Tim

00:15:05.560 --> 00:15:12.639
John yeah well we primarily use invid Hardware at and we we buy L of

00:15:13.199 --> 00:15:16.639
it that's

00:15:16.839 --> 00:15:22.199
surprise I've got a light boost monitor on my desktop so I mean it'll probably

00:15:20.839 --> 00:15:28.040
update to it yeah I heard my voice call

00:15:25.279 --> 00:15:31.319
that uh we got the the voice of God over here telling us one more

00:15:39.160 --> 00:15:42.160
question