Huddy: "Make the API go away" [Edit: He wants a lower level API available too.]

[fellix]

Farewell to DirectX? (http://www.bit-tech.net/hardware/graphics/2011/03/16/farewell-to-directx/1)
Despite what delusional forum chimps might tell you, we all know that the graphics hardware inside today's consoles looks like a meek albino gerbil compared with the healthy tiger you can get in a PC. Compare the GeForce GTX 580's count of 512 stream processors with the weedy 48 units found in the Xbox 360's Xenos GPU, not to mention the ageing GeForce 7-series architecture found inside the PS3.

It seems pretty amazing, then, that while PC games often look better than their console equivalents, they still don't beat console graphics into the ground. A part of this is undoubtedly down to the fact that many games are primarily developed for consoles and then ported over to the PC. However, according to AMD, this could potentially change if PC games developers were able to program PC hardware directly at a low-level, rather than having to go through an API, such as DirectX.

[digitalwanderer]

Uhm, no.

[Arwin]

What a great, insightful article and very relevant to several ongoing discussions here ...

[willardjuice]

It's probably in AMD's best interest that API's like Direct3D and OpenGL/OpenCL stay around.

[gkar1]

Not really. AMD already offers a complete platform (CPU+GPU) and has been for years. Customizing apps to their platform without having to go through generic API layers would be incredibly beneficial. Nvidia has already subverted the transparency an API was supposed to bring by paying cash to developers/publishers to tailor apps to their hardware. Why are people suddenly offended when AMD thinks of taking the next logical step? I even recall many people say AMD should at least do the same as Nvidia's TWIMTBP, why the about face now?

[eastmen]

Not really. AMD already offers a complete platform (CPU+GPU) and has been for years. Customizing apps to their platform without having to go through generic API layers would be incredibly beneficial. Nvidia has already subverted the transparency an API was supposed to bring by paying cash to developers/publishers to tailor apps to their hardware. Why are people suddenly offended when AMD thinks of taking the next logical step? I even recall many people say AMD should at least do the same as Nvidia's TWIMTBP, why the about face now?

I remember the early days of hell dude. when 3dfx had glide , nvidia had something , there were software renderers , power vr had something else . It was nuts and so many things didn't work.

I will take a single api with nvidia and amd both playing fair for the most part

[willardjuice]

Why are people suddenly offended when AMD thinks of taking the next logical step?

I'm not offended, but what makes you think AMD will suddenly release a competitive environment for software developers (compared to Intel or Nvidia)? I think one of AMD's major weaknesses is their development tools. API's like Direct3D and OpenGL/OpenCL mitigate that weakness.

To better illustrate what I mean, what's essentially the only reason to use OpenCL over CUDA? The reason is clearly to reach a larger audience (i.e. not be limited with one vendor's hardware). But if your target audience only has Nvidia hardware, you'd be crazy to pick OpenCL (even with the extensions Nvidia has released for it) over CUDA. Do you think that AMD could realistically create and maintain an API competitive to CUDA? In my opinion, "OpenCL with extensions" hasn't been a great answer from AMD (at least for the time being).

I also want to make clear that this doesn't mean I think OpenCL is useless (quite the opposite). It just means that if things become a war of vendor-specific API's, I'm not betting on AMD.

[repi]

I've been pushing for this for years in discussions with all the IHVs; to get lower and lower level control over the GPU resources, to get rid of the serial & intrinsic driver bottleneck, enable the GPU to setup work for itself as well as tear down both the logic CPU/GPU latency barrier in WDDM and the physical PCI-E latency barrier to enable true heterogeneous low-latency computing. This needs to be done through both proprietary and standard means over many years going forward.

I'm glad Huddy goes out and in public talks about it as well, he get's it! And about time that an IHV talks about this.

This is the inevitable, and not too far, future and it will be the true paradigm shift on the PC that will see entire new SW ecosystems being built up with tools, middleware, engines and games themselves differentiating in a way not possible at all now.

- Will benefit consumers with more interesting experiences & cheaper hardware (more performance/buck).

- Will benefit developers by empowering unique creative & technical visions and with higher performance (more of everything).

- Will benefit hardware vendors with being able to focus on good core hardware instead of differentiating through software as well as finally releasing them and us from the shackles of the Microsoft 3 year OS release schedule where new driver/SW/HW functionality "may" get in.


This is something I've been thinking about and discussing with all parties (& some fellow gamedevs) on different levels & aspects of over a long period of time, should really write together a more proper blog post going into details soon. This is just a quick half-rant reply (sorry)

The best graphics driver is no graphics driver.

[gkar1]

I remember the early days of hell dude. when 3dfx had glide , nvidia had something , there were software renderers , power vr had something else . It was nuts and so many things didn't work.

I will take a single api with nvidia and amd both playing fair for the most part
I remember quite well.
The issue is there is no playing fair anymore when all an IHV has to do is pay a developer or publisher to subvert the supposed transparency an API brings to tailor the app to their hardware. Things were a lot more messy back then because no one offered a complete platform to consumers. In fact one of the more successful players SGI made it work by offering complete platforms. Incidentally out of them (a complete platform vendor) came one of the most popular APIs of all time: OpenGL.

[nAo]

Devs and IHVs here might work together for a common goal but they might be doing it for *very* different reasons :cool:

[Andrew Lauritzen]

I agree with the need for such an API and have been hearing the same request from other developers as well.

It's not totally clear though what level of forwards/backwards compatibility is required in practice by game developers. Obviously having every SKU require a custom path isn't going to be acceptable, but maybe each hardware generation? Sucks a bit for gamers who upgrade their GPUs though and now the game doesn't run... Fundamentally the "legacy" cost has to be paid somewhere. This-generation consoles have simply ignored the problem (somewhat laughably and to a significant amount of complaint), but it's not clear that's acceptable on PCs.

[nAo]

"Be careful what you wish for, you might get it"

[madyasiwi]

I guess they could've just grab linux kernel and tailor it to let games access the hardware via ultra thin API.
Developers could then ship their games on a bootable medium containing both the OS and the game.

Boot & play! :smile:

[DeanoC]

In terms of performance its the right answer, however in terms of development cost and resources its a different matter. Abstraction are designed to trade performance for ease, its why we don't code everything in ASM and why we have OS and drivers.

But different hardware paths is something most games and engines are used to, we already have 3 or more so adding a few more isn't that much more work *assuming* their is the backup from the IHVs themselves. Its also something we have dealt with through the game development era, its has not been uncommon to have had to support many more hardware platforms than the 2 or 3 we would be talking about now.

Legacy issues are a 'solved' problem, as used on all the consoles and indeed on PC for older games; emulation. Already PS2, Xbox, DOS, Glide, N64, etc. are all supported using emulation tech and with the open specification required for low level implementations this would be considerably easier.

We currently have 3 paths in our PC renderer (OpenGL), Intel, AMD and NVIDIA. Currently the majority of that code is shared, with perhaps 20% (numbers out my arse so rely on them as such), we also have two completely custom render paths for PS3 and 360, if there was the potential (and appropriate cost/benefits) we could add two paths for high end AMD and NVIDIA parts (say AMD 5x00 6x00 and Fermi based NV).
As each chip family share a lot of register level similarities, its not hard to follow the small differences that appears.

