Digit Life claim that GF4mx has vertex shader 1.1
- Thread starter Teasy
- Start date
Doomtrooper
Veteran
I though software shader support was removed in DX 8.1 ?
It was my impression (correct if im wrong) that vertex shaders can be implemented via the CPU, and not too slowly at that...so while i view this as deceptive, at east the vertex shaders will WORK...which they wouldnt otherwise. It just remains to be seen if nVidias vertex shader emulation is faster than (insert game maker)'s custom job...
Doomtrooper
Veteran
The driver may do all the work but I'd guess it would be dead slow, especially on a sub 1000 mhz processor ?
Generally, it's realistic to do per-vertex stuff on the CPU, depending on how complex the scene is of course, but for many apps the CPU will do just fine even though it may not give optimal performance. Anything that touches textures/fragments/pixels though has to be done by the GPU for pretty much every application if you want it to be realtime.
Yeah - they are not going to change the design from a functioanl unit they already have and risk needless extra respins.
I disagree.
Take character animation for example. The best way to do it on vertexshaderless hardware is to do the tweening/skinning on CPU, and let the GPU do the transformation and lighting part.
I guess they will take games that do use vertex shaders and optimize the codepath for those special cases. (That's what they always do, don't they?)
Yes, it is possible to apply transformations to a subset of vertex programs for mixed-mode execution. If dependencies aren't an issue, non-fixed-function idioms can be moved to the front of the vertex shader and executed in two phases.
Also, from what I've read, the GF2 T&L pipeline isn't completely fixed, it just isn't flexible enough to do DX8. There are still registers and microinstructions, presumably setup by the device driver or firmware ROM. These could have been altered for the GF4MX to expose more of the underlying pipeline to programmability. Who knows what the deficiences are? Maybe a lack of registers, constants, swizzling, etc?
This is similar to the situation with register combiners, where the underlying pixel pipeline was flexible, just not flexible enough.
Also, from what I've read, the GF2 T&L pipeline isn't completely fixed, it just isn't flexible enough to do DX8. There are still registers and microinstructions, presumably setup by the device driver or firmware ROM. These could have been altered for the GF4MX to expose more of the underlying pipeline to programmability. Who knows what the deficiences are? Maybe a lack of registers, constants, swizzling, etc?
This is similar to the situation with register combiners, where the underlying pixel pipeline was flexible, just not flexible enough.
Well, there is a subset of the texture shader where this may work, but i wouldn't say the GF4 MX's has hardware vertex shaders, or even call it a hybrid. It makes as much sense as calling the Radeon 7x00 fragment processing capabilities for a pixel shader compliant hybrid approach since some of the pixel shader operations may be mapped on the multitexture pipeline with a driver tweak.
I would be very surpriced if the GF4 MX had significantly different vertex processing engine than that of GF2.
I would be very surpriced if the GF4 MX had significantly different vertex processing engine than that of GF2.
Hmm... they are bit different. If the GF4 MX's driver really can utilize its hardware T&L engine with some vertex shader, it is a hybrid to me. On the other hand, no driver for Radeon 7x00 can utilize its pixel pipeline for some pixel shader since emulating other pixel shaders will be too slow to be practical. That's a fundamental difference.
<font size=-1>[ This Message was edited by: pcchen on 2002-02-26 18:01 ]</font>
<font size=-1>[ This Message was edited by: pcchen on 2002-02-26 18:01 ]</font>
It is possible if driver is doing all things. Since a built vertex shader can not be altered, driver can determine whether the hardware is able to perform it when building a vertex shader, and choose software code path implemented in the driver if the hardware is unable to process the vertex shader.
Well, some of the early Radeon drivers allowed you to set a registry key "PixelShaderVersion" to enable that version. It would allow you to run several pixel shaders in hardware mode, in fact, most if not all the DirectX SDK examples worked just fine. What's "too slow to be practical" is of course a matter of definition, and varies a whole lot between different applications, not all apps needs to be realtime.
