 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| An Overview of Microsofts Direct3D 10 API |
|
 |
Pipo DeClown Member since: 2/16/2002 From: Amsterdam, Netherlands |
|||
 Posted - 12/15/2005 4:44:01 PM |
||||
| I haven't read it -YET-, but I just wanted to thank Jack for the great information he has been spreading on GDNet. It's very useful to many DirectX users and makes every DirectX10 mystery clear again. I'm not back. I'm just visiting. |
||||
|
||||
 |
jollyjeffers Moderator - DirectX and XNA Member since: 3/16/2000 From: London, United Kingdom |
|||
 Posted - 12/15/2005 5:17:39 PM |
||||
Quote: Wow - thanks  It's always great to hear that it's been useful. Cheers, Jack Jack Hoxley [ Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ] |
||||
|
||||
|
Calefaction Member since: 4/26/2004 From: Houston, USA |
|||
|
Posted - 12/16/2005 11:02:47 AM |
||||
| As nice as some of the features in DX10 are going to be, I can't shake the feeling that MS won't allow it to run on XP simply because they want to force an OS upgrade. They have done it in the past, and I have no doubt they are doing it here. It's sad that they won't even support their own products for more then five years before they kill them off and force the consumer to upgrade, thus taking any form of choice away. If I want to play the latest games come 07, I will have to upgrade to Vista, despite XP still working perfectly fine. Great article though. Some good features coming in DX10...too bad the price is so high. |
||||
|
||||
 |
evolutional Moderator - Alternative Game Libraries Member since: 1/25/2002 From: Leeds, United Kingdom |
|||
 Posted - 12/16/2005 12:07:47 PM |
||||
| I don't think it's a case of them 'forcing' an OS upgrade to Vista, more like DX10 has been written as to rely on components and driver models that don't exist or will never exist on WinXP. |
||||
|
||||
 |
superpig GDNet Technical Lead Member since: 5/26/2001 From: Oxford, United Kingdom |
|||
 Posted - 12/16/2005 1:49:17 PM |
||||
| As evolutional says, it only runs on Vista because it needs the Vista Display Driver Model. Besides, I'm not sure there's any guarantee that the 'latest and greatest' will all be using Direct3D 10 by 2007. Don't forget that D3D9 is supported in Vista and so targetting it gets you both Vista and older OSes like XP; any D3D10 card will support D3D9 with SM3, so you do get quite a lot of power without jumping to SM4. Even if there's something that requires D3D10 to look the way developers want it, I wouldn't be surprised if we saw a decently large number of games supporting both D3D10 and D3D9 in the future. If you want those games to look and run their best, then sure, you need Vista, but that's part of what upgrading is all about. |
||||
|
||||
 |