To make that work, we would want a micro-code compiler for shaders (takes some high-level language and produce microcode). Spec level descriptions or a low level API for the base platform with descriptions of the changes over the lifetime including access to changes well before new variants appear (we would need seeds of new cards and specs at the same time as the internal driver teams, to produce patches before a new chip is released).

Its often said to be similar to writing your own driver, but this just isn't true. Drivers are hard because they have to support lots of apps they can't change. When your in control of the app as well, you only need to support the bits you use, which is often quite a small subset.

Its hopefully obvious that it will cost more than supporting higher level API and if it doesn't increase income, thats less profit from the PC side of the game.
So how would we recoup the cost?

Make PC games the same price as Console titles (they typically sell for $10-20 cheaper), but this could be argued as a high end game tax on the lower end gamers.
It perhaps could be offset by more sales, would more gamers buy PC titles if they were noticeable better than now and the console editions? Without hard facts its hard to know, it brings in the questions of DRM, piracy, how many PC gamers etc. We know some PC titles do brilliantly well (BF2 and 3 do/will do amazing numbers on PC) whats harder to tell is whether they do well on PC because they show the love they do for it or vice versa.
Paid DLC is another options - would high end gamers pay $10 for a high end pack?
IHV subsidy?
Loss leader- contrary to many forumites beliefs PC is a loved platform among many developers, PC version often exist as loss leaders for the consoles. Higher res etc. make nicer screen shots and generate a lot of hype (BF3 videos are the perfect examples at this time), the PR benefits are often able to recoup the costs of investing in the high end PC version.


Another point, maybe that we have no choice?
The wheel of reincarnation is spinning and what was once SW then HW is swinging back to SW, we might have no choice but to write everything again in SW and then the GPU just becomes another supported platform as it compiler, OS, CPU etc. at the moment.

Obviously this is just a discussion... we don't have the option at the moment but its an interesting thought if we did.

[GZ007]

The question is rather why do they need performance when thats the easyest way to increase with next generation graphics cards and procesors. :?: (Imagine 6850 or gtx460 on 28nm. :wink:)
PC was always about brute force with all the hardware around it. On top of that hardware vendors dont care about piracy as software developers.

[Arwin]

The question is rather why do they need performance when thats the easyest way to increase with next generation graphics cards and procesors. :?: (Imagine 6850 or gtx460 on 28nm. :wink:)
PC was always about brute force with all the hardware around it. On top of that hardware vendors dont care about piracy as software developers.

Perhaps, but having a hot, power hungry PC with a blood-thirsty, noisy graphics card only to see it being used at about 10% efficiency versus consoles is kind of, well, pathetic. Note that my PC is not power-hungry by any means: I have a quad core PC with 4Gb of RAM and 5570 with 1GB of RAM, but I have yet to find a game that runs better than on a console even with the same resolutions. Sure, sometimes I can run at a higher resolution and/or higher textures, but the framerates keep sucking.

So yeah, this topic has me interested, as it explains a lot.

[GZ007]

Perhaps, but having a hot, power hungry PC with a blood-thirsty, noisy graphics card only to see it being used at about 10% efficiency versus consoles is kind of, well, pathetic. Note that my PC is not power-hungry by any means: I have a quad core PC with 4Gb of RAM and 5570 with 1GB of RAM, but I have yet to find a game that runs better than on a console even with the same resolutions. Sure, sometimes I can run at a higher resolution and/or higher textures, but the framerates keep sucking.

So yeah, this topic has me interested, as it explains a lot.

I think no low level voodoo magic will help your 5570 to turn into console killer. :razz:

[DeanoC]

PC was always about brute force with all the hardware around it.

No it wasn't, most consider the golden age of PC development, between Doom and say Quake 3. And in the era that code extracted massive performance out of the hardware, from software tricks (like perspective division every 16 pixels) to driving 3DFX via glide or mini-GL and other via custom APIs.

Indeed in some-ways this suggestion that Richard has brought up, is just going BACK to the golden days of PC gaming. Multiple HW specific APIs, to the metal level coding (can you imagine anybody on PC today, hand pipelining as the Pentium required?)

The question is why that level of care for PC has reduced?
Is its simply to the metal access or is it financial?

[GMâ„¢]

Seriously, is it April 1st already?

The DirectX API has its limitations, but AMD/ATI owes a great deal of their recent success to its prevalence.

If this was ever to happen then NVIDIA and quite possibly Intel will be all over AMD. NVIDIA has the track record with API development and support and as underhand as NVIDIA can be they have brought TWIMTBP, PhysX/APEX, CUDA and OptiX, SceniX, CompleX related technologies to the market and provided many developers an extraordinary amount of support where required. Look at the latest Unreal tech demo of evidence of what they achieve. AMD would also need to be very careful of Intel as it has significant resources and could quite easily reignite Larrabee development any time it chooses and come up with their own competing system.

From recent experience AMD struggle to bring anything to the table in regards to OpenCL or anything quite as substantial as CUDA, they are all mouth and no action. They design beautiful hardware though, no criticism there. How about AMD backup their claims and release a tech demo showing what can be achieved on current hardware?... but please nothing like the last one, that was just embarrassing.

[Arwin]

I think no low level voodoo magic will help your 5570 to turn into console killer. :razz:

Maybe not, but why is parity even too much to ask?

[GZ007]

The question is why that level of care for PC has reduced?
Is its simply to the metal access or is it financial?

Maybe because graphics is not everything ? Maybe because u dont to the metal access for a game to be good. ?

And in my opinion graphics and graphics is quite relative. The things that Huddy says about the games that should look 10 times better is nonsense. A lot of these days depends on things like animation, graphics art and so on. And on consoles there are much higher budget games with some of the most talented artist out there.
Check out the latest AMD tech demo. Its dx11 and it looks like a piece of shit. No low level acess to the hardware would made that demo look better.

[Scott_Arm]

I thought the 360 was DirectX, basically, but allowed some lower-level manipulation of the hardware? Not sure I'd want to see the APIs completely disappear. I'm sure the IHVs don't like the current situation because it's hard to differentiate their products from the competition when the performance and support is relatively equal because of the APIs. Not sure I want to see the PC space turn into console space, where you have games that are written for AMD, and not Nvidia, or vice versa, where backwards compatibility is an issue because of drastic changes to the hardware in each generation of the product

Edit: The only way I can see this type of thing working is by having some sophisticated sandboxing in the OS, where if your game crashes you're protected from locking up your OS. Not that games can't lock up your OS already.

[Arwin]

I think DirectX will never go away, why would it? An abstraction layer is always nice to have, and will always be useful.

However, the question is whether developers should be allowed to optimise on a higher level.

The biggest question is - can Microsoft ever allow this, especially now that Windows itself also uses the GPU for more and more tasks in the Desktop, even in the browser. Can something like that ever reliably work in combination with a game doing more low-level things? I'm guessing that could get pretty complicated.

[DeanoC]

A lot of these days depends on things like animation, graphics art and so on. And on consoles there are much higher budget games with some of the most talented artist out there.
And every piece of art and animation you see, is controlled by the speed we can render things at. Make no doubt every game I've worked on has looked better before we had to trim back to hit performance targets, not going to change in the next generation (and by generation I meant the original version of 25 years!)

