Direct3D shader compiler infrastructure

Stefan Dösinger stefandoesinger at gmx.at
Mon Mar 31 06:31:49 CDT 2008


Am Montag, 31. März 2008 13:17:49 schrieb H. Verbeet:
> Our current intermediate representation is essentially a list of
> SHADER_OPCODE and SHADER_OPCODE_ARG elements. We probably want to move
> the bytecode parsing into the shader library and then generalize the
> intermediate representation a bit. It would also mean separating
> parsing and code generation a bit more than it currently is.
Yes, this is my idea.

> It doesn't compile the shaders, but it certainly generates shader
> source. I'm not sure what it does in terms of configuring GL state?
> Wrt state like vertex declarations, bound textures etc, there's no
> reason we can't pass that to the code generator (and it's probably a
> good idea to pass that state a bit more explicitly anyway). At this
> point there isn't a real reason to move shader code generation into
> this library, but it should certainly be possible.
You're right, we could just pass the GL state to the shader lib. Generating a 
shader with ATI_fragment_shader or NV_texture_shader requires opengl calls 
though, so I don't think it is desireable to move that to the shader utility 
lib.

How do we call this library? wineshader.dll?



More information about the wine-devel mailing list