No Fixed Function At All?
Obviously, Microsoft (and the conspiring graphics card vendors) do not care enough about existing applications that rely on fixed function rendering to provide some level of intrinsic support for a fixed function pipeline. The DX9 fixed function pipeline is seriously limited in its ability to replace fixed function rendering done by OpenGL, but the complete removal is a serious snub toward existing professional applications. 90% of the professional modelling applications use fixed function rendering because it 1) fast, 2) simple to code against. Providing snippets of fixed function rendering is truely a cop out since the ramp up to getting this running in a reliable way is far more difficult than these snippets imply.
A better solution would be for Microsoft to admit that there is actually merit in fixed function, simplistic rendering and offer a supported path for applications that are looking at porting to D3D. Granted that Microsoft and the graphics card vendors don't want to support fixed function AND shader based rendering, one very clean solution would be to offer a D3DXStockEffect interface that allows the application to select from a set of commonly used, fixed function pipelines (e.g., Direct3D, OpenGL, Toon, etc.). This way everybody wins -- the porting application can simply select a stock effect, set values in the shader in a similar fashion as the emulated fixed function API, and the backend rendering is implemented by a shader. As it stands, if an application that is currently using basic circa 1994 OpenGL 1.1 functionality (no extensions), that application is required to write a custom shader to achieve the same quality output in D3D (any version). If the destination hardware does not support accelerated shaders, there is a huge performance penalty. If the claims that graphics card drivers are already writing dynamic shaders to implement fixed functionality today, then the stock shader suggestion would simply provide the application developer with an easy path toward a final solution. The stock effect eliminates the burden of writing yet another fixed function shader emulator and provides for some level of return to a standard level of display. The fixed function pipeline, while simplistic in some ways, is typically sufficient for many professional modelling or scientific applications. Does it really make sense to REQUIRE every application to re-invent the same wheel? Stock shaders are not unlike the GDI GetStockObject(enum) call used to select a basic black, white, or gray pen or brush.
Without a fixed function pipeline, could someone detail the least number of lines of code to draw a simple, appropriately lit, red triangle?
[2779 byte] By [
tranders] at [2007-12-24]
While the fixed function pipeline might be simpler to code for, it doesn't offer any increased performance on modern video cards. In any case, if you want the the fixed function pipeline, you know where to find it. No one is stopping you from using DirectX 9, or OpenGL for that matter. As such functionality would be part of the Direct3D Extension library it could be added in every one of the later 2 monthly SDK releases. But with the limited resources the team has they need to set priorities. As nice a fixed function shader factory would be most early Direct3D 10 projects would profit from such an addition. Game engines that get a D3D10 extension would already use shaders for their D3D9 path as no one would ignore the D3D9 shader models. I know some scientific people that are interested too but they want not port their old stuff they are interested in the new possibilities of Shader Model 4.
Anyway it’s a valid request and if others will support it enough there is a chance that someday it will included. It’s even possible that someone else will write such a tool. I remember that 3DLabs have done it for OpenGL.
 Ross Ridge wrote: |