We don't have separate teams for consoles, u do know that, right? Its the same budget and artists on the PC or PS3 or X360 version. No-one is crazy enough (I think) to suggest having separate teams making consoles and PC version of the games (except for a few rare cases where other factors have come into play).

Thats said the correct thing to ask, is if simply increasing the performance of the engine would be that usable without an increase in art budget as well? Thats is a completely valid concern about the idea.

[Malo]

To me the unfortunate thing is that if API's went away, eventually most games would be Nvidia only, the party most willing to make sure developers coded only for their hardware. Rather than seeing small differences, like MSAA support or PhysX addons, we'll have complete lack of support for any other vendor. It wouldn't happen immediately but it would be a gradual process that would exponentially tip the balance as more and more publishers take the cash.

[DeanoC]

Maybe because graphics is not everything ? Maybe because u dont to the metal access for a game to be good. ?

Of course you don't need to the metal for the game to be good!

But what games can't be made right now that are possible with the power you have in a modern PC?

If your game design requires 100,000 enemies on screen, you don't make it right now. So yes graphics do affect game play, never underestimate the power the primary interface into the game world has on the game itself.

Graphics are literally your window into the game world. Many games are possible right now, but some aren't and want/need a better window.

[Silent_Buddha]

Here's the question I have. We all realize that lower level access to the hardware would be a win in terms of performance and flexibility, no?

However, lower level access also increases the likelihood of system level crashes from badly written code like back in the early days of PC gaming, DOS - Win9x era. It's extremely rare in this day and age for a game to take down your OS due to the relatively high level of abstraction.

When MS moved to consolidate Windows (consumer and enterprise) on the NT kernel, they also further abstracted the graphics API (compared to Win9x) in order to enhance system stability.

How likely is it then that MS would relent and allow more "to the metal" level of access to the graphics hardware in a system? Or am I looking at this incorrectly and we're not actually discussing getting closer to the metal from an OS perspective?

I fully trust that good developers are far less likely to have code that isn't tested against a broad set of hardware configurations and thus likelihood of a system level crash would be rare for them. However, software releases for the past 2 decades don't engender much hope that all developers are so diligent. :p

Regards,
SB

[Mintmaster]

Anyone remember how Dave was saying that some games were "front end" limited on ATI cards compared to NVidia? I assumed that it was geometry, given the resolution scaling and tessellation tests we've seen, but it always seemed like it wasn't a good enough explanation given the 69xx's doubled geometry throughput and limited use of tessellation in games aside from HAWX2.

Now it looks pretty clear to me that NVidia's superiority for most games lies not in their caches, shader architecture, tessellation, etc., but rather in their ability to handle state changes:
On consoles, you can draw maybe 10,000 or 20,000 chunks of geometry in a frame, and you can do that at 30-60fps. On a PC, you can't typically draw more than 2-3,000 without getting into trouble with performance, and that's quite surprising - the PC can actually show you only a tenth of the performance if you need a separate batch for each draw call.What's more is that even with their experience from Xenos, ATI can't combat this problem on the PC. Somehow DX compliance is the issue.

It's quite surprising to me. We have multiple cores giving the GPU plenty of compute power to power drivers. We have GPUs buffering frames so that they can do whatever processing they feel like on the command buffer to reduce batch count. How exactly is DX holding them back and not NVidia?

[homerdog]

*Noob question* Why is the PC so limited with draw calls in comparison to consoles?

[Rodéric]

*Noob question* Why is the PC so limited with draw calls in comparison to consoles?

Because of D3D9 API.
(OpenGL never had the problem, D3D10+ don't have the problem that much either.)

"What is my limit on draw calls for D3D10 to reach 60 Hz? 30 Hz?

Direct3D 9 had a limitation on the number of draw calls because of the CPU cost per draw call. On Direct3D 10, the cost of each draw call has been reduced. However, there is no longer a definite correlation between draw calls and frame rates. Because draw calls often require many support calls ( constant buffer updates, texture bindings, state setting, and so on) the frame rate impact of the API is now more dependent on the overall API usage as opposed to simply draw call counts."
Source : http://msdn.microsoft.com/en-us/library/ee416643(v=vs.85).aspx

Basically you have a lot of validation done in D3D9 draw calls, less so in D3D10 because the API is better (and validation is spread in relevant calls), on consoles you don't have any validation. (It's all do it yourself.)

[Andrew Lauritzen]

Now it looks pretty clear to me that NVidia's superiority for most games lies not in their caches, shader architecture, tessellation, etc., but rather in their ability to handle state changes:
That's quite possible, but ironically it's the other way around for the CPU overhead of state changes in my experience (NVIDIA's is much higher than AMD's in DirectX). The key point here is that the API tries to abstract over something which is highly non-uniform... namely the set of "expensive" vs "cheap" state for a given piece of hardware. That's yet another reason to expose that to the developers who want the best performance.

Because of D3D9 API.
(OpenGL never had the problem, D3D10+ don't have the problem that much either.)
Yes the overhead is less in D3D10+ and OpenGL, but it's still quite large compared to consoles. Try rendering 10k batches where you change the texture (or similar) between each one even in OpenGL ;) In Windows, the operating system owns the graphics memory, so at some level there are expensive APIs that need to be called to make sure that everything is in place for rendering.

It's worth noting that obviously some of this overhead is necessary to make a multi-tasking OS work at all (you can't run two games at once on consoles!), but a lot of it is unnecessary if game developers were willing to structure their code like they do for consoles - managing their own versioning and dependencies and so on. That stuff is more efficient for the game to do, whereas on PC right now it tries to reconstruct it all from your DX/GL command stream on the fly.

[homerdog]

Thanks guys.

[DarthShader]

Yes the overhead is less in D3D10+ and OpenGL, but it's still quite large compared to consoles.
What about DX11 multithreaded rendering? AFAIK it would have to be first introduced in the graphic drivers of both vendors though.

[Scott_Arm]

Could the future be to segment GPU memory, like system memory, and have an OS thread that runs in fixed memory, protected by the OS, through a driver and APIs? That way you could split the GPU to operate with complete freedom in a large chunk of the memory while reserving a finite portion for the OS for stability?

[DeanoC]

What about DX11 multithreaded rendering? AFAIK it would have to be first introduced in the graphic drivers of both vendors though.

The implementation has not shown if its amenable to good near linear scaling yet but at best that gives you, N x speed up, where N is the number of cores.

The command buffer support was/is the bigger hope for dramatic speed up, but the choice to go without fixups (even the 360s slightly odd implementation would have been better than none at all), was a serious mistake imho and makes it only useful as a display list system which isn't enough for serious usage.

[doob]

So, do you think multithreaded rendering support and the command buffer feature will come forth and materialize or will it remain on the wishfull thinking until the next directX revision?

[digitalwanderer]

Dumb question, but I was actually thinking about this thread a lot today...

Could this be why AMD is gearing up their development team? I've seen some ads lately for software developers for 'em...

[Andrew Lauritzen]

So, do you think multithreaded rendering support and the command buffer feature will come forth and materialize or will it remain on the wishfull thinking until the next directX revision?
Depends what you mean. Drivers will support the multithreaded rendering stuff in DX11 soon enough but as DeanoC noted, that's not addressing the base problem. That's at best distributing the slow code over 2-4 cores, not fixing the slowness.

