Slashdot Mirror
A Glimpse Into 3D future: DirectX Next Preview
Dave Baumann writes "Beyond3D has put up an article based on Microsoft's games developers presentations given at Meltdown, looking at the future directions of MS's next generation DirectX - currently titled "DirectX Next" (DX10). With Pixel Shaders 2.0 and 3.0 already a part of DirectX9 this article gives a feel of what to expect from PS/VS4.0 and other DirectX features hardware developers will be expected to deliver with the likes of R500 and NV50."
If they could somehow program Dx10 so it was backwards compatiable with cards now (such as radeon 9800 etc), if I'd bought such a card I'd be quite annoyed if there wasn't decent support for it in the future.
When anger rises, think of the consequences.
Confucius (551 BC - 479 BC)
XBOX Next?
:)
DirectX Next?
I guess we all know what the Next version of Windows is going to be called!
At this point DirectX is years ahead of OpenGL
With few, if any, games fully supporting DX9, is DX10 a bit of overkill? I'm all for the advancment of technology, but it looks like the cart is coming before the horse, and dragging the horse with it.
Doom 3 was delayed.. again.
So DX11 will be "DirectX Try"?
I could care less about this functionality being exposed through a proprietary API.
My question is: when will it be available in OpenGL 2.x? :-)
Cross platform is the best way to go with game development...and OpenGL is the only game in town for cross-platform 3D graphics. It is also the official 3D API for Macintosh.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
DX9 is backwards compatible with even my lowly NV25 and MX cards.
The issue is my card doesn't have the vertex shaders and other registers that DX9 takes advantage of so i won't be fully accelerating new DX9 features. I can run DX9 games just fine even though my card was designed with 8 in mind.
Its not that it isn't backwards compatible, it is that your hardware doesn't suport technology of the future since it didn't exist
Only way around this would be if your GPU core was software driven and they could update it. Otherwise to get new DX10 support, you need a DX10 card that was built with the new functionality in mind.
Backwards compatibility has nothing to do with it. Its just like in the days of MMX vs NON MMX. IF you had MMX it ran faster, if you didn't it never wouldn't work for you.. just would be slower.
Microsoft aren't dictating to NVidia and ATI what features to put in their next chips, either. NVidia, ATI, other card makers, and graphics programmers, are telling Microsoft what features they need in an API, and Microsoft are releasing APIs that have those features.
Compare this to OpenGL, which is lagging so far behind that only rare titles take it seriously (Doom3 is the one that springs to mind).
Note for example that both NVidia and ATI provide better support for DirectX in their drivers than they do for OpenGL. That doesn't sound like companies being imposed upon, that sounds like companies appreciating an API that supports the features they've spent a lot of money developing.
And they don't care about portability, because Linux and MacOS are basically irrelevant as gaming platforms. That's not going to change until OpenGL catches up with DirectX, guys.
The game developers are the ones who really want new performance features (sure it will make the hardware manufacturers money but the developers are the ones who are really driving it).
The game developers don't ever work directly with the graphics card, only the API. So to them extensions to performance are basically extensions to the API (and just demand that users get a card that supports the API).
The API for DirectX is of course designed by Microsoft who want people to use it because it locks them into Microsoft more than OpenGL. So Microsoft want to advance the API to please the developers. Therefore Microsoft extend the API for new future features.
Graphics card performance is not based on processing power, its based on how fast they can go while implementing the API (either DirectX or OpenGL). To get sales they need their DirectX performance to be good so they follow the API (with one eye, the other on OpenGL) and try and make the best card for implementing it.
So there's no real point having a feature on your graphics card that isn't used by the API. While OpenGL does have extensiosn to allow you to get at manufacturer-specific stuff to an extent, as I recall DirectX doesn't so much (it just provides a generalised architecture for manufacturers to implement, as core OpenGL does).
Which is why DirectX comes before the manufacturers to an extent. There's a bit of poetic licence there but that's my general view.
I'm no 3d coder guy but as I understand it shaders are short programs you can enter into the GPU to control how a face is rendered [at a given vertex]. Before that you used to say "render me with [phong|gouraud|flat] shading" and the whole thing looked uniform.
Shaders programs let you do cool things like features [e.g. skin, roughness to things, etc...]
What I don't get is why didn't they just make the GPU a generic RISC with say 32/32 registers [ALU/FPU] and a set of instructions that fast graphics would require [say saturated X bpp operations, fast division, etc...]
That way you have a processor you can just upload code to. Also make it a standard so instead of having "every joe and their brothers graphic processor specs...." you have something truly conforming...
Tom
Someday, I'll have a real sig.
I have done some work with DirectX and the biggest problem I see is that new versions come out too quickly. Do you want your project to be totally tied to DirectX version N with you know N+1 will be out next year making your huge project obsolete or requiring a rewrite. For that reason SDL or OpenGL (an API that hardly changes) appeal to me. Who wants to build on shifting sands.
Notice how some words, such as "OSs", are underlined by the spellchecker in the pictures. Are they too lazy to remove those?
Er, they did. There's even a C-like programming language, in case you don't want to write raw assembler for these processors. The whole process of uploading stuff on the graphics card is halfway standarized, at least in OpenGL; I don't use DX, but according to documentation you can use the same shaders with similar commands.
Documentation of the OpenGL side is in the OpenGL Extension Registry, look for "shader" and "program".
I try not to make it a habit to flame people, but do you know what you're talking about? Adding new functionality to DirectX *before* the new hardware comes out, means that when you buy your new GeForce FX 9999, you don't have to wait for Microsoft to release a new version of DirectX 6 months later to use the full potential of the card. This has absolutely nothing to do with embrace and extend. This is their proprietary graphics/multimedia API in the first place. How can they "embrace and extend" their own library?
Your second bit of anti-Microsoft conjecture is no better than your first. When it comes to Microsoft working with Intel to add extensions to the x86 processor set, so what if they did? Do you think they wouldn't benefit all x86 operating systems? At the level of the instruction set, how would you design into an x86 CPU, instructions which only benefit one x86 OS? Yes, Microsoft has worked with Intel on the instruction set, but mostly vice verca. It is Intel who releases the manuals on "how to write an OS for our CPUs." But no matter how they're working together, that is a good thing, not "the evil empire at work."
Please, learn a little and think a little before you post your knee-jerk anti-MS reaction. There are plenty of legitimate reasons and opportunities to bash Microsoft. The problem I see is a lot of people look like that guy from Can't Hardly Wait who keeps trying to find the right second to start the slow clap.
At Nintendo, we have been surprised that no major graphics vendor has really addressed to an adequate degree this problem, so we're currently spearheading the development of a new architectural paradigm called MARIO, standing for (Making Assets for Rendering I/O Optimized).
In a nutshell, we move bandwidth and space-consuming model and texture data from RAM and disc media, where it is time-consuming to load, to super-fast ROM, contained within the GPU itself. Having this data in silicon will dramatically speed up the rendering process and hence the user experience overall.
You may ask, how do we modify these models and textures? Of course, that is not possible, but we've done great research, and have found that for most of our games, the same models and textures are always being used anyhow, so it makes sense to put those in ROM.
Specifically, we're embedding data for Mario, Luigi, Donkey Kong, the Princess, and Link into ROM. For 99% of our anticipated future games, this will cause a dramatic speedup in performance, and will provide a great incentive for game developers to license the use of our assets in their games, instead of using their own proprietary non-Nintendo characters in order to make their 3-D rendering pipeline as efficent as possible.
We at Nintendo look forward to the quantum leap in graphics performance this new architectural vision will surely bring on and are quite excited as you can see!
-- Samir Gupta, Ph. D. Head, New Technology Research Group, Nintendo Co. Ltd., Kyoto, Japan.
Compare this to OpenGL, which is lagging so far behind that only rare titles take it seriously (Doom3 is the one that springs to mind).
I can only see one property of OpenGL that is "lagging behind" DirectX: Whiz-bang features.
Is OpenGL "lagging behind" DirectX in portability? hardware support? scalability?
I would argue that OpenGL as a general-purpose 3D API is more useful than DirectX soley because it is more widespread. The API is implemented (or implementable) on a more diverse selection of hardware and software platforms than DirectX can ever dream of.
As a Intel-Windows-Cutting-Edge-Game-only API, DirectX is the way to go, but for everything else, we have OpenGL.
Wow, you are very uninformed for someone who was rated +5 Insightful.
OpenGL exposes new 3D functionality much faster than DirectX, through the OpenGL extension mechanism. It may not be as convenient as having a "standardized" API (and OpenGL 2.0 will address as much of that issue as it can), but it is still better to be able to use new functionality immediately, rather than waiting for the next DirectX release (or worse yet beta) from Microsoft. NVIDIA's drivers even support all of this under Linux.
As to your "rare titles" comment, see my other post for top games using OpenGL. Also reflect on the fact that every id game plus all the games based on id engines (Heretic 1/2, RTCW/ET and many more) all use OpenGL exclusively.
And guess what, when id releases Doom3, I'm pretty sure it'll raise the bar again. Perhaps by then quite a few people will have shader-capable video cards. ;-)
For more correct information about OpenGL, feel free to check out the official OpenGL website.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
What, you mean it's not going to be called DirectXX?
It would certainly get someone's attention...
The Penguin Producer
But there is more then just a technological cost to bring games to market. There is the marketing, QA, tech support, packaging, distribution, etc, etc, etc, of bringing games to additional markets. And even if it was just money, (most?) game companies are fairly small outfits; the 'distraction' of other markets might be too much for overworked staff, everyone from the CEO down to coders.
While I dont think the 'Loki experiement' was fair: its clearly easier to port to other OS if you do it from day 1, not from the release date. Basicly only ID Software developes games that have a design goal of being cross platform. But the ID Software people all have more money then they can spend, there decisions are not purely business ones, and others who should/could be using ID as a prescidence know that. It would take time, money, and (perhaps most importantly) effort, to develop games for what is still unproven markets.
Since it hasent been pointed out yet, its not a OpenGL v DirectX question. DirectX is not just a 3d graphics library; it does many, many other things. While there are many OSS projects to bring the same type of libs to linux (and other !MS OSs), some sponsored by now dead Loki, DirectX is the most compleate set of libs... And while I havent coded it either OpenGL (and friends) or DirectX, Im suspect, since DirectX comes from a single source, as a whole it is more cohesive and unified then OpenGL + friends... Which isnt to say that any given DirectX component is better then alternatives, but as a package DirectX is almost definitly better then the (not existant) OSS package.
What I don't get is why didn't they just make the GPU a generic RISC with say 32/32 registers [ALU/FPU] and a set of instructions that fast graphics would require [say saturated X bpp operations, fast division, etc...]
This was tried in the past, with TI's TIGA (Texas Instruments Graphics Architecture) which supported the TMS34010 and TMS34020/34082 graphics coprocessors. This was a really neat architecture which accelerated 2D and basic 3D operations. Unfortunately, the CPU chip manufacturers (Intel, etc...) would identify the bottlenecks and optimise their CPU's so that the next generation chips would be faster than a current generation CPU/GPU. "Local Bus" basically whacked out TIGA from the market. A real shame, since you could write your own extensions which had complete access to GPU memory (maybe this was a bad thing). They even got as far as having a trapezium rendering algorithm (halfway to rendering triangles).
Going back to the present day, look for the extensions like ARB_vertex_program and ARB_fragment_program. According to Microsoft's plans, these will at least have identical instruction sets. I wonder how long it will be before we can completely define an entire graphics pipeline using a single program.
(This would probabl require virtual "clip_vertex", "render_triangle" function calls).
Buy Steampunk Clothing Online!
The article's really long, and somewhat technical. Here's the layman highlights for anyone who just wants to know "Ok what should I care about?"
.plan update which you can find here: http://www.bluesnews.com/cgi-bin/finger.pl?id=1&ti me=20000308010919
1. The big change is all memory goes virtual. What this means is that you don't need to load an entire texture to render a subset of it's pixels. This is a VERY good thing considering on most textures you're only using a low level mipmap anyway. Thus, texture memory on the card becomes more like a gigantic L2 or L3 cache that can be efficiently used. Also you can have massive texture spaces without having things go all slow over AGP. 3Dlabs' Wildcat already does this. This was originally mentioned by Carmack in the 3/27/2000
In addition, geometry is stored virtual as well, as are shaders, which can be loaded into the processor in pages, instead of being limited to a small block of instructions that have to fit entirely into the GPU registers. The registers now work more like an L1 cache, and shader programs can be effectively unlimited size. This means lots of neat special effects will be possible.
2. High ordered surfaces (curves) are getting mandated. No more n-patches vs truform, it's going to use standard curve systems like Beizer splines.
3. Fur rendering and shadow volumes are going into hardware as part of a new "tesselation processor"
4. You can have multiple instances of meshes. This means you can take one model, run a few vertex programs on it, and store each result seperately. Saves alot of time later.
5. Integer instruction set. This is so you don't have to deal with floating point data when you don't need to. There are some times you want simpler data for use in a shader program and having to pretend everything's a floating point texture isn't convenient.
6. Frame buffer current pixel value reads. This has been a developer request for a long time. It's not mandatory in the spec, but it can be used for all sorts of stuff. Basicly the GPU can read the current value in the framebuffer into the pixel pipeline without needing to maintain a second copy. This will both save alot of memory and allow you to do things such as light accumulation more efficiently.
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!