Stefan Dösinger wrote:
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.
Sounds fun *g* ... I thought of generating Intel assembly code from the vertex shader bytecode on the fly, just like GLSL and ARB shaders are generated, using primarily SSE for doing the floating point computations (in situations where it brings an advantage), and directly referencing the memory at IWineD3DVertexShaderImpl->data,input,output (load constants, input data, store temporary values, store output data). Would something like that even be accepted in wine ?
I'm already 'experimenting' a bit, but as I don't have much time these days don't count on it to be finished within the next 3 months, or ever, after all I might also get so desperate with it and stop working on it altogether ... I've never written anything similar before.
The main reason for this mail is to know whether someone else is working on a solution for doing software vshaders already, and if so, rather invest the time in my other studies (I'm running behind there ...), before having two people work at the same thing.
On 12/01/07, Christoph Bumiller e0425955@stud3.tuwien.ac.at wrote:
Stefan Dösinger wrote:
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.
Sounds fun *g* ... I thought of generating Intel assembly code from the vertex shader bytecode on the fly, just like GLSL and ARB shaders are generated, using primarily SSE for doing the floating point computations (in situations where it brings an advantage), and directly referencing the memory at IWineD3DVertexShaderImpl->data,input,output (load constants, input data, store temporary values, store output data). Would something like that even be accepted in wine ?
I'm already 'experimenting' a bit, but as I don't have much time these days don't count on it to be finished within the next 3 months, or ever, after all I might also get so desperate with it and stop working on it altogether ... I've never written anything similar before.
The main reason for this mail is to know whether someone else is working on a solution for doing software vshaders already, and if so, rather invest the time in my other studies (I'm running behind there ...), before having two people work at the same thing.
How about something like R2VB?
Am Samstag 13 Januar 2007 21:37 schrieb H. Verbeet:
On 12/01/07, Christoph Bumiller e0425955@stud3.tuwien.ac.at wrote:
Stefan Dösinger wrote:
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.
Sounds fun *g* ... I thought of generating Intel assembly code from the vertex shader bytecode on the fly, just like GLSL and ARB shaders are generated, using primarily SSE for doing the floating point computations (in situations where it brings an advantage), and directly referencing the memory at IWineD3DVertexShaderImpl->data,input,output (load constants, input data, store temporary values, store output data). Would something like that even be accepted in wine ?
I'm already 'experimenting' a bit, but as I don't have much time these days don't count on it to be finished within the next 3 months, or ever, after all I might also get so desperate with it and stop working on it altogether ... I've never written anything similar before.
The main reason for this mail is to know whether someone else is working on a solution for doing software vshaders already, and if so, rather invest the time in my other studies (I'm running behind there ...), before having two people work at the same thing.
How about something like R2VB?
I think we can implement R2VB if we want it(it is an ATI hack) by just setting a VBO as a render target. The extensions imply that this is supposed to work, although the performance isn't guaranted to be optimal. I think the biggest issue with R2VB is Alexandre :-/
On 14/01/07, Stefan Dösinger stefan@codeweavers.com wrote:
How about something like R2VB?
I think we can implement R2VB if we want it(it is an ATI hack) by just setting a VBO as a render target. The extensions imply that this is supposed to work, although the performance isn't guaranted to be optimal. I think the biggest issue with R2VB is Alexandre :-/
Well, you can't set a VBO as rendertarget directly, but you can copy the FBO data into a PBO, which you can bind as a VBO. That's pretty legitimate in OpenGL. But I was wondering how hard it would be to use something like that for ProcessVertices.
Am Freitag 12 Januar 2007 20:06 schrieb Christoph Bumiller:
Stefan Dösinger wrote:
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.
Sounds fun *g* ... I thought of generating Intel assembly code from the vertex shader bytecode on the fly, just like GLSL and ARB shaders are generated, using primarily SSE for doing the floating point computations (in situations where it brings an advantage), and directly referencing the memory at IWineD3DVertexShaderImpl->data,input,output (load constants, input data, store temporary values, store output data). Would something like that even be accepted in wine ?
This is precicely the best way to do implement software shaders, if I understood things correctly, and this is what SoftWire / SwiftShader does. SoftWire is an open source project(C++), Transgaming hired its developer and development went on in a propritary way and is now known as SwiftShader. No idea if SwiftShader ever had any practical use though. It is a Software D3D rasterizer that is said to deliver approximately the performance of Intel integrated cards.
-
Christoph Bumiller -
H. Verbeet -
Stefan Dösinger