"Command buffer feature" is much more nebulous... to truly extract the performance that people get on the consoles from directly addressing command buffers you need to write hardware-specific code, and thus you sacrifice portability. I'd argue that at least the top tier games can handle a few more paths on PC consider what they already do on consoles (and no one is arguing that we eliminate the higher-level layers), but that's what this thread is about :)

[Graham]

I suspect he actually isn't too concerned about competing with the 360 and PS3 - I'd bet he has his sights set firmly on competing with the next generation of consoles.

[madyasiwi]

Or... take benefit from the next generation console, if it happen to be equipped with their hardware.

[Rangers]

It seems pretty amazing, then, that while PC games often look better than their console equivalents, they still don't beat console graphics into the ground. A part of this is undoubtedly down to the fact that many games are primarily developed for consoles and then ported over to the PC. However, according to AMD, this could potentially change if PC games developers were able to program PC hardware directly at a low-level, rather than having to go through an API, such as DirectX.

The whole premise is wrong. PC titles dont look similar to console ones because of direct x, but because they're console ports. Unless I'm missing something, lack of an API wont change that at all.

Surprised Huddy would say something so obviously off track.

[AlexV]

The whole premise is wrong. PC titles dont look similar to console ones because of direct x, but because they're console ports. Unless I'm missing something, lack of an API wont change that at all.

Surprised Huddy would say something so obviously off track.

Well, I'm guessing his answers were tailored to fit the potential target audience, which may not have been all that interested into a deeper discussion as to what devs are apparently asking for/what a thinning of DX will involve. Luckily for everyone, I think I know a site where the target audience would be interested in something like that, hmm...

[Bouncing Zabaglione Bros.]

I just can't see us going back to the days when programmers had to hit the hardware for every possible piece of gear in someone's PC. Doesn't anyone remember GLide when the reality was that whoever paid the bucks got decent support for their hardware, and everyone else got the minimum?

Today with a couple of big players and marketing money involved, we'd very quickly get to the nightmare scenario for us customers where one company's hardware gets optimised and extra fries with everything, and the other company gets an inferior product, sometimes even deliberately crippled.

Would game devs even want to have to hit the hardware nowadays, given the huge amount of gear out there, in weird configurations or frankensteined drivers? Would Nvidia or AMD give out the low-level information required, or just provide some kind of low level API to get closer to, but not directly hitting on the card? And how would that help if you can't do anything about the OS layers that sit around a graphics card driver, that were put there for stability in the first place?

It all seems really pie-in-the-sky stuff that sound great in principle, but is full of the same real-world problems that caused API's like Direct X to be needed (and be very successful) in the first place. The reasons for the rise, use, and need of DirectX haven't gone away.

[Scott_Arm]

Would the lack of an API slow the the release cycle for new hardware?

[frogblast]

Would the lack of an API slow the the release cycle for new hardware?

It would take a lot longer to ship a new GPU. One thing most people don't consider about what goes on inside a GPU driver: workarounds. Just about every GPU that has ever shipped has multiple hardware bugs when it goes to market. But, with a driver between the application and hardware, you get a second chance to make things right without having to spin the chip, forcing a delay of many months.

Without a driver in the way, you end up developing GPUs like CPUs: perfection, or very very close to it. This comes at a huge cost in both QA time and additional silicon revisions. You should expect a GPU without a driver take significantly longer to bring to market than one with a driver (easily a year or more).

Console developers don't have this problem. Their GPUs have bugs too, but those bugs don't change every 6 months. They just learn "don't do that", and get on with their lives.

[green.pixel]

Can we get back to the Amiga days? ;)

[Rodéric]

Can we get back to the Amiga days? ;)

how is that any different from consoles ?
(ie set hardware)

[green.pixel]

how is that any different from consoles ?
(ie set hardware)

Well, you keep the openness of the personal computer and have the m&kb/freedom of choice of input devices. You could still upgrade the Amiga, a similiar/updated modern concept like that that would be great if possible. You can write very optimized code for the base hardware, and when the user base builds up with expendable cards/kits, develop paths for them. In the meantime, those would run the existing code at higher res/PQ. This is just from layman's perspective of course.

[Florin]

Doesn't this concept also legitimise Nvidia efforts to provide proprietary access to their hardware's benefits outside of DirectX? Considering that Huddy now seems to be evangelising dropping cross-vendor compatibility, this could be seen as approval for the likes of CUDA, PhysX and OpenGL extensions.

[digitalwanderer]

Doesn't this concept also legitimise Nvidia efforts to provide proprietary access to their hardware's benefits outside of DirectX? Considering that Huddy now seems to be evangelising dropping cross-vendor compatibility, this could be seen as approval for the likes of CUDA, PhysX and OpenGL extensions.
That's sort of what I'm thinking too. :???:

[Bouncing Zabaglione Bros.]

DirectX has been the framework that has enabled cross-company agreement on what abilities should be in the next iteration of their hardware. Companies get together with MS, decide what should be included in DirectX, and then implement that feature set however they see best in their hardware. Without DX as a basic framework, we'd go back to the days when every company did different things, offered different functionality, and no game could rely on having a given feature be available in hardware.

[I.S.T.]

This really does not give me any faith in AMD's decisions with regards to software of any kind. Nvidia may do shit that is at best anti-competitive, and at worst trying to engender a monopoly, but at least they aren't trying to destroy Direct X and thus plunge us back into the dark ages of 3D software development!

Why does AMD have such brilliant hardware engineers, and such idiotic people in charge of the software and ISV relations departments?

http://rinth89.files.wordpress.com/2011/02/businessman-banging-his-head-against-the-wall-ispc026073.jpg

Edit: And, for that matter, why can't we get a third GPU maker that doesn't pull Nvidia's bullshit and AMD's idiocy?!

[Andrew Lauritzen]

Let's be clear... I don't think anyone is saying we should get rid of DirectX. Rather, some are advocating providing APIs in addition to it that allow higher performance at a lower abstraction level. Presumably DirectX will continue as a "least common denominator" standard as it is now and games will continue to have a DirectX path. They just could also have faster/more optimized paths for specific architectures by coding more "to the metal".

[Davros]

Let's be clear... I don't think anyone is saying we should get rid of DirectX.

with a quote like make the api go away i think huddy is :D

ps: does he give any idea of what speedup we could expect from going to the metal ?

If its more than 2x that will be fun, imagine the senario, crysis 3 comes out has a gf580 path scores 60fps
nv releases gf580 successor (we never have 2x improvement) has to use fallback dx path with crysis 3 scores lower.

[DeanoC]

By "Make the API go away" Richard is forcing a debate by stating an extreme view to cause the headline.

He well knows the pros and cons and no-one is suggesting in reality not have a cross-platform path that back/future and sidewides proof as the current OpenGL/DX is. The question is that *IF* there was a way similar (or lower) to CUDA for GPGPU to drive the HW lower and more directly, would AAA PC devs use it and so make the PC platform shine, as we all know its capable of.

As I mentioned in the earlier post, its as much related to cost as API, but the debate is whether its worth exploring? If IHVs made it so, and devs could get the funding, would could we do with a modern PC setup?

[Bouncing Zabaglione Bros.]

I somehow doubt that AMD wants to provide a second low level API that allows devs to hit the metal. AMD and Nvidia have enough trouble maintaining a robust DX API, and now they want a second one that will allow programmers to do all kinds of stuff that will make your PC unstable?

