Hi.
I wanted to perform some deferred shading using pixel shaders 3.0 and DirectX 9.0c in a GeForce 7800. All was fine until I tryed to change the "stencil light volumes" for an unique pixel shader... Noticed the FXC ( effect compiler ) has two HEAVY problems:
1) Doesn't allow texture arrays. For example, you cant do "shared texture tex [ 8 ]".
2) Doesn't support pixel shader constant indexing.
Surfing the Internet I found this
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi ubb=get_topic;f=3;t=013925
thread in the OpenGL forums... And that situation is exactly the same I have... Due to the lack of that pixel shader constant indexing, the FXC tool unrolls that very simple code inside the light enumeration loop ading really unnwanted instructions to the shader...
Do you have planned to fix this How can I do a "c[a0.x]" in a pixel shader Is the ps_4_0 ( well or unified model ) near in the time Do you have planned any pixel shader version between the 3.0 and the 4.0(unified)
thx.
Pixel shader 3.0 constant indexing
Hot Topic
- DirectDraw Surface.Draw with aplhablending
- HELP "The file system.dll is missing!"
- Threading issues
- How can I draw a line with pencil like effect ?
- DX SDK 9.0 cutted edition :)
- i need help! pls I want to begin to write games
- Loading .X meshes
- Totally newbie question - development platform?
- to David Weller and tom miller
- Problem setting the attribute table of a mesh
Game Technologies
- MechCommander2: Multi-Player?
- Can't Run Any Programs On Others Machine
- EDITING TOOL FOR COMPILED SOURCE
- commercial use
- Rendering Skeletal Animation
- Loading DirectX inside a .NET control
- I cant Install Directx 9.0c December 2005 dsound.inf problem
- Sample framework on a panel with mouse and keyboard
- "Ensure that DirectX SDK is correctly installed"
- Image Zoom with Sprite Draw
Pixel shader 3.0 constant indexing
Peter2005a
So resuming, this is my wish list for the next direct3D thing ( if they can listen me ):
1) Pixel shader constant indexing ( something like dot(g_dirLightConstants [ i ],tex2D(normalMap,uv) )
2) Pixel shader texture sampler indexing ( something like tex2D(g_myTextureSampler [ i ],uv) )
3) Write-to-cube face - 6 multiple render targets (COLOR0 to COLOR5) pixel shader output ( to do 1 pass cube shadowmaping for example )
4) A LengthSq intrinsic function in the HLSL/GLSL ( well is just a dot(a,a) but helps shaders to be more readable )
5) Unified shader model : no pixel shader and vertex shader... just "shader" with all the features I mention WITHOUT limitations. Infinite length shaders, real early-out/return/break/continue branching, full loop-indexing, pointers/linked lists, etc... This allows to use the GPU as other "virtualized" CPU for physics, heavy SIMD calculator and other !=graphics applications.
6) Topographic shader. Allow SEPARATE indices for vertex positions, normals, UVs, etc to avoid duplicate transformations... And add to the triangles some info like "what triangles are adjacent to me " for stencil shadows or GPU-ROAM terrains. See this thread in the OpenGL forums:
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi ubb=get_topic;f=3;t=013930
Also, the topographic shader could create/destroy triangles... So you can add to it too some kind of "adaptive displacement mapping" and "adaptive tessellation". I've seen some WGF2 presentations about this, but nothing concrete...
7) Force IHVs to MEET minimum requisites. Oh, your card can't do pixel shader constant indexing Sorry, not WQHL and not Windows-compatible logo for you...
8) Support OpenGL plenty. There is no fight between OGL and DX really... OpenGL people will continue using OpenGL and DX people will continue using DX... The are not rivals, just "differents" approaches to do the same. Some programmers need COMPATIBILITY, and OpenGL exists in multiple platforms... If you wanna start a war then make DirectX for linux, else suport OpenGL in Windows Vista so everybody can be happy with you.
9) Support both Managed .NET and pure C++ APIS ( like you do at the moment with Managed DirectX and C++ DX9 ). I think WinFX and .NET are very cool but games that need speed should be able to decide if they use managed or pure C++. I would like to see the XBox360 using Managed.NET too...
10) Add boolean ( and, or, xor, not ) algebraic operations to the shaders. For example:
int i = (int)tex2D(tex,uv).r;
int val = (i^90) & 0x3E;
this is very useful for testing attributes in deferred-shading MRTs
11) Add support in D3DX for reading OpenEXR files. Expand the DDS format to support "image tiling" for BIG images. Also add some animation support and normal map compression.
Bength
http://www.beyond3d.com/forum/showthread.php t=11813
quote:
"Crytek and Epic were both there showing off Farcry and Unreal 3 on the NV40, some cool demo's with Crytek going into detail on what they did to use SM3.0. Interesting they were very honest (given they were at a NVIDIA sponsored event) with the problems encountered, subtle problems like pixel shader not having a constant index register (which stopped them implementing there intended PS 3.0 lighting model) and stencil/single-pass lighting problems."
But then was TOO LATE. You must listen developers BEFORE to release the model, not after the IHVs had tapped out its GPUs.
Perhaps if Microsoft and NVIDIA desgined it better, the graphic cards supporting SM30 NOW could include this important features... So was really an API thing, because no graphic card existed when SM3.0 came to the life and you could re-designed it better with all this features... Now the poor programmers must pay, as always, this design fault using very ugly and completely absurd texture lookups to emulate constant indexing in the pixel shaders and also the user suffer because this will force them to buy a new improved ps_4_0 model card in the future...
I found ps3_0 completely lacking due to:
1) Pixel shader constant indexing lack.
2) Pixel shader texture sampler indexing lack.
3) Doesn't support 6MRT cube faces, only have 4 max MRTS ( oC0-oC3 )
4) Due to all the before mentioned, the FXC tool generates really absurd shaders like is mentioned in the OpenGL forums.
5) Topography shaders pls Unifyed/unlimited(really) shaders pls
6) Boolean algebraic operation pls int i=( (int)tex2D(tex,uv) ^ 80 ) & 0x3E;
So basically ps_3_0 is ps_2_0 with branching... because loops are absurdly unrolled into tons and tons of instructions... Now I can understand why you allow 65536 instruction slots...
So I complain about API ( because was bad-designed BEFORE the HW came to life, with serious limitations ), about the hardware and about the metodology followed...
The next time you, Microsoft, NVIDIA, ATI, blah blah work together, please do a DEFINITIVE-ULTIMATE shader model, because to release a new shader model each 6months with serious limitations ( like all I mentioned ) in one or other way has no sense and you force us to implement 18 different paths ( 1.1, 1.3, xbox reg combis, 1.4, 2.0, 2.x, 3.0... ) in our engines... better wait a few more, perfection the shaders, analyze what want the developers and release a FINAL model.
And this is valid too for the OpenGL comitee and for all, of course!!!
Other thing I wanna say : Perhaps is better the OpenGL approach to HLSL... Instead of using the FXC tool to compile into DX9 shade asm, it could be good to let the driver compile the HLSL into its own internal shader instructions to optimize and use certain features the graphic card have... For example, the GLSL allows you to use "bunch of texture arrays" without problem... it compiles ok... but IF the card doesn't allow texture samplers indexing then unrolls the loop. If the card allows it, then will use sampler [ idx ] without problems, YAY!. The company who made the graphc card KNOWS better than other its internal design... This is good too optimize and good too to reduce the size of the DirectX runtime and SDK because there is no need for FXC.exe, VSA.exe, PSA.exe etc etc.
thx and please take this as a constructive critic for the next shader model relese, it doesn't pretent to be a flame at all.. All I want is a most-perfectly-possible model for the programmers and users.
Amit_Kulkarni
Actually Microsoft listens pretty carefully (if i do say so myself). I think you will be pleased to find that a majority of things you have listed (but not all) will be available in the next shader model. Balancing IHV needs to release new products with developer needs for stability and uniformity and technology improvements is tricky business You'll note a fairly large time gap between the release of shader model 3.0 (back in 2002 with shader model 2.0) and shader model 4.0 (slated for 2006). It is quite a large step forward, but there are still more steps to come. Game development is currently one of the driving forces in computing and that is ultimately going to continue to drive innovation in software and hardware.
ToxicSoul
The API/DDI specs are always defined before hardware supporting it exists. Exactly the same with D3D10 stuff - they've got that API well under way, yet it'll be a long time before we see any hardware that can actually handle it...
They do! Microsoft are a pretty powerful force and they don't seem to have too much trouble getting input from the other big players in the industry. I don't know the specifics of how such meetings take place (1 on 1, or big 'round table' events), but I do know that they don't just invent API's and features inside of a dark closed room.
Hindsight is a wonderful thing. It's not an easy game to be planning ahead by years at a time... it's inevitable that the needs/desires and so on will change between the spec being finished, the API being released and the IHV's catching up. Of course Microsoft would be able to make SM3 better if they knew 3-4 years ago what they know today.
Check out the various bits of public information on D3D10. You might be a bit happier
That won't happen. Real-time computer graphics is moving at a phenomenal pace. If they made SM4 a 100x better than SM3 then you'd still (might take longer) get to a point where you or other people would be complaining about it's limitations.
My understanding is that they specifically *dont* want this to happen! On paper I quite like the OpenGL approach - but in practice it's going to get messy. Allowing the compiler to ship as part of the drivers leads to, amongst other possibilities, combinatorial explosion - us developers will need to do even more testing to verify that the same shader produces the same outputs in a suitably efficient manner.
As a general comment - it might be worth considering these sorts of design decisions based on the business climate as well as the 'pure' innovation side of things. Any suitably big company has limitations - financial, time etc... and they must decide to balance the priorities against their resources in order to get the product out. I'm sure many developers would like to be left alone for an undefined length of time to produce the most awesomely amazing and super-unbelievably-cool best-ever product, but that's just not possible in the 'real world'
Best regards,
Jack
Bin Liu
june_21