Stefan Dösinger wrote:
Now that almost everything is gone from drawPrimitiveDrawStrided we don't need a subfunction for calling drawStridedSlow/Fast any longer
I think while we're cleaning up things, all of software shaders should be removed.
There's tons of code in drawprim and *shader.c, which is disabled, doesn't work, and isn't on the right track if you ask me. None of the changes to make the shader parser 3.0 compliant are used in the disabled paths. There's even an "Emulation" value in winecfg which just confuses the user, since it doesn't work.
I did have a working implementation of software shaders some time ago, which broke things up into functions, and shared the tracing and parser with hardware shaders - but in the end it was too slow, and I abandoned it as the wrong approach too. Unless we generate asm on the fly for the shader or something like that, I don't think software shaders will be made to work soon.
Am Samstag 06 Januar 2007 22:25 schrieb Ivan Gyurdiev:
Stefan Dösinger wrote:
Now that almost everything is gone from drawPrimitiveDrawStrided we don't need a subfunction for calling drawStridedSlow/Fast any longer
I think while we're cleaning up things, all of software shaders should be removed.
There's tons of code in drawprim and *shader.c, which is disabled, doesn't work, and isn't on the right track if you ask me. None of the changes to make the shader parser 3.0 compliant are used in the disabled paths. There's even an "Emulation" value in winecfg which just confuses the user, since it doesn't work.
Perhaps.
We will need software shaders for a correct implementation of IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I don't really think OpenGL feedback mode is what we want here.
Maybe we should remove it for now, but keep the code somewhere(in the wiki maybe). If someone is extra-ambitious we can do something like Softwire/SwiftShader does. But I think ProcessVertices is a good oportunity to verify our vertex shader implementation.
Stefan Dösinger wrote:
Am Samstag 06 Januar 2007 22:25 schrieb Ivan Gyurdiev:
Stefan Dösinger wrote:
Now that almost everything is gone from drawPrimitiveDrawStrided we don't need a subfunction for calling drawStridedSlow/Fast any longer
I think while we're cleaning up things, all of software shaders should be removed.
There's tons of code in drawprim and *shader.c, which is disabled, doesn't work, and isn't on the right track if you ask me. None of the changes to make the shader parser 3.0 compliant are used in the disabled paths. There's even an "Emulation" value in winecfg which just confuses the user, since it doesn't work.
Perhaps.
We will need software shaders for a correct implementation of IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I don't really think OpenGL feedback mode is what we want here.
Maybe we should remove it for now, but keep the code somewhere(in the wiki maybe). If someone is extra-ambitious we can do something like Softwire/SwiftShader does. But I think ProcessVertices is a good oportunity to verify our vertex shader implementation.
I think it would be better to start from scratch rather than reuse what's currently there: you can't verify the current vertex shader implementation by adding a completely independent code path. You have to share parts of the processing to do that.
-
Ivan Gyurdiev -
Stefan Dösinger