So what's Huddy really saying here? "Wouldn't it be great if we could get rid of API overhead?" Yeah it would, but then you wouldn't have a high level API. Huddy might as well say "wouldn't it be great if every programmer wrote in assembler and could hit the metal? Think of the extra speed you'd get without going through the API". Really who is going to do that? There are reasons programmers today use high level APIs instead of hand-tuned assembler to the metal, and those reasons haven't gone away.

[Rodéric]

Those systems that can outperform the consoles significantly may not be a big enough market to make it appealing...

[Arwin]

Those systems that can outperform the consoles significantly may not be a big enough market to make it appealing...

The amount of systems that could outperform would increase in numbers by tenfold though? :wink: If you think about it, it would also increase the bandwidth of PC games that can run console level graphics or better.

How about if Crytek and Epic could code to the metal, or D.I.C.E., or Id? People could make their own game engine APIs that are optimised for current GPUs. That could still work? How about people who would be able to write something that raytraces a lot, or is founded on smart tesselation, or voxels or whatever, not having DirectX get in the way of that performing half decently?

I can think of a lot of reasons why people would allow it, without DirectX ever having to disappear completely. But instead of making very complicated drivers with optimisation profiles for each individual game created by vendors during or after the fact (=release of an important game), we're back to where developers can find their way around.

And it's not like there are that many competitors on the market right now either.

[MfA]

This really does not give me any faith in AMD's decisions with regards to software of any kind. Nvidia may do shit that is at best anti-competitive, and at worst trying to engender a monopoly, but at least they aren't trying to destroy Direct X and thus plunge us back into the dark ages of 3D software development!
Or maybe AMD at the moment doesn't have a lot of faith in Microsoft's independence for the next DirectX?

Without a fair development model DirectX isn't all that useful.

[Davros]

And it's not like there are that many competitors on the market right now either.

And if everyone had to code to the metal we would never have any more
no one would code for a chip that had no market share and a card would never gain market share if no one coded for it

[Arwin]

And if everyone had to code to the metal we would never have any more
no one would code for a chip that had no market share and a card would never gain market share if no one coded for it

I could be wrong, but I am very strongly under the impression that the work that goes into driver optimisations and DirectX optimisation knowhow is currently probably much worse than any opportunities offered to code to the metal would pose. I don't know that there would be a big difference here either way, but I'd sooner believe that a radical new design would suffer from having to fit into DirectX. And there is only one real way to find out.

Personally I doubt Microsoft will allow it though.

[ninelven]

Personally I doubt Microsoft will allow it though. Couldn't quite follow you here... allow what?

[RichardHuddy]

with a quote like make the api go away i think huddy is :D

ps: does he give any idea of what speedup we could expect from going to the metal ?

If its more than 2x that will be fun, imagine the senario, crysis 3 comes out has a gf580 path scores 60fps
nv releases gf580 successor (we never have 2x improvement) has to use fallback dx path with crysis 3 scores lower.

Note that Huddy (i.e. me) didn't say that he wanted to "make the API go away". I said that "make the API go away" is an increasingly common request from developers.

Just to support that observation I'll quote John Andersson of DICE who recently publicly stated at http://forum.beyond3d.com/showpost.php?p=1535975&postcount=8 : "I've been pushing for this for years in discussions with all the IHVs".

I'm not trying to argue that DirectX is a bad thing - just that (like most things) it comes with a cost.

For the vast majority of developers the 'cost' of using DirectX is well worth it. For some very high end ISVs like DICE it has become a bottleneck that they'd like to go away.

I guess if I were to refine my wording I'd say some ISVs want to be able to render PC graphics without using an API like DirectX or OpenGL...

[Arwin]

Couldn't quite follow you here... allow what?

Access the graphics cards from outside DirectX ... but that is probably wrong (just thinking if there would be conflicts between windows components doing more GPU stuff lately and allowing more direct access to hardware, but I guess it should be possible)

@RichardHuddy: thanks for your clarifications here, it seems we agree (cf what I said a few posts down).

[homerdog]

Instead of coding "to the metal", would it be possible to improve D3D to the point where it is no longer such an impediment? As I understand it, the point of a standardized API is to ensure functionality across a range of hardware. This is not something worth sacrificing IMO.

[Arwin]

Instead of coding "to the metal", would it be possible to improve D3D to the point where it is no longer such an impediment? As I understand it, the point of a standardized API is to ensure functionality across a range of hardware. This is not something worth sacrificing IMO.

D.I.C.E. suggests in their GDC presentation on DirectX11 that they've been working with Microsoft to do that also (perhaps repi can comment on that himself). But those two don't have to be mutually exclusive.

Ensuring functionality across a range of hardware remains possible. It just means that developers of both software and hardware that want to can, go further and develop a complete new graphics pipeline much more easily and/or use more optimisations for specific hardware should they so desire.

[Frontino]

I don't get what's wrong with DirectX ceasing to exist.
Aren't GPUs becoming more general purpose, with less and less fixed functions and increasing independence from the CPUs?
If a SH comes up with an engine capable of running solely on the GPU (with also AI, sound, physics, etc.) compiled with whatever code they like, where's the annoyance?

[Rodéric]

I don't get what's wrong with DirectX ceasing to exist.
Aren't GPUs becoming more general purpose, with less and less fixed functions and increasing independence from the CPUs?
If a SH comes up with an engine capable of running solely on the GPU (with also AI, sound, physics, etc.) compiled with whatever code they like, where's the annoyance?

The no API could come once we get a GPU ISA, until then we need a layer of abstraction to support a broad range of hardware.

Sounds like this isn't a call to go back to the "metal" (and Glide, PowerSGL, S3 Metal...) but to get an improved D3D12 that is even more streamlined and gives more freedom to those developers who want it.
If so, I welcome the idea, D3D (even 10/11) often gets in my way, but not all game studios can afford an increased cost of 3D rendering. (ie can afford to write lower level code than what D3D currently requires, in fact many studios buy engines to be at an even higher level.)

[Dave Glue]

The no API could come once we get a GPU ISA, until then we need a layer of abstraction to support a broad range of hardware.

Sounds like this isn't a call to go back to the "metal" (and Glide, PowerSGL, S3 Metal...) but to get an improved D3D12 that is even more streamlined and gives more freedom to those developers who want it.
If so, I welcome the idea, D3D (even 10/11) often gets in my way, but not all game studios can afford an increased cost of 3D rendering. (ie can afford to write lower level code than what D3D currently requires, in fact many studios buy engines to be at an even higher level.)
If that's what Huddy meant, then he certainly phrased it poorly (or was being hyperbolic on purpose to garner attention to the "issue" and promote this kind of discussion).

Edit: Duh, he's here. No reason to interpret.

No API is not a path that's feasible anywhere in the near future unless the PC market turns into consoles. Cripes, even Apple would have a hard time with such a route.

[caveman-jim]

From chatting with a couple of people that have some insight on being on the dev side of the fence, I'm guessing that devs do want an API, just not DirectX or OpenGL as they stand today.

It's become burdensome and now a challenge to work around, because of the restrictions it creates. As stated in the article, the creativity and innovation is being curtailed because of the API limitations, not the designer, developer, coder, ones.

