Digit Life claim that GF4mx has vertex shader 1.1

[up]

So, ...is there a chance for the Gefoce4 MX 440 to see the 'Nature' part in 3d Mark 2001 SE (benchmarkmode!) with the right driver?


BTW, I've put a Leadtek Geforce 4 MX 440 in a comp and got no Nature in benchmode...
P933/192/MS6309 = 3337

 

[Teasy]

So, ...is there a chance for the Gefoce4 MX 440 to see the 'Nature' part in 3d Mark 2001 SE (benchmarkmode!) with the right driver?

In a word no. A chip needs to be able to support both vertex and pixel shaders in order to run the 3dmark2001 nature test.

<font size=-1>[ This Message was edited by: Teasy on 2002-02-27 00:50 ]</font>

 

[cho]

In Microsoft's DX 8.1 SDK:

"In DirectX 8.x, the HAL can have three different vertex processing modes: software vertex processing, hardware vertex processing, and mixed vertex processing on the same device. The pure device mode is a variant of the HAL device. The pure device type supports hardware vertex processing only, and allows only a small subset of the device state to be queried by the application. Additionally, the pure device is available only on adapters that have a minimum level of capabilities."

So, I think GF4 MX had HW Vertex Shader (1.1) .

 

[pcchen]

On 2002-02-26 23:40, Humus wrote:

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.

I believe that emulation can not emulate everything in hardware. That is, if it wants to emulate all pixel shaders (as required by DX8), some pixel shaders must run in pure software. Emulating pixel shaders will be too slow to be practical, at least for games. Therefore, I don't think any Radeon drivers are going to emulate those pixel shaders in software.

Vertex shaders, on the other hand, does not suffer this problem that much, since many CPU can run vertex shaders at reasonable speed. So if many vertex shaders can run in hardware, and some complex or lengthy vertex shaders have to run in software, it may still have some advantage.


<font size=-1>[ This Message was edited by: pcchen on 2002-02-27 07:16 ]</font>

 

[ram]

On 2002-02-26 18:10, pcchen wrote:
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.

Yes. But IMO the way Burke is describing it is quite missleading. Letting the GPU perform some of the instructions of the same shader and some by the CPU is impractical if you can't split the shader and send two connected shader parts to the processors.

The only thing I can imagine beside what you're saying is that the driver analyses the vertex program for instructions the GPU can't handle as well as data depencies between standard functionality and custom code. If that's the case, the driver could split the shader and send the custom part (e.g. custom transformation) to the CPU and after getting the result sending the rest (standard lighting) to the GPU. But I think this capability is very limited.

 

[aths]

My theory is:

The NV17 got a DX7 T&amp;L unit. The common transformations (for the object and for the point of view) are done by the GPU, all the other VertexShader operations are done by CPU.