If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
No announcement yet.
Direct3D 10/11 Is Now Natively Implemented On Linux!
Secondly, there's a psychological issue, people who work for fun, or for a sense of doing the right thing often get less enthusiastic if money is involved, even very small sums. You actually end up with even less volunteers than before.
Yeah but I'm talking about features no one wanted to do in the first place but which everyone agrees are required for full functionality.
I have a general question concerning the Gallium infrastructure.
What makes a Gallium driver *capable* of running a general state tracker,
i.e. OpenCL, OpenVG, Cairo or this DirectX10+ st and other state trackers
that already exist or will exist in the (near?) future? Is this requirement different
from the bare G3D OpenGL driver?
Afaik the r300g driver is considered rather advanced and does shiny things already
- how close is it to a general Gallium driver? Or is it that such a driver simply cannot
not exist and would always require more or less new work to support new state trackers?
To be honest I feel completely lost here.
I'd really like to see a roundup about the current situation of state trackers and the drivers.
To answer you shortly. AFAIK the state_tracker uses different states of a graphic pipeline and the TGSI shader language to implement different things in e.g. a OpenGL or another state_tracker.
Every g3d hardware drivers should be able to handle TGSI shader language and different states common in a graphic pipeline.
So when you use a state_tracker, it just hooks itself to a hardware-driver able to use TGSI and different states. This will able different state_trackers work on different g3d hardware drivers.