Anytime an artist or project feels limited by an arbitrary set of limitations, they will seek to remove those shackles. The end result might not be much different but it will be the end result they intended to achieve within their own parameters, rather than settled for.

I remember the creativity of the amiga/atari etc. demoscene, where the demo coders wrote their own everything - didn't rely on the OS functions, just wrote their own assembly: close to the metal. Easy to do on fixed hardware platforms.

To deliver that now an abstraction layer that lived CTM would be needed, something that presented the physical underlying hardware as a representation with physical attributes but allowing the abstraction layer to handle things like varying shader count, simd organization, simd/rop/tmu count, even multi hardware instances. But is it better to start developing this, building on existing virtualization hardware and software capabilities or work towards reforming DirectX or OpenGL; or even expanding OpenCL?

[Davros]

Isnt the driver to the metal
game issues direct 3d api call to the driver
driver converts that to a set of gpu specific assembler instructions (puts correct values in correct registers and issues desired interupt)

[Rodéric]

Just a little note, when moderators delete posts, do not write them again, it tends to annoy us.
If you don't understand why a post was deleted, think harder, as a last resort, go ask in the feedback forum.

[sebbbi]

Somehow I feel that Huddy has forgotten the past. I would not like to go back to the time, when I had to keep my old 3dfx Voodoo 2 inside my box in addition to my brand new NVidia TNT2, because some games only supported Glide. This situation repeated couple of years later. I had an ATI Radeon at that time, but the newest Bridge Builder game was programmed only to work with NVidia OpenGL extensions, so I could not play it at all.

I think the both camps (AMD and NVidia) are starting to become tired to reprogram (optimize) shaders ported lazily from consoles to PC, and in adding antialiasing features to DX9 engine games that utilize deferred rendering.

StartCraft 2 is a good example that even the biggest developers are not finding it cost effective to port their games to multiple APIs. If Blizzard doesn't find resources to support one extra API (DX10) to enable antialiasing in their game, I doubt they would want to program support for at least 6 different APIs (AMD discrete cards, AMD fusion with UMA, Intel UMA, NVidia, PowerVR (used by some Intel chipsets), S3/VIA). And big game developers are surely not going to drop support for some chips just to get a few percent frame rate improvement on others.

I agree with Huddy that draw calls have been traditionally expensive on PC, but that was during DX9 era. Each GPU state bit had to be set separately and constants had to be sent for each object each frame over the bus. Those things really kill the performance.

But since DX9 (SM2.0) the API has evolved dramatically (->DX10->DX11):
- State blocks. This allows fast state change (matching hardware units), and pretty much mirrors the console low level APIs.
- Constant buffers. We can store object constants to GPU memory and GPU can access them without CPU bus transfer overhead. Again this is how console developers are used to use the hardware.
- Lower level access to textures. We can access MSAA subsamples directly and we can have multiple views to same texture data for quickly casting format to another. This again mirrors pretty much the console world. PC developers no longer need to do extra resource copies or instances for these reasons.
- Command buffers and multithreaded rendering. Now also available on PC (DX11). Reusing draw calls by recording them to command buffers reduces draw call overhead a lot.
- Instancing. This was not possible in SM2.0 either. Some newer SM3.0 DX9 cards supported it, but with DX10/11 this became part of the required specs. PC instancing also supports post transform vertex cache properly. I doubt many console DX9 ports supported instancing, since the API support was pretty bad (for example ATI SM2.0b cards had it disabled in their drivers by default).
- Stream out, Geometry shaders and Compute shaders. These allow many new algorithms to run completely on graphics chip (that were previously ran on CPU on PC). Again these features reduce the PC bus traffic and draw call count.

10k-20k draw calls per frame sounds like a lot (esp for PS3). Huddy is likely talking about 30 fps console games, since huge majority of console games are running at that frame rate. I did a quick DX11 render loop and allocated a separate constant buffer per object (CB had object matrix and some object properties). My test renderer could do 50k draw calls + CB changes per frame (30 fps) on Radeon 5850 using just a single CPU thread. So the situation is not that bad for PC as Huddy said.

Where the performance is lost then? A quite simple math explains it pretty well. Highest selling AAA console games run usually at slightly less than 1280x720 resolution (for example Modern Warfare runs at 1024x600, Alan Wake runs at 960x540, Halo Reach runs at 1152x720 as does Crysis 2). 1152x720x30fps = 24.8 million pixels per second. PC gamers tend to want to run their games at 60 fps and have usually 1920x1200 monitors. That results in 1920x1200x60fps = 138.2 million pixels per second. With these increased requirements (by PC gamers), the PC graphics card needs 5.6x pixel shader power to run the scene, just because of the increased resolution and frame rate requirements. And we are talking about exactly the same content here (same objects, same textures, same amount of polygons and draw calls).

Add in 4x antialiasing, 8x anisotropic filtering, 2x2 higher res textures and shadowmaps, etc, and soon the 10x more powerful PC hardware is fully utilized. Without any extra objects in the scene. Unfortunately for most players, the improved resolution (720p->1200p) + double frame rate + improved texture resolution (2x2) + better filtering (AA+AF) doesn't exactly feel like 10x improved graphics quality. But saying that this is the fault of PC DirectX API is an overstatement.

If developers would need to code separate support for all the different PC hardware, I think we would have even less PC games than currently. Most developers would feel that porting the game to PC would require too much extra work to be profitable. Releasing for PC already is really demanding, as it requires huge amount of extra testing. There's so many different OS-versions, different graphics chips (manufacturers and generations), different CPUs and memory configurations. I personally feel that DX10 and DX11 were a huge step to right direction, and I hope that in the future we will continue on that path, making DirectX closer to the hardware API, instead of making a separate API for each hardware.

[Silent_Buddha]

Somehow I feel that Huddy has forgotten the past. I would not like to go back to the time, when I had to keep my old 3dfx Voodoo 2 inside my box in addition to my brand new NVidia TNT2, because some games only supported Glide. This situation repeated couple of years later. I had an ATI Radeon at that time, but the newest Bridge Builder game was programmed only to work with NVidia OpenGL extensions, so I could not play it at all.

<snip--snip>

If developers would need to code separate support for all the different PC hardware, I think we would have even less PC games than currently. Most developers would feel that porting the game to PC would require too much extra work to be profitable. Releasing for PC already is really demanding, as it requires huge amount of extra testing. There's so many different OS-versions, different graphics chips (manufacturers and generations), different CPUs and memory configurations. I personally feel that DX10 and DX11 were a huge step to right direction, and I hope that in the future we will continue on that path, making DirectX closer to the hardware API, instead of making a separate API for each hardware.

Everything was interesting, but this reply only applies to those two comments.

In the first case it's interesting to consider what the PC gaming landscape would be like if not for OpenGL and Directx (both managed higher level API access to hardware). For example, would Nvidia or ATI even exist right now if not for DirectX and to some extent OpenGL? The Riva 128 for example was created specificly to take advantage of and accelerate Direct3D. Without that, Nvidia may not have had a chance to even make the TNT as they had already lost lots of money on NV1 and its proprietry rendering method and API. If not for D3D and OGL 3dfx would quite likely still be king and dominate the gaming world. Even with OGL support on later Nvidia cards, most games were still mostly using Glide for 3D acceleration. Once Direct3D matured, that combined with OGL opened the door wide open for multi-vendor competition in the 3D accelerated game arena.