kSquared Member since: 10/29/2004 From: Charlottesville, VA, United States |
|||
|
Posted - 12/16/2005 1:51:35 PM |
||||
| What a great article; very informative and definitely filled in some of the gaps in my understanding. Thanks Jack! - k2 |
||||
|
||||
|
don Member since: 6/2/2002 From: Washington, USA |
|||
|
Posted - 12/16/2005 2:08:47 PM |
||||
| One thing I'm curious about is whether an app can precompile its HLSL shaders at content-creation time rather than run-time, and just pass a pointer to a buffer containing the compiled shader to Create*Shader? I'm assuming that the compiled shader output is still in some format that any D3D10-compliant card can support? Does anyone know if D3D10CompileShader actually makes calls into the driver to do the compilation? |
||||
|
||||
|
superpig GDNet Technical Lead Member since: 5/26/2001 From: Oxford, United Kingdom |
|||
|
Posted - 12/16/2005 3:57:27 PM |
||||
| Looking at D3DX10CompileShader*, you get a Blob out, which you could easily write to disk and load back in later. Once you've got a compiled shader, either in blob form or just in a buffer in memory, you'd use CreateVertexShader to actually create a shader from that. So it's certainly possible. Whether it has an effect of performance or not I'm not sure. I've heard it suggested that the driver isn't consulted at compile-time and performs optimisation when you call CreateVertexShader, and the reason ASM shaders are no longer supported is to make it easier for drivers to spot patterns produced by the HLSL compiler. I don't know how true that is though. If the driver does get involved somehow, perhaps you could do something like this: Ship both HLSL and compiled-format shaders (that would work but would not be optimized appropriately) with your title. Initially, use the compiled-format shaders, but recompile the other shaders in the background. As you generate optimized versions, use them to replace the generic ones. What you get is a relatively short install, followed by a slower start in your game but an improvement in performance after a moment or two as shaders get optimized (especially if you prioritize them in a good way). |
||||
|
||||
|
jollyjeffers Moderator - DirectX and XNA Member since: 3/16/2000 From: London, United Kingdom |
|||
|
Posted - 12/16/2005 5:48:56 PM |
||||
Quote: Glad to hear you liked it  Quote: Yes, it can. I'm not a 100% sure if/how the current API handles it as I haven't tried... but it's in the specification. One compelling reason for this is the potentially ridiculous number of permutations. Current titles can have 100's if not 1000's of shaders across the entire game; I'd expect that to be standard (if not more) on D3D10 titles. I don't fancy waiting for my game to compile 500 shaders before it loads However, one thing I do wonder about... whether anyone would "hack" the binary format. Assembly code is pretty much out... but I'd imagine its not going to be impossible for someone to write a tool to sit between the compiled HLSL and the Create*Shader() calls that allows developers to go back to assembly code  Jack Jack Hoxley [ Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ] |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 12/17/2005 5:50:20 AM |
||||
Quote: Quote: But it this not exactly the "they want to force an OS upgrade" like Calefaction wrote!? Because they bundle Shader4 and the new displaydriver handling together, and made no Shader4 only support for WindowsXP. Or does Shader4 really need the Vista driver? What kind of Shader4 features need it? Aren't the new kind of drivers not only for the new displaydriver handling in the new os? Why should Shader4, like all shader versions before, not work with WindowsXP's drivermodel? Should not be a Shader4 support in OpenGL on WindowsXP possible? |
||||
|
||||
|
TempusElf Member since: 3/23/2002 From: Chicago, IL, United States |
|||
|
Posted - 12/17/2005 9:10:05 AM |
||||
| Good Read. I'm not convinced that the benefits of throwing out the fixed function pipeline will outweigh the fact that there will be yet another barrier for beginners. It is already difficult for people to start learning graphics programming. I can't wait to try out that Geometry Shader, though. |
||||
|
||||
|
Monder Member since: 7/16/2002 From: Cambridge, United Kingdom |
|||
|
Posted - 12/17/2005 9:47:09 AM |
||||
Quote: Well as D3D10 brings us unlimited instruction shaders and you can branch I would've thought this'd become a thing of the past as you'd just write one shader where you can turn various things on and off using constant boolean values. HL2 contains more than 10000 shaders but these are generated from something like 20 HLSL shader files with preprocessor stuff to generate all the permutations, with full branching support none of that would be necessary, though I guess using it extensively may impact performance. But you can't tell until you actually try it on some hardware which currently doesn't exist. Quote: Personally I think shaders are actually easier in a way because it makes the actual pipeline and processes the graphics card uses more transparent. Besides neophyte graphics programmers aren't much of a concern when you're creating a next generation state of the art 3D API. Oh and nice article Jack. I'd already read through the D3D10 docs but your article helped answer some questions and clear up things I was unsure of. |
||||
|
||||
 |