| While the fixed function pipeline might be simpler to code for, it doesn't offer any increased performance on modern video cards. In any case, if you want the the fixed function pipeline, you know where to find it. No one is stopping you from using DirectX 9, or OpenGL for that matter. |
|
This forum is for D3D 10 concerns and fixed function rendering is a concern. While fixed function rendering is available in DX9 and OpenGL, removing fixed function rendering from DX10 prevents any DX9 fixed function application from using DX10 enhancements (e.g., ID3DXMesh::DrawSubsetInstanced) because unlike OpenGL, DirectX does not support mixing different versions. I just have a problem with REQUIRING everyone to implement, debug, and maintain algorithms that have been a part of standard rendering API's for over twenty years (and I'm not talking about DirectX). It's like removing AND and OR gates from all circuit diagrams and requiring chip designers to only use NAND gates. You can accomplish the task and it will be "just as fast", but you have to route your own paths for AND and OR.
If no one complains, then how is Microsoft going to know that people disagree with their decisions?
No one is requiring you to use DirectX 10 or removing any tools you already have. Maybe DirectX 10 would be better for you if it included the fixed function pipeline, but it's not making things any more difficult for you. If you think DirectX 9 or OpenGL is easier, you can still use them.
It all depends on what you mean by "require". If you classify "not allowing me to use parts of DX10 unless I write my own shader to emulate fixed function rendering" as not requireing me to use DX10, then yes I'm not required to do that. My point has been that I am required to write my own shader if I want to use enhancements to the D3D architecture even though I have no need to use anything but fixed function rendering. That is why I suggested the inclusion of stock shaders to allow applications to move forward without the pain of re-inventing the wheel.
You are mistaken as well as OpenGL does not allow mixing fixed and shader versions of the Pipeline. Especially OpenGL ES, which I'm currently developing an implementation of. Typically, you use either OpenGL 1.x or 2.x series. OpenGL and DirectX are following the direction of the video card manufacturers which is to provide a more robust and faster environment for developing high quality graphic applications. Unfortunately, it means you and others may need to take some short toerm pain and convert your fixed functionality to a shader based model. This is a natural evolution of the system as many people (including myself) have been complaining for sometime that we'd like to have more control of the pipeline instead of throwing stuff into a black box and letting it churn (fixed function pipeline). It is true the fixed pipeline is easier to program (whether OpenGL or DirectX), but for far more control of your system, the Shader based model will allow you to do far more and have far more control of the pipeline.
| tranders wrote: |
| A better solution would be for Microsoft to admit that there is actually merit in fixed function, simplistic rendering and offer a supported path for applications that are looking at porting to D3D. |
|
Fixed functions in modern graphics cards are, in fact, emulated in a programmable pipeline. In addition, if you want fixed-function capabilities, you can use DirectX 9, which isn't going away for a long time. New features in Direct3D 10 are found in the programmable pipeline, so there's no benefit for you if you insist on using FFP, which we still fully support in D3D 9.
P.S. -- This thread has been moved to the "Graphics" forum, as it is unrelated to Direct3D 10 issues.
No, I am correct -- read the GLSL specification. OpenGL specifically allows the mixing of fixed and shader versions as detailed in the GLSL shader documention. The GLSL ftransform() function specifically details the mechanism that allows multipass algorithms to use both shader and fixed function passes and be guaranteed the same transformation result (e.g., depth buffer values). The natural evolution you elude to is what I would call entropy -- more of a devolution -- in that the core API provides nothing more than a compiler and a pixel pusher. It's nice for all those applications that need to display multitextured, volume fogged, motion blurred animations because those applications had to struggle with fixed function pipelines to get the results they needed. It's a nightmare for the application that renders basic shading with a few multipass algorithms that fit perfectly in the fixed function pipeline because those applications now have to expend significant effort to re-implement logic that was once considered core functionality. It's not something I CAN'T do, it just not something I should be FORCED to do.
With respect to OpenGL ES, it is my understanding from reading the specs that the OpenGL ES SC (Safety Critical) version essentially reverted from the "forward progress" because the shader model did not offer the level of security and stability that some applications demand (e.g., aircraft instrumentation, etc.) because of non-deterministic resource requirements. I would much rather have my application render using fixed functionality and actually WORK, than have my application be subject any and every virtualized resource leak that might pop up.
I understand that fixed function rendering is being emulated -- that is not at all the point of the thread. The point of the thread is that Microsoft should provide the fixed function applications a way migrate by way of a stock shader that provides access to what is already being emulated by the driver. If such an interface were provided via the D3DX toolkit -- everyone wins -- Microsoft can drop the fixed function pipeline from the API, the stock shader can provide access to an immutable state block, and the fixed function application developer just moves a few names around.
So you consider ID3D10Device::DrawIndexInstanced() not important to fixed function rendering? I have customers that have models of 500,000 high definition components (nuts, bolts, washers, frames, springs, etc.) that consume upwards of 3GB of application and display memory. The display has no photorealistic or mutitextured requirements although there is a fixed function multipass algorithm to make sure everything is presented correctly on the screen. I'm not sure why you think that a fixed function display would not benefit from new features in D3D10? It would. The only problem is that I have to replicate algorithms that were designed 30 years ago. Not only do we beat dead horses, but we dig them up from their graves and beat them again.
P.S. -- this thread was only related to Direct3D 10 as the title clearly indicates.
| tranders wrote: |
| P.S. -- this thread was only related to Direct3D 10 as the title clearly indicates. |
|
tranders,
I moved the thread to "General" because I thought it was an important discussion that was bigger than just D3D 10. For instance, the XNA Framework only supports programmable pipeline as well, even though it is only (currently) targeted to DirectX 9 and the Xbox 360 platform. It wasn't meant to appear as a snub. Quite the opposite, actually.