And for the other comment. I can't help agreeing with that. While there are certainly developers that would and could go to all lengths not only to create multiple rendering paths AND spend the time to make sure they all worked correctly for their game, I can imagine there's an order of magnitude more devs that couldn't justify the cost involved and would only code to the hardware that is most prevalent.

While, I'm sure we'd all like to be able to see what DICE, for example, could accomplish with to the metal access, I can't help thinking that it would be yet another barrier encouraging devs to code for consoles where they only have to worry about one set of hardware if they are exclusive or two (maybe three) sets of hardware if they are multiplatform.

I'd imagine that Microsoft will continue to provide greater access to hardware as DirectX evolves. As sebbbi pointed out, there's already been huge strides with Dx9->10->11. Microsoft is always having to balance the desires of software developers with the reality of what the hardware designers can create with the need to keep Windows a stable platform. They may not always get the balance exactly right, but they do seem to be getting better and better at it. And the computer gaming industry as a whole benefits greatly from them providing a (for the most part) single way to exploit various IHV hardware.

Regards,
SB

[Arwin]

I can imagine there's an order of magnitude more devs that couldn't justify the cost involved and would only code to the hardware that is most prevalent.

But wouldn't these just keep using DirectX, OpenGL, Unreal Engine 3, CryEngine 3, Flash, Silverlight or whatever?

[pcchen]

Personally I don't think multiple code path is a serious problem. For those who don't want (or can't afford) to do multiple code paths, they always have Direct3D. For those who wants better performance out of each vendor's card, they already have to do multiple code paths even with Direct3D. So additional "low level" vendor specific API are probably not very serious problem for these guys.

Furthermore, these low level API also enable the possibility of middle ware (game engine) developers to make better code paths for specific GPU. Those who can't afford to do so can buy (and generally already do) game engines to reduce development cost.

The only problem with low level APIs I can think of is the compatibility problem with current WDDM. Of course you don't want a game using low level API to crash your computer. How a program using a low level API should share resources with other Direct3D programs is also a difficult problem. it could also be a security problem if not designed well.

[Silent_Buddha]

But wouldn't these just keep using DirectX, OpenGL, Unreal Engine 3, CryEngine 3, Flash, Silverlight or whatever?

With using engine platforms (CE3, UE3, etc.) you still have make sure each rendering path works with your game correctly. And if you modify the engine in anyway, most devs do I assume, then you may end up having to code your own rendering paths anyway.

With regards to DirectX and OGL, would IHVs really want to take on the task of providing yet another API that's closer to the metal, bugfix an additional API, optimize an additional API, convince Microsoft that they should allow an API closer to the metal which may or may not jeopardize system stability, etc... Intel aleardy can't keep up with just one API to worry about. AMD while generally just as robust in DirectX has traditionally trailed in OGL, and that's just 2 APIs.

All of which means you will quite likely have developement gradually favoring one IHV over all others.

For example, lets say IHV X can only keep up with IHV Y in one API, gets close in another API, and just gives up on the 3rd. If we use DX and CTM (Close to the Metal), that means they give up competing in the professional market where OGL is far more relevant. And means they'll trail in performance/features in either DX or CTM. Which means end users will gradually tend to favor the IHV with more resources. Which means less resources for the other. Which then means less ability to keep up with 2 APIs, etc.

And I only mention CTM as an API as I'd imagine at least Nvidia and AMD would be reluctant to divulge all information regarding their hardware for fear it could give their competitors an advantage.

IMO, it's best to just keep going as we have been. Software developers pushing MS to allow more access to hardware. Meanwhile, MS evolving DX to better meet the demands of Software devs and pushing IHVs to include features Software developers are demanding while balancing to an extent what each IHV is currently capable of delivering for the next generation. If MS can't keep IHV hardware similar if not the same in terms of capabilities then the PC market will most definitely shrink as we go back to a time when hardware could have greatly disparate feature lists (80's to mid/late 90's).

Remember how things were with fledgling 3D acceleration? 3D acclerated game for Matrox couldn't run on S3 or ATI. And same thing going other ways. So for example, you had to create a specific version of Mechwarrior 3D for Matrox, ATI, S3, and whoever else had a card. It was a bloody mess. Then you had Rendition and 3dfx entering with their own ways of doing things and again you had to code specifically for each one. And eventually the only 3D accelerated games being made were for 3dfx with everyone else being ignored until OGL and D3D matured. At which point Nvidia entered with Riva 128 (D3D), Intel with the i740 (D3D), ATI switched to D3D and started abandoning any proprietary efforts, etc. And it's only at that point that 3D games started being made that could run on all vendors cards.

Regards,
SB

[sebbbi]

Remember how things were with fledgling 3D acceleration? 3D acclerated game for Matrox couldn't run on S3 or ATI. And same thing going other ways. So for example, you had to create a specific version of Mechwarrior 3D for Matrox, ATI, S3, and whoever else had a card. It was a bloody mess. Then you had Rendition and 3dfx entering with their own ways of doing things and again you had to code specifically for each one. And eventually the only 3D accelerated games being made were for 3dfx with everyone else being ignored until OGL and D3D matured. At which point Nvidia entered with Riva 128 (D3D), Intel with the i740 (D3D), ATI switched to D3D and started abandoning any proprietary efforts, etc. And it's only at that point that 3D games started being made that could run on all vendors cards.
I started my first 3d engine project when Glide was still very much alive, and in DirectX 5 you had to load different textures to different memory banks just to get things to work properly on Voodoo 2 cards as well (both Voodoo 2 texture units had their own separate memories, and the frame buffer was in third memory pool). PowerVR had their own API as well. I remember implementing lens flare code by directly accessing depth buffer. The bit orders were completely different on Matrox G400 compared to Voodoo 2 and TNT, and PowerVR didn't have a z-buffer at all. Everything was obviously completely undocumented. Personally I would not like to go back there.

Don't get me wrong, I love getting my hands dirty and doing very low level microcode and EDRAM optimizations on Xbox 360 and to pass DirectX API completely whenever possible. And same applies to all other closed console hardware I have worked with (I always prefer the lowest level hardware access). However these platforms all have a single hardware configuration, and you can performance analyze and fine tune every little bit of your code to match the hardware perfectly. You can even do silly trade offs to reduce a bottleneck that would seem really counterintuitive if you didn't know exactly the bottlenecks. But I don't want to do these things on PC, since all the bottlenecks change depending on the hardware. How should I suppose to know how I allocate my unified shader GPRs between VS and PS on each part of my scene if I don't know how many registers and shader units the graphic chip even has? What is the correct TEX/ALU ratio I should use for each card? Should I write 4d vectorized shaders for low/mid/high TEX/ALU AMD cards, and different 5d shaders for the last generation cards? What happens if my game launches with 5d shaders, and next year AMD releases new generation cards with 4d shaders? Do all developers need to path their games to run with the new hardware? Does the low level API have a "simulation" feature that I can use to query using my shader, render target and state info to get the bottlenecks and make educated choices to pick correct shaders / render paths real time? Could I query the vertex cache size? (this would actually be great feature to have in DirectX).

This thread actually increased my curiosity to test how fast DX11 renders stuff from prerecorded command buffers (we use them extensively on consoles). Basically with prerecorded command buffers you could render an animated scene with no draw calls at all. The prerecorded command buffer just includes the constant buffer GPU memory addresses for each object, so you can edit the constants and still reuse the recorded draw calls from frame to another. Objects can be moved/rotated by editing their matrices in the constant buffers. Of course you would need to update the main scene command buffer periodically, but much less often than every frame.

[DarthShader]

Bit-tech.net last Wednesday reported that AMD's worldwide developer relations manager of its GPU division, Richard Huddy said software developers told him Microsoft’s Direct X was getting in the way (http://www.bit-tech.net/hardware/graphics/2011/03/16/farewell-to-directx/1)of optimal graphics performance for PC gaming. In an interview with CRN on Tuesday, however, Huddy said his comments had been taken out of context and exaggerated. Huddy and Neal Robison, senior director of ISV (http://www.crn.com/channel-encyclopedia/definition.htm?term=ISV&x=&y=) relations at AMD, said only high-end gaming developers may benefit from going around Microsoft’s API.

http://www.crn.com/news/components-peripherals/229400101/amd-re-affirms-commitment-to-micrsofts-directx-api.htm?pgno=1&itc=refresh

Some more interesting stuff there.

[Tahir2]

Would the lack of an API slow the the release cycle for new hardware?

I was thinking about something along those lines.

Each architecture from AMD and NVIDIA has a major refresh every 18 to 24 months with incremental and evolutionary changes in between.

Wouldn't "programming to the metal" break compatibility? It would mean a lot of new patches every time new hardware was released and 18 months is not a significant amount of time. Consoles have a life shelf of 5 years (maybe moving to 7-10 years this generation) so consumers have a system that is well supported for a reasonable amount of time.

The alternative is new hardware is built around these new metal APIs and therefore sometimes cannot be as innovative in change as they once were.

In either case I don't see it working. Not just yet anyway.

[pjbliverpool]

Forget about removing the API, getting developers simply to use the best iteration of it and not the one that's now about 8 years old and suffers from horrible performance pitfalls would be a start.

[rpg.314]

Oh come on, no body uses OpenGL these days :)

