Direct3D shader compiler infrastructure

H. Verbeet hverbeet at
Mon Mar 31 06:17:49 CDT 2008

On 31/03/2008, Stefan Dösinger <stefandoesinger at> wrote:
> Am Montag, 31. März 2008 08:54:18 schrieb H. Verbeet:
>  > Looks reasonable enough in general. I guess it would make sense to
>  > create some kind of "shader utilities" library that can be used from
>  > both wined3d and d3d9x.
> Right, that is my plan. Although I am not sure yet in which way wined3d would
>  use it. It might be best off by just parsing the asm tree itself.
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.

>  > You could in principle even move GLSL/ARB code
>  > generation in there, although that isn't required of course.
> Not really, because the GLSL/ARB code generator doesn't compile shaders, it
>  configures the GL pipeline. As such, it depends on many other things like the
>  textures that are bound, the vertex declaration, etc.
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.

More information about the wine-devel mailing list