Lately we've been working a lot on Gallium but we haven't been publicly talking about it enough. I, personally, spent a considerable amount of time last week coming up with my strategy for the inevitable monster invasion. In general I always thought that if, sorry, "when" the monsters attack I'd be one of the very first ones to go on account of my "there's a weird noise coming from that pitch black spot over there, I better check it out" tendency. Obviously that's not ideal, especially if the need to repopulate the world arises; I just really feel like I should be present for that. In conclusion I'll quickly go over some things we've been doing with Gallium. Admittedly that wasn't one of my best transitions.
There are three new major APIs that we want to support in Gallium. OpenCL 1.0, DirectX 10.x and DirectX 11. DirectX 10.x was somewhat prioritized of late because it's a good stepping stone for a lot of the features that we wanted.
Two of my favorites were the geometry shaders and new blending functionality. I want to start with the latter which Roland worked on because it has immediate impact on Free Software graphics.
One of the things that drives people bonkers is text rendering. In particular subpixel rendering, or if you're dealing with Xrender component alpha rendering
Historically both GL and D3D provided fixed-function blending that provided means of combining source colors with the content of a render buffer in a number of ways. Unfortunately the inputs to the blending units were constrained to a source color, destination color or constants that could be used in their place. That was unfortunate because the component alpha math required two distinct values: the source color and the blending factor for destination colors (assuming the typical Porter&Duff over rendering). D3D 10 dealt with it by adding functionality called dual-source blending (OpenGL will get an extension for it sometime soon). The idea being that the fragment shader may output two distinct colors which will be treated as two independent inputs to the blending units.
Thanks to this we can support subpixel rendering in a single pass with a plethora of compositing operators. Whether you're a green ooze trying to conquer Earth or a boring human you have to appreciate 2x faster text rendering.
Geometry shaders introduce a new shader type, run after the vertices have been transformed (after the vertex shader), but before color clamping, flat shading and clipping.
Along the support for geometry shaders we have added two major features to TGSI ("Tokenized Gallium Shader Instructions", our low level graphics language).
The first one was support for properties. Geometry shaders in Gallium introduced the notion of state aware compile. This is because compilation of a geometry shader is specific to, at the very least, the input and output primitive they respectively operate on and output. We deal with it by injecting PROPERTY instructions to the program as so:
GEOMPROPERTY GS_INPUT_PRIMITIVE TRIANGLESPROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIP
(rest of geometry shader follows)
The properties are easily extendable and are the perfect framework to support things like work-group size in OpenCL.
The second feature is support for multidimensional inputs in shaders. The syntax looks as follows:
DCL IN[][0], POSITION
DCL IN[][1], COLOR
which declares two input arrays. Note that the size of the arrays is implicit, defined by the GS_INPUT_PRIMITIVE property.
It's nice to see this framework progressing so quickly.
Summing up, this is what yin yang is all about. Do you know what yin yang is? Of course you don't, you know nothing of taoism. Technically neither do I but a) it sounds cool, b) I've been busy coming up with a "monster invasion" contingency plan, so couldn't be bothered with some hippy concepts, c) the previous two points are excellent.
11 comments:
what ? no screenshot ?
I'm deeply disappointed :(
Here is your screenshot. Happy?
The Wine folks will be happy about the DX stuff!
I don't knwo if the Wine folks will use it. That would mean 2 different path, one for Gallium platforms, one for the others (Apple, NVIDIA Linux, etc.)
@Santiago: I think shamaz wants a screenshot of TGSI multidimensional inputs, not a screenshot from an invading monster.
You should definitely blog more often, I want to hear more about invading monsters :D
Is it legal to write open source D3D drivers? I would suspect that MS have written something in the EULA to prevent that? Or can't MS prohibit that?
NVidia on Linux already uses Gallum ne? I certainly know that it does on AROS.
Also, I agree with the more blogging. You're doing really amazing work, but us poor users are left with biannual teasers without much knowledge of where the project's at most of the time :(
I know that there is a c++ state tracker for direct3D9. I may be wrong, but there is no COM interface to access it, only c++.
You can get an eye on it at :
http://cgit.freedesktop.org/~jsindholt/mesa/
and especially :
http://cgit.freedesktop.org/~jsindholt/mesa/tree/src/gallium/state_trackers/nine?h=gallium-nine
Maybe it can help on implementing Direct3D 10/11
@The Girl,
You probably could not use it on a windows platform but that's not the purpose of the project.
From a programming point of view they are just reimplementing all the interfaces of Direct3D the code behind that is all original so not copyrighted.
Interfaces cannot be copyrighted. Otherwise the samba project would have been dead a long time ago.
The only thing Microsoft could do is stop you from calling it DirectX or Direct3D.
In an awesome episode of Stille post, some German websites are now using this blog post as a source for the headline "DirectX to come to Unix/Linux systems soon?".
If you speak German, check out the horrible fail. You've got to love the tubes...
I do want to know if there is some OpenCL implementation done in some in-house tree or it's just planned.
Where can I find more about this progress? I do want to help getting OpenCL working.
Post a Comment