Jason Z GDNet+ Member since: 2/4/2004 From: Royal Oak, MI, United States |
|||
|
Posted - 12/17/2005 9:55:06 AM |
||||
Quote:Not to mention the fact that if you still want to do fixed function work, D3D9 is still available and will run on XP and Vista. I just think it is cool that the capabilities are advancing, regardless of the api. It is good for computer graphics in general that there will be real-time geometry shaders running in hardware sometime next year. It's something new and interesting to learn about. Jason Zink :: MVP XNA/DirectX "Intellectuals solve problems, geniuses prevent them." - Albert Einstein Check out my game: Lunar Rift :: Dual-Paraboloid Mapping Article :: Parallax Occlusion Mapping Article :: Fast Silhouettes Article Check out our free online D3D10 book: Programming Vertex, Geometry, and Pixel Shaders |
||||
|
||||
|
jollyjeffers Moderator - DirectX and XNA Member since: 3/16/2000 From: London, United Kingdom |
|||
|
Posted - 12/17/2005 10:42:43 AM |
||||
Thanks for the feedback everyone - appreciated Quote: Its not so much that the SM4 features directly rely on the VDDM, more that they are tightly integrated into the API. With that in mind and that the API is dependent on VDDM you effectively have an indirect dependency. Its quite likely that the SM4 hardware will be visible to D3D9 (both on XP and Vista) as turbo-charged SM3 parts. I'm sure you can find plenty of cool things to be doing with that Quote: Yup, I'm not imagining 100's or 1000's of individual fx/vsh/psh files being hand-written. Or, if they did - I feel sorry for the code monkey thats tasked with it  Its more that if they reside in memory as a large number of permutations... any preprocessing such that they can be streamed in quicker would be a definite  Jack Hoxley [ Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ] |
||||
|
||||
|
MattL Member since: 1/4/2004 From: New York, NY, United States |
|||
|
Posted - 12/17/2005 10:30:45 PM |
||||
| Has anyone written anything about the performance hit of a multithreaded GPU and/or GPU memory virtualization? Obviously the Direct3D 10 generation of video cards will be designed to handle this, but I'm wondering if there will be some side-effects. For example, as the GPU cycles through all the processes wouldn't it have to copy out all the memory and registers and then copy them all back? Wouldn't this cause hiccups in performance? Similar problems might occur with memory virtualization, since we might not get an allocation failure even when we're bumped down to disk. Can you imagine accessing texture memory off disk in the middle of play? Are my worries misguided? |
||||
|
||||
|
Monder Member since: 7/16/2002 From: Cambridge, United Kingdom |
|||
|
Posted - 12/18/2005 6:19:59 AM |
||||
| Well I would imagine that a full screen D3D application has the GPU all to itself as nothing else will need it. |
||||
|
||||
|
RAZORUNREAL Member since: 1/18/2004 From: Auckland, New Zealand |
|||
|
Posted - 12/18/2005 7:07:34 AM |
||||
Quote: Would it? You certainly don't have to copy out all the memory, and it's not like you'll switch mid pixel, so I can't think of a whole lot that needs saving... You might have to flush the pipelines or something, but I don't really know enough about that. ___________________________________________________ David Olsen If I've helped you, please vote for PigeonGrape! |
||||
|
||||
|
jollyjeffers Moderator - DirectX and XNA Member since: 3/16/2000 From: London, United Kingdom |
|||
|
Posted - 12/18/2005 8:36:34 AM |
||||
Quote: I don't think anyone can write about it yet - until we have some usable hardware, its difficult to reason as to what can/will/wont cause performance problems. Although, I do understand that the new display driver has (effectively) two modes - one where it handles the resource switching and multithreaded access similar to current implementations and another where it offloads it to the GPU to handle at an interrupt/page-fault level. The former being for legacy D3D9 hardware and the latter being the new D3D10 parts. But, either way, you have a valid point - theres plenty of possibility for it to cause some "interesting" performance characteristics hth Jack Jack Hoxley [ Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ] |
||||
|
||||
|
FBMachine Member since: 11/25/2005 From: Rohnert Park, CA, United States |
|||
|
Posted - 12/18/2005 9:31:58 AM |
||||
| Excellent info! :) It might interest you to note, they already got rid of the fixed function pipeline in the xbox 360 xdk. I think it's pretty safe to say, beginners will be given an alternative framework for the fixed function pipeline that they can use anyway. As for having to compile thousands of shaders generated using a fragments/combiner system, that's what we're doing now for the next-gen project I'm working on, but we're actually considering testing using conditionals instead and having just a small set of generic shaders. We'll have to profile to see if it's a performance hit, but using conditionals in this way is pretty much a best case scenario for the branch prediction since they'll always evaluate to the same per material. We'll see if that's actually true! Ok I'm straying off topic, so again, nice article. :) Daniel |
||||
|
||||
|
haro Member since: 3/30/2002 |
|||
|
Posted - 12/24/2005 2:35:39 AM |
||||
Quote: I'm not sure I agree with that. Getting rid of the fixed function pipeline might create a small hurdle for present day programmers used to the fixed function pipeline since it will involve getting 'used' to a related paradigm - but I think this will be great for new programmers. Getting rid of the fixed function pipeline gets rid of another piece of high level 'magic', which makes it alot easier to understand exactly what's going on. And understanding is the most important part of learning. It might make it a bit more difficult for beginners to get their first gouraud shaded triangle on the screen, but when they do get it - they'll be alot further ahead than any of us were when we got our first shaded triangles on the screen. |
||||
|
||||
|
deavik Member since: 6/14/2005 From: Baltimore, MD, United States |
|||
|
Posted - 12/27/2005 9:45:45 PM |
||||
| I don't know if this is a bit off-topic--I apologise if it is--but are OpenGL going to take similar steps forward? I mean, they already have a high-level shading language, so they could ditch the FFP and be done with it. The GS sounds yummy for D3D too, what is going to be OGL's response? |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 1/22/2006 4:47:06 AM |
||||
Quote: does the xbox 360 xdk use shader model 4.0? In that case developers could work on windows vista to develop graphics for the xbox 360... |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
