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)
So while we wait for some great games to make proper use of DX9, we can dream of games on DX10 and only dream of the wonders of DX11.
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"?
if theres one thing a business model can achieve, its quick and streamlined development on something as critical as directx. gnu/linux desperately needs improvement in this area
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
Doesn't this logic seem backwards?
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.
Shouldn't hardware vendors develop processing capability, then the software vendors implement the OS support? Or maybe I'm sensitive to the Evil Empire trying to dictate other computing advances through its 'embrace and extend' philosophy.
Compare this to CPU design, however - Microsoft doesn't dictate to Intel what extensions to add onto x86. Or do they? (puts on tinfoil hat)
I want to delete my account but Slashdot doesn't allow it.
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.
Instead of say "ultra shade 2000 (tm)" how about "more polys render (tm)". Cuz really well drawn 2d trees/grass/foilage is getting kinda lame [no matter how high the bpp is!]
... though I recall when 15/16 bpp was dreamy] cuz I concentrate on the game, not how nicely phong shaded some poorly tesselated object looks.
Really it gets to the point where people are like I want 300fps *and* I want every pixel to be drawn perfectly.
I'd just go for decent poly/s and a card that doesn't catch on fire! Heck I play most games in 16bpp [yuck!
That and as many others said... why not use OpenGL? Or better yet. Why doesn't DirectX just act like a wrapper around OpenGL [or merge OpenGL into DX?] DX does provide input/sound support which nobody bitches about. The 3D support leaves a lot to be desired [and undesired]
Tom
Someday, I'll have a real sig.
... be better off using something like OpenGL or SDL or some other cross-platform (if not Free, free, or combinations thereof) API, if for nothing more than to make porting to Mac or consoles or anything else much easier?
Don't blame me, I voted for Kodos
A shader is something that shades things that need to be shaded, while leaving thing that don't need to be shaded alone.
"While the next major revision for DirectX is not expected until Longhorn's launch..."
Well, that means we've got at least a couple years (or a decade) for games to really take advantage of DX9. I'm glad that people will be given a chance to get new hardware that properly supports DX9 (at a mainstream price) and PLAY games that support it before we're told to upgrade again, even if it's only because of Microsoft's problems with Longhorn.
(Minor digs at MS and Nvidia in there of course).
"But I trust in the people's capacity for reflection, rage and rebellion." -Oscar Olivera
How about a sneak preview of how many patent licenses it will require to implement?
No, wait, that would be bad marketing. You have to get everyone excited about it first, then when everyones asking for it, the other vendors will want to use it, and *then* the patents come out.
Ah, screw all this microsoft monopoly crap. I prefer free market capitalism. Give me Free Software any day.
Expert in software patents or patent law? Contribute to the ESP wiki!
"We have X's in our name, too! In fact, in our new and improved version there's twice as many X's! Just wait until our next operating system, codenamed Windex, comes out. Those Linus people ain't got nothin' on us."
If aspiration is a virtue, achievement cannot be a vice.
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.
What is the real advantage of using DirectX instead of standard OpenGL? I'm going to start a little project soon and I have to decide what tools to use. Are there any problems with OpenGL support on Microsoft systems or what?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
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.
Longhorn.
No really, I was there.
What, you mean it's not going to be called DirectXX?
It would certainly get someone's attention...
The Penguin Producer
Are you guys retarded?
/me blinks
Why is this modded up to insightful, instead of funny?
Xbox Next, if it's not just a codename, is already triple X. Whether this is XXX in the Vin Diesel style or XXX in the high-nudity low-artistry style is still in the proverbial air.
I guess we all know what the Next version of Windows is going to be called! :)
As I understand it, the next version of Windows is code-named Donghorn.
-kgj
-kgj
It's just sad to see how far down Slashdot has
sunk these days.
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.
The Intellivision console actually tried storing 3/4 of its textures in ROM, which is why so many of the games for InTV look the same. I originally thought this was true of the NES as well, what with the uppercase Latin font being identical across so many early NES games and with early Game Boy games having a different font altogether, but the first time I went ROM hacking, I realized this wasn't true.
Speaking of ROM hacking, if you really did work at Nintendo, I'd be sued by now.
Specifically, we're embedding data for Mario, Luigi, Donkey Kong, the Princess, and Link into ROM.
Wouldn't the Bowser model be more detailed than the Mario model, requiring more of a load time and becoming more of a candidate for on-console caching?
Another objection: ROM is slow and expensive; hard disk drives, as used in the Xbox console, are much cheaper and still faster than typical DVD-ROM. Couldn't the game keep the models on the disc and then cache them on the HD, possibly sharing models between a pre-installed Smash Bros. 3 and many of Nintendo's other flagship titles?
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).
When it comes to graphics, what I want is exactly "Whiz-bang" features.
Graphics whore since 1983 and proud of it!
Will code a sig generator for food
Buy Steampunk Clothing Online!
Buy Steampunk Clothing Online!
The screen will automatically sharpen to compensate for the drunken blurring from drinking excessive quantities of Australian Lager.
Australians couldn't give a Windows 4X for anything else
DirectX runs at 0fps on my Linux machine. I don't see how anything else could be slower.
Also if Neverwinter Nights isn't a "real" game, I'm the king of France.
Karma: It's all a bunch of tree-huggin' hippy crap!
Um, it's called parody. Or satire, if you prefer.
I've had this sig for three days.
That has nothing to do with DirectX.
Deus Ex 2 specifically uses hardware Pixel Shaders in its engine. If your card doesn't use them, it won't run, because Deus Ex 2 was programmed that way. The GeForce MX cards are not supported.
What people mean by backwards compatibility in DirectX is that DirectX 9 doesn't break compability with games that use earlier versions of DirectX. For instance, I'm typing this on a laptop that has a Mobility Radeon 7500, and I have DirectX 9 installed and can still play Black & White or Deus Ex 1. They each use different earlier versions of DirectX.
DirectX 9 can't make your card do something it doesn't have the hardware support for. Backwards compability with earlier cards just means it will still also do DirectX 8's hardware features, DirectX 7's, and so on. It's inclusive with each previous version's features. Each new DirectX version just adds new hardware features and capabilities to the 3D interface that newer cards can take advantage of.
Deus Ex 2 should have had an option to turn off the Pixel Shader bump-mapping, and then your card would have ran it, since it doesn't do Pixel Shaders 1.1.
"Sufferin' succotash."
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!
There doesn't appear to be a single thing in there to address physics. This means that I'm still going to get monsters in the wall, explosions that go through floors and clothing passing through players, it's just going to look nicer.
Ecerquest was Windows only for a LOOOONG time. It was a Windows/DirectX app from inception. Only long after it had been out (like 3 years) was it ported to other platforms, and that was after it's prime.
There is a real difference between somethign that was developed as a Windows game, then later because of its success, had effort spent on it to make it work on another platform, and a game that was designed using open standards as to run on more than one platform from the beginning.
Why it is no company likes to call its software version 10?
It's not DirectX 10, its DirectX Next
It's not OS 10, its OS X
It's not Redhat 10, its Fedora
Do companies think that people won't use anything labeled 10? Or, maybe they just assume the average consumer can't count the high.
Well, I'd like to see how DirectX 10 does.
I think I think, therefore I think I am.
One thing that many people might want to consider when comparing DirectX and OpenGL is that DirectX is a suite, and GL an interface to the 3d extensions (and 2d) of your video card.
However, with that in mind, is there an equivilent suite that incorporates GL? 3D graphics are nice, but I do remember thinking nice things about DirectMusic (situation-themable audio events) and DirectSound. Is there anything we can use to compare to directX as a whole?
Being that I'm currently working on learning/developing using C++/GL in linux, it would be nice if anyone could point out any extensions aside from just graphics (which, while they may be a large portion of a game/multimedia-app, are not always all of it).
Don't DirectX games absolutely blow chunks when playing across untrusted networks? I mean, they always have in my experience, but that's limited to the Civilization series of strategy games.
Configuring a firewall to pass the ridiculous number of ports required is a pain in the ass (I actually wrote a script to do it because it's too tedious otherwise) and you still can't have multiple players inside and outside if you're NATted to a single outside address. Well, OK, you can sort of do it if you are willing to settle for huge performance hits and major lack of function.
I suspect directX has evolved into a scam to sell uPnP firewall technology, which is out of the question for anyone who actually needs a real firewall.
This is really sweet. There's any number of times I've wanted to store one shader in the light and one on the mesh and just combine them. it looks like this would allow you to run through once with the light shader and then run through on a second pass with your stored mesh on the specific mesh shader. Unless I'm misinterpreting (if I am ... someone please make this happen... it'd make writing the shaders *so* much easier)
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.
mixmode is dead!!! long live framebuffer reads.
People who quote themselves bug the crap out of me -- Me.
There's no such thing as a free port. Even if you're using largely the same APIs.
I am a 3D coder guy, and your description is grossly accurate. Allow me to be more accurate. :-)
In 3D graphics, models are composed of vertex sets (all the edges) and fragments (pieces of the model). For performance reasons, you want to keep all the models on the video card, and not re-transmit them through the system bus every frame.
Example: a walking person.
In a "vertex soup" system, you would have to carefully move every single vertex, every frame, then upload that to the video card, and let the video card rasterize the model (=convert it from points into a picture). This is not very practical.
Fragmenting your model into pieces (torso, shoulder, upper-arm, joint, forearm, etc.) lets you keep all the pieces on the video card and move the different pieces around, much like a jointed wooden doll. Keeping it on the video card means you don't have to spend a long time waiting for the data to be transferred to/from the CPU, so you can see a *huge* speed improvement.
Now lets say you want to modify the model, maybe to make the joints look beter.
Without shaders, you would have to modify a bunch of points on the model, then transmit it back up to the video card, then render it, every frame. That is very slow, but easier to transmit a small portion, like a joint, every frame than it is to do the entire model.
Shaders try to help you keep the model on the video card. Rather than modifying and re-transmitting a model fragment, you send a shader program and give it instructions every frame.
What they can do
Vertex shaders let you modify :
Fragment shaders let you modify:
You can do an awful lot with those shaders, much more than the few things you mentioned. Some of the big things right now are hair/fur, grass/sand/dirt on terrain, and perturbed surfaces.
But there are a lot of things shaders cannot do. They only operate in specific places in the graphics pipeline. They must be small and operate within very tiny time and space requirements. They have limits on execution control (no looping). They have very limited input, and output can't effectively be re-used in other places.
Shaders need to be very small and run very quickly, since they may be run in the hardware hundreds of millions of times each second. One of the biggest complaints I hear about shader languages is that you can't loop, and you can't do more general programming on the GPU. But shaders have to live within very tight rules. They function as a slow pit-stop or detour within a VERY high-speed rendering pipeline.
But lets just think about it; Let's briefly consider the GeForce4 Ti 4800. It has an advertized performance of 136 million verts/sec and 1.23 Trillion ops/sec. If they had only a single pipeline, it would ne
//TODO: Think of witty sig statement
I have 94 freaks. :P
I hate liberals. If you are a liberal, do not reply.