IndirectX 10
A quick note to express an opinion on Direct3D 10.
It seems very focussed on static mesh rendering, but has no support for direct primitive rendering like OpenGL. So, once again I have to write a layer to be able to draw lines and polys for debugging and quick prototyping.
Direct3D 10 has this "state objects" concept, so now changing states has to be done either selecting different predetermined effect's "techniques" (a technique can select different states) or one has to change states by creating state objects for every combination... what a pain !
I've moved form vertex/pixel shaders to "effects". I still have to see how effects handle render targets with annotations, but it seems like a not very well defined matter. For one thing, nVidia's FX Composer 2 seems to be the better tool to building effects, but at the same time it doesn't support Direct3D 10.. geezz
As GPU programmability is improving, it feels restrictive to use Direct3D 10. Interfacing C++ with shaders is a pain.. but at the same time shaders make it very easy to write highly parallel code.
ummmmmmmm
- Davide's blog
- Login to post comments
Reading all the things about
Reading all the things about everything that Vista brings makes me wonder if Microsoft really lost the grip. I am pretty sure that DirectX10 is not that bad at all, but considering what developers really expect it seems that it went into wrong direction. Also Vista itself seems to be going totally wrong. I was fully upset with it not only that it is nothing new than more demanding and more eye crazy user interface of WindowsXP but also that it's compatibility with existing software was so poor. It did not offer anything new on the other side.
Microsoft really seem to be like US car manufacturers in 90s when they were sitting in their Detroit based headquarters and only watching each other while whole world developed superior cars meanwhile. Microsoft for sure has potential - huge engineering base and unlimited funding but they need to see where the world is going. Having monopolistic position destroys all the creativity. Meanwhile Apple makes things better and better - however I am pretty sure that if iSteve had monopolistic position it would be even worse.
One thing I always wondered
One thing I always wondered is the default theme for XP. The Windows' borders look like they've been designed by Bill Gates own children..
As for the graphic interface of Vista, it looks like a lot of work went behind it.. but it's actually done with little taste and the colors are ugly.
Can't they pay a decent designer ?! Or maybe they just don't want to.. ..it makes me think how no matter how much money and work one puts behind something, if there is no inspiration, little useful comes out.
This is the trap of being
This is the trap of being monopoly. Linux is no competition for them (as Linux advocates say for last 10 years it needs another 6 months to dominate desktop market) and probably never will be as there is no one central Linux coordination. For some time RedHat was able to put money and resources to create one nice unified distribution but even they gave up on it and finally they only focused on server market.
OSX is for sure innovative and nice to use but even it can run on virtually most machines right now, iSteve will never go to dominate PC market as this is not really where the beef for Apple is. They want to maintain their exclusivity and get the profit from selling overpriced (although well built) hardware.
Microsoft problem will develop. Vista is just one good example of how bad they got trapped with delivering great system like Windows XP - Windows 2K would be even better but without support and new drivers for new hardware it is hard to keep it running.
Perfect example for Microsoft how bad is to be monopoly is Office 2007. There is nothing new except really confusing user interface that flips all the work with it upside down. At the beginning when I saw Office 2007 I was amazed because it finally looked clean and neat. But when I started doing just more advanced things I felt limited by this new user interface and I got even more pissed of with it's AI that always thinks I want to do something else.
While Microsoft Office 2004 for OSX is just great to work with. How come it came from the same company?
Ha ha ha ... It almost
Ha ha ha ... It almost sounds like the initial pains of PS2 coding ... I've always been (and probably will be) an OpenGL man ... mainly because I'm not tied API-wise to a specific platform or OS. Hopefully OpenGL 3 will avoid some of these headaches.
More like Direct3D 1.0
More like Direct3D 1.0 ;)
Thanks for the slides (though at the end it asks "Questions ?" in many languages but Japanese and Italian !!! 8P)
I have a little faith on OpenGL. It's obvious that it's evolving too slowly. The 2.0 was nothing exciting, nobody uses GLSL in games.
I liked Iris GL first and OpenGL later because it was simple to use and it was powerful. Now, I think that the new target should be something like RenderMan.
The real-time shaders are tired and will expire sometime soon..
An even simplier API than
An even simplier API than OpenGL would do much better. Most of game companies do very sophisticated game engines anyway. So just using one unified driver level API to have direct access to a vertex processing unit and then texturing unit with simple access to loading primitives and textures would be probably a good thing for the gaming companies. Direct3D always aimed to provide 100% compatibility even if it had to fail into software emulation mode for a non supported features. Microsoft got trapped into it's own design with the development of lower level techniques like T&L and then shaders because they had to start reporting not supported features. This came back to game engine to first check features and then decide how to handle it. One unified low-level API would later cause 3D APIs to pop-up as middleware for people willing to skip the step of development of their management unit for primitives. I still do believe that most game companies that do design their own game engines would appreciate one level lower compatible API.
This would be also a good point for 3D cards designers to standarize one HW layer as it happened for other HW devices like USB/ATA/SATA.
Direct3D 10 eliminates
Direct3D 10 eliminates hardware caps. This time around the hardware must support certain features or it's not for Direct3D 10.
Direct3D 10 is good at grasping current hardware structure, but such structure will change constantly. 3D is different form other hardware as it changes very rapidly. Abstracting state with those objects forces one to think twice about changing states, but it's also a pain in the ass, and the drivers themselves have their own ways to deal with state changes anyway.
When does a state change really matter it's not very easy to understand... it's a whole big pain in the ass. Most importantly, I'd like to be able to draw primitives without having to worry about state change details unless I really find a performance bottleneck.
wooo
Actually, I have more
Actually, I have more important question but I am not sure if you can tell it :)
I wonder what is the reason for game making company to focus on DirectX 10 development. Since installed base of WindowsXP is huge and limiting game only to Vista is like a marketing shot in a foot. Unless it's pure research project :)
It's for research more or
It's for research more or less.. I wonder if any game company is targeting DX10 mainly.. I doubt so !
Aren't you scared by the
Aren't you scared by the fact that the performances of all the video cards on the market drop by 50% going from DX9 to DX10?
Yeah I am not exactly sure
Yeah I am not exactly sure what the purpose of dx10? Apart from the changes in the api, what can it do that dx9 cant?
Makes it easier to sort
Makes it easier to sort states and has support for geometry shaders.
I think the official reason why it's for Vista only it's because it uses a new (better performing) driver model. But so far, most people don't really think any good of being forced to use Vista.
Answering the previous message.. lack of performance in DX10 is probably due to the fact that most games are being designed for DX9 anyway.. especially considering that XBox 360 is running DX9..
Well on the console the dx
Well on the console the dx interface is really just something self imposed to conform with existing api. Each dx function call directly translates into filling in opcodes into the comman buffer.
We already had geometry shaders on ps2 with vu1, although there was no easy way to feed a texture to it. Its funny how in some ways older hardware might actually have a feature that has been overlooked on many generations of more advanced technology.
I dont know if geometry shaders are a move in the right direction, finally we can have truly highly detailed surfaces and not have to cheat with various forms of normal or parallax mapping. But it still doesnt give us a solution for true geometric LOD, since it only solves the problem on a per surface basis.
Still, I don't know if DX10
Still, I don't know if DX10 could be implemented on the 360. The geometry stuff may imply some special GPU feature to run efficiently.
Yeah PS2 already had all that, in fact, it had more than "shaders". I liked that approach better than the shaders approach. It's similar, but the current real-time shader system is rather limited. I've been working to implement the HLSL shaders properly (to deal with common parameters, render targets, states embedded in the shaders) but my final goal is to write shader code natively in C, vectorized code and multi-core.
Geometry shaders can help LOD when used to build geometry procedurally and to tessellate curved surfaces.
For LOD on geometry that is already very complex instead.. that becomes also an off-line processing issue. Doing polygon reduction, but also possibly implementing displacement mapping. Displacement maps being basically 2D textures make it easy to select LODs in real-time by using mipmaps, though one still needs to build lots of extra geometry to be on the safe-side with sampling and avoid aliasing artifacts.
I am not sure what extra
I am not sure what extra capabilities the 360 gpu has, but you are probably right.
I think the extra power of GPUs can not be ignored when considering complex shader processing. For example features like render targets, caching, texture swizzling, hierarchical-z etc... General purpose multicore processor or vector processor will not be able to outperform it.
On the other hand if geometry is detailed enough (triangle per pixel), material properties can be stored per vertex and hardware can do a fast vertex to vertex visibility test then complex shaders are not needed. Even a fixed function t&l pipeline would be enough...
I think that shaders, or
I think that shaders, or let's call them "programmable materials" are important because they are very much used in movie quality rendering.
Only they should be more powerful and easier to implement.. more like RenderMan shaders and less like HLSL/Cg + the 3D engine of the day.
All those features in th GPU to me are more like systems developed around a DSP concept. Nicely organized and streamable data better fits the raw power that can be produced by streamlined hardware solutions. This means texture mapping, with all the DSP-like filtering and rasterization with triangles streaming in without much "thinking".
Shaders instead need more complex processing and GPUs aren't so good at that.
Deferred Shading then starts to make sense as one can more clearly divide the raw power task of converting geometry to pixels (DSP-like task) to then minimize the effort (0 overdraw for opaque materials) that a CPU would take to apply complex shading routines.
..of course then one really have to see if it's really worth it to worry so much about detail. As it's entirely possible that an smart LOD system would give worse average performance than a careless brute force rendered.
For example, though less elegant, it might be simpler to just sort objects front to back before rendering to avoid most overdraw and avoid having to resort to fancier techniques such as Deferred Shading...
wooooooo
I am not sure I agree with
I am not sure I agree with you on the 'shaders need more complex processing'. On the 3d graphics side all we are really trying to simulate is the lighting behavior across a triangle and the complexity arises from the fact that the triangles are large and textures are small.
For example if you want to approximate a square function between 0 and 100 then you need y = a*x*x + b*x + c, but if you break it up to 0-10, 10-20, ... 90-100 then you can probably have y=b*x + c and if you sample at each 0,1,2..100 then y=c is enough =)
So if we increase tesselation density and texture resolution in theory shaders should get less complex.
I guess its the eternal balance between memory size and code complexity. If you can precalculate results into memory then your runtime code complexity decreases. I am more for precalculating and runtime simplicity.
As for deferred rendering I think all modern GPUs have hierarchical z-culling feature in which case drawing occlusion only 'front to back' pass is a good rendering optimization which falls in nicely with the deferred concept.
The shaders' advocate
Sure textures are a substitute for lack of geometry but they make it simple to subsample details. Very detailed geometry instead needs heavy antialiasing to cope with reduced screen resolution.
That aside, polygons also aren't the best representation of nature. For effects such as subsurface scattering, one would still need to build several layers of translucent polygons and those polygons would need some sort of BRDF to handle different ways to scatter light.
Shaders come to the rescue as they basically allow to do some more or less complex custom programming. Routines including jumps and more or less random fetching (multiple texture lookups, or whatever access the shader allows).
Hardware is thus required to allow a certain level of programmability, making it more generic and generally slower. However when doing this for pixel shaders, at least guarantees that those slow operations won't happen more than once per pixel (when opaque and when overdraw is minimized, which is much easier than doing geometric LOD).
The ugly thing about LOD with geometry is that I'm not sure how one picks the perfect LOD. Displacement maps, being basically elevation texture maps, have a regular structure that is easily sampled with a texture unit, however, because they actually displace (possibly stretching along vertex normals ?), the resulting geometry is unpredictably stretched beyond the estimated pixel coverage.
I mean, when doing plain texture mapping, I know exactly how many texels I have to fetch to fill all the pixels of a polygon: one texel per pixel (texture filtering aside). With displacement maps instead, one tessellates on the fly hoping that every polygon resulting form the tessellation will take exactly one pixel, but most likely it will not 8)
Displacement mapping is a bit like doing a landscape per-source-polygon, hopefully without having to worry about LOD across the source-polygon itself !
Hey Kaz
My last comment was deleted, maybe because it was OT, I try again here.
Drop me a line when you'll be in SF, it would be nice to meet for something.
There's a great italian restaurant I tried, we could go there!
Talk to you soon!
Stefano
Hey Pom !
I didn't delete any comments 8)
In fact I even replied.. I hope you can see it ! -> http://v4.kazzuya.com/indirectx_10#comment-1339
wanwan !
Happy Valentines
HAPPY VALENTINES MR. Davide :)
Long time no hear 8)
I know you're a very very busy person 8)
Take care!!!
At times I'm not necessarily
At times I'm not necessarily sure what game companies want. Of course (graphically speaking) it's more realism, etc ... but wouldn't it be wonderful if there were a standardized gamplay API? 8P Just kidding ...
REYES has your eyes
Yeah, going to a fully REYES based rendering system would be perfect. I think the main problem is that the hardware is not quite yet there for real-time purposes. Over the holiday this past weekend, I was in the country-side and was observing how flames in fire and smoke look visually. While it's possible to polygon-ize this and rendering, things would simply be a lot easier to model with a REYES renderer.
I have to keep some faith and optimism for OpenGL simply because DirectX doesn't really inspire much hope. I guess I like taking the side of the underdog ... of course, if I had "no choice" but to use DirectX, I would ... but I have freedom to choose ... at least on whatever I do on my own. 8P
You're probably right about real-time shaders vanishing eventually; it's just everything coming full circle in that (in a sense) things will go back to the DSP-ish route where you have programmable processors that are specialized for parallel operations ... especially with things like graphics.
By the way, have you heard of Pixel-Planes? What's old will once again become new! Ole'! 8P
REYES sounds good.. but
REYES sounds good.. but that's for offline. The idea that eventually geometry will be tesselated to subpixel level makes sense, however to translate to real-time it's a complex issue. ..I think I should try nail down those main conceptual differences for my current research 8)
I remember pixel-planes but I'm not sure if they still mean any innovation nowadays 8)
It's obvious that REYES
It's obvious that REYES can't be used for current real-time applications, but that shouldn't necessarily keep one from adopting concepts that can be used in real-time. I mean some of the things being done now in real-time weren't possible years ago ... akin to the GPGPU stuff. If there's a will, there just might be a way. 8P
But in the current reality of things, it's probably not (currently) worth the time or money, but I don't see why there couldn't eventually be some kind of unit inside the GPU that does subpixel geometry operations. At times what's required is a new approach to an old problem or (if possible) something alltogether new (redesign of the rendering pipeline or a different way of representing surface data?) ... though that's more of a rarity ... especially when it comes to money and market forces.
I wouldn't quickly dismiss pixel-planes as a lot of what's being done on GPUs today were done on that hardware years ago. Alas, what's state-of-the-art graphics will become commodity stuff in the future and won't be so "cool" or "important".
The problem really is that
The problem really is that no matter what speed you reach, the performance curve for off-line rendering quality is exponential. For real-time will always be more useful to pull out all sort of tricks. From the careful hand crafted optimization of models, to less accurate and dynamic lighting models.
Off-line rendering systems are still too far away from real-time. What is really needed is a process that scales complexity (of entire scenes) nicely and takes the burden away from artists (artists aren't stupid, it's just that it takes time for them to optimize things).
There is this real-time ray-tracing solution that has been proposed recently.. however ray-tracing can mean a lot of things. Off-line quality ray-tracing is still relying on some other form of global lighting and traces a lot more rays than real-time can afford.
[OT] GDC in San Fracisco
hey Kaz, still in for the GDC? When will you arrive? It would be cool to meet up once you're here.
I'm here with Italian guys so we can organize something 'very Italian' :)
Let me know!
See ya!
Umm I will leave the 17th,
Umm I will leave the 17th, but right now I have no idea. I'm very busy (yesterday went back home at 3am 8) and have to worry about departing.. the closer I get to leave the more I feel the pressure.. I hate traveling, especially for work, and now I also have to carry a 6 lbs Dell laptop which makes things worse 8)
I don't want to leaveeeeeeeeeeeeeeeeee !!!!!!!!!!!!!!! 8(
Wow ... still burning the
Wow ... still burning the midnight oil ... soon, it'll become midnight vapor. 8P At least you'll be able to get some sleep while flying only to be jetlagged when you return. 8P