JK

[Tahir2]

Forget about removing the API, getting developers simply to use the best iteration of it and not the one that's now about 8 years old and suffers from horrible performance pitfalls would be a start.

It certainly helps that the new baseline is no longer the unspectacular 4500HD from Intel but rather the HD Graphics 2000 and 3000 series.

DX9 going away? I think first the new consoles need to be released for that to happen. As it is it looks like mobile phones are about to further increase the popularity of this API.

[swaaye]

Hey when is Tim Sweeney going to chime in and recommend we just do GPGPU-driven software rendering? ;)

[Tchock]

Would that really bypass the problems regarding overhead anyway? :lol:

[Davros]

On the bright side we could free up the gpu for a.i, sound and game logic ;)

[green.pixel]

http://www.extremetech.com/article2/0,2845,2277870,00.asp

But there's a lot of things with gaming and Vista that you just want to slap Microsoft and go, "What the hell were you thinking?"

When we created DirectX, there's a reason it's call DirectX. It was direct access to hardware acceleration to the developer with very little abstraction and operating system nonsense in the way. So DirectX was meant to be very fast and low-level, and push all the OS bloat out of the way. Over the years that's been forgotten, so each subsequent generation of DirectX has had more value added from Microsoft, which makes the API more complex, more bloated, harder to understand, and so forth.

[Humus]

I disagree with that statement. There's little "bloat" in DirectX. It's all a matter of API design. DX10 has significantly lower overhead than DX9. DX11 provides the opportunity to thread the command buffer generation, which doesn't really reduce overhead but can improve throughput. For DX12 I hope the overhead can be further reduced, for instance by giving the applications more direct control over some hardware resource, such as like in Nvidia's bindless graphics extensions to OpenGL.

[green.pixel]

Why did he say something like that when it's not true?


I think that AMD are finally becoming aware of and upset that the endless stream of console ports aren't helping them sell newer cards.

[Demirug]

Why did he say something like that when it's not true?

You might know that he was responsible for DirectX some time ago. I am not sure why he has quit but since he left he claims all the time that Microsoft does it wrong. Maybe he really thinks so or maybe he is just angry for a reason we don’t know.

[Andrew Lauritzen]

When is that interview dated? The site seems a bit screwed up so I can't be sure... doesn't sound modern. "Page 1" seems to say 2008 which makes it totally irrelevant in this space.

As Humus mentions it's also so factually untrue that it's staggering if truly coming from an expert. DirectX 10/11 isn't exactly an "easy to use rendering API" with lots of helpful features these days. It's pretty close to the lowest level abstraction over current hardware as possible... in fact it sacrifices several favorable abstractions to be "more low level" that restrict how future hardware is built.

[iwod]

Sorry for digging up an old thread, any news on the discussion?

[asmara]

I remembered this thread when I was listening to the keynote speech by John Carmack at QuakeCon 2011.

This transcript of an interview also hits on some relevant points.
http://mudojuegos.com/?p=5421

I searched for 'pointer' on this page for the discussion about low-level access v. API and what AMD and NVIDIA were doing.

(hello everyone)

[swaaye]

John Carmack's comments on Rage development challenges and fighting PC APIs and drivers is along the same lines.

[NRP]

Is he still using OpenGL?

[AlStrong]

Yup, he's using it... on there. :yes:

[homerdog]

And if I'm not mistaken it's OGL 2.0 on there.

[swaaye]

asmara, sorry I somehow missed your post when I was posting from my phone. I didn't mean to seem to bypass you.

[Novum]

And if I'm not mistaken it's OGL 2.0 on there.
I'm pretty sure he's using some extensions that go beyond basic OpenGL 2.0 if it makes sense.

[Humus]

Sorry for digging up an old thread, any news on the discussion?

There was a rather interesting panel discussion at Siggraph where this kind of topic was heavily discussed. It appears the general consensus is that making the API more low-level is considered the right way to go, with the main issue being how far you can go without constraining future hardware, breaking compatibility and still having it vendor agnostic. I think there are still things that can be made lower level than it is today without losing too much abstraction. For instance more freedom over memory use, with a more malloc-like approach rather than CreateXXX(). Being able to control whether textures are linear or swizzled. Command-buffer patching etc.

[bigtabs]

Hey when is Tim Sweeney going to chime in and recommend we just do GPGPU-driven software rendering? ;)
Tim Sweeney has been awfully quiet of late, unless I'm just not looking in the right places. Used to love hearing/reading his view on things. The last I heard from him was easily more than a year ago, on that very topic. If anyone has more recent links, I'd appreciate them.

We need to get Sweeney and Carmack together for a couple of hours and film the ensuing conversation.

[CNCAddict]

We need to get Sweeney and Carmack together for a couple of hours and film the ensuing conversation.

By far the best idea I've seen this year :yes:

[Tahir2]

Tim and John are that passionate about what they do I fear it may end up in a blood bath. Bad idea! :)

[iwod]

Tim and John are that passionate about what they do I fear it may end up in a blood bath. Bad idea! :)

Then i am sure the movies will be one of the best sellers.

From Reading on what John said about API, it seems we might want a Modern, New, Lower Level API.

But isn't that what is Future OpenGL moving towards?