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