Heading towards a fixed function pipeline replacement
Stefan Dösinger
stefan at codeweavers.com
Sun Mar 2 13:52:34 CST 2008
Hi,
Due to the bad weather I had some spare hacking time this weekend, and I've
done some work and investigation on a fixed function pipeline replacement.
The product of that is a hacky fixed function pipeline replacement via
GL_ATI_fragment_shader(*).
Functionality wise the code is doing pretty good, it should support everything
the current GL_ARB_texture_env_combine supports on ATI cards, although I
didn't test it much yet and it is most likely buggy. However,
integration-wise it is a disaster at this point, as I've focused on the GL
functionality for now.
However, I have some roadmap for integrating this in Wine now. Essentially I'm
going to modify the state table and shader backends a bit:
-> Make the state table a property of the shader model: Each pipeline
implementation has its own state dependencies and ways to load states, so it
is pointless to use one static table. The table will remain static, but there
will be multiple tables, selected at device creation time
-> As a consequence, make the current "none" shader backend a backend for the
current fixed function state table
-> Different state implementations will be able to borrow code from each
other. E.g, the ATI_fragment_shader backend can borrow vertex processing from
the fixed function implementation or GL_ARB_*_program
-> The current "fixed function" state table will still be able to handle d3d
shaders of all kinds, at least for now. Somewhen later we might want to split
fixed function and shaders up, so that whenever we have shaders we use them
for fixed function processing too. But for now we still have the problem that
e.g. GLSL has horribly slow shader compilation performance.
On top of this work the mentioned SoC project to write a vertex shader
replacement pipeline might be doable because the general infrastructure is
there, and only the shader generator is needed.
Feel free to comment,
Stefan
(*) Why this odd extension and not GLSL? We'll want it at some point anyway
for better support of r200 cards(radeon 8500-9250), and as a counterpart to
the GL_NV_register_combiner code on nvidia cards. GLSL has a few other tricky
aspects, like per shader uniforms, so this extension is easier for the start.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0032-WineD3D-Add-GL_ATI_fragment_shader.patch
Type: text/x-diff
Size: 9680 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20080302/75b36fa5/attachment-0001.patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0033-WineD3D-Fixed-function-fragment-processing-with-GL_.patch.bz2
Type: application/x-bzip2
Size: 7600 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20080302/75b36fa5/attachment-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20080302/75b36fa5/attachment-0001.pgp
More information about the wine-devel
mailing list