Direct3D 9 Support Stands A Chance Of Being Added To Mesa

[Veto]

yes
yes... and no. it would cause problems as there is only support for oss drivers, unless someone implemented this lib as dual in a sense of use this for oss and use wine gl implementation when non oss driver.

Also remember that the (official) open source Intel driver does not use Gallium3D. This D3D9 state tracker only has relevance for a limited niche of Wine users. I really hope the performance difference is worth maintaining it in both Mesa and Wine!

Now if we instead could standardise a Gallium3D-like low level API we could build low overhead D3D and OpenGl obsolescence layers upon, that would be of great benefit to _both_ driver developers and Wine developers. We could even call it OpenGl 5
:-)

[OneTimeShot]

Hmm.... We can't use S3tc compression or integer textures because of legal fears, but we are ok with a Microsoft API implementation?

Not expecting this to be merged. In any case - DX compatibility is "less exciting" now that we have native Steam support.

[Redshirt001]

I'm only interested if someone can get this working with binary, non-free drivers. Sure, with this you could get some interesting results with games that may not work terribly well now, but you're shutting out loads of other games, like native games, that require NVIDIA drivers or Catalyst drivers in order to get decent performance.
Also, one does have to hope that dx10/11 could be supported at some point, since the winehq mob don't seem too keen on doing that.
I'd also like some word on the legal consequences of essentially reverse engineering dx9. Is that what this state tracker is doing?

[justmy2cents]

Also remember that the (official) open source Intel driver does not use Gallium3D. This D3D9 state tracker only has relevance for a limited niche of Wine users. I really hope the performance difference is worth maintaining it in both Mesa and Wine!

Now if we instead could standardise a Gallium3D-like low level API we could build low overhead D3D and OpenGl obsolescence layers upon, that would be of great benefit to _both_ driver developers and Wine developers. We could even call it OpenGl 5
:-)

good point. forgot about this

standardizing galium for all and then have blob (nvidia, catalyst) loaded on demand if needed ... one could only wish for that and at the same time all drivers would support state trackers like this... hmmm, nah... reality is never perfect

[droste]

Hmm.... We can't use S3tc compression or integer textures because of legal fears, but we are ok with a Microsoft API implementation?

Not expecting this to be merged. In any case - DX compatibility is "less exciting" now that we have native Steam support.

1) As you said it's an API not a patented algorithm or anything like that (which shouldn't be patentable in the first place, but that's another discussion).
2) Both of your examples are supported by mesa (if you're speaking about s3tc and float textures)
3) D3D 10/11 was already merged and just removed because it was unmaintained and not fully working and not because it's a Microsoft API
4) Native steam support doesn't mean all games switch to OGL, especially not old games

[Anthony]

yes
yes... and no. it would cause problems as there is only support for oss drivers, unless someone implemented this lib as dual in a sense of use this for oss and use wine gl implementation when non oss driver. that would also bring the world of hurt since blobs would be inferior and at the same time leading developers believe direct3d is the way to go. not to mention it would put linux in low performer class, since oss performance would be max possible. if blobs implemented it, performance would get equal, but at the same time it would deprecate gl on whole lot of fronts
no clue about this one.
as far as i looked the code it is pretty straight forward
not sure about this one in whole

Cheers

But say I wanted to create a piece of software for a specific set of hardware.
Or if say in several years most drivers were gallium based, and we had a direct3d 13 tracker. Could we see native Linux direct3d games?

[justmy2cents]

Cheers

But say I wanted to create a piece of software for a specific set of hardware.
Or if say in several years most drivers were gallium based, and we had a direct3d 13 tracker. Could we see native Linux direct3d games?

lots of ifs here, not to mention few impossibles yes, but better question here "do you want that?", i know i don't

[asdfblah]

Has anyone talked to a Valve engineer about this? Are they interested in maintaining it? If not, why?
Or Oracle, or VMWare, or...

[artivision]

I have read several articles on the state tracker recently and I'd like to check if I'm understanding it right.

Someone has created a Direct3D implementation which runs upon Gallium. So Wine, rather than converting Windows Direct3D calls to Linux OpenGL ones, it instead converts them to the Linux Direct3D calls, saving a bit of overhead.

But could these calls be made from Linux directly? Could we have native Direct3D games? Could someone porting a Direct3D game from Windows to Linux, rather than converting to OpenGL, just use this state tracker instead? (Obviously Gallium drivers only)

Is there any extra overhead compared to OpenGL with Gallium?

How complex is the Direct3D state tracker? With OpenGL there are functions like glVertex3f, glBindTexture. Are these the sort of functions which the state tracker exposes? Did they create an implementation of every DirectX function?

When a graphics card supports "DirectX 10", what exactly does this mean? Are the DirectX functions somehow implemented in the card, so a state tracker somehow maps these functions to the card? What does it mean if a graphics card doesn't support DirectX 10 say?

Sorry for loads of questions - I'm not entirely sure how graphics cards work.

Friend, things are like this. With graphics you have 2 things: APIs and Shader_Models. APIs are high level languages and are useful because you need a standard way to write something. Shader_Models are important because you need a way to accelerate graphics on a GPU. So a GPU accelerates low level Shaders and not a certain API. The way to convert API data to Shaders is called State_tracker and it targets an Intermediate_representation_layer (IR or IL), then to HW. Once the data becomes valid IR or IL for a certain Shader_Model, then graphics will be produced. So D3D or OGL => Gallium or other IR, IL (via ST) => Low level unified driver and HW, APIs don't have low level access, no lower than IL, libD3D32 and libOGL32 are used before IL and not after. When with an active ST, data becomes Gallium assembly then you can make them AMD_IL if you want very fast, Like Gallium => LLVM fast. Also all D3D games have legacy support. They can work on a SM3 GPU even if thy are written with DX11.

[Alejandro Nova]

Also remember that the (official) open source Intel driver does not use Gallium3D. This D3D9 state tracker only has relevance for a limited niche of Wine users. I really hope the performance difference is worth maintaining it in both Mesa and Wine!

Remember that Intel free drivers were initially written in an era when Gallium3D was an afterthought, and was simply not ready. The Intel driver team has expressed they don't want to rewrite their driver for Gallium3D because there's no incentive to do so (a rewrite for the sake of it).

Well, here we have a powerful incentive. Merge it, ASAP. And sooner rather than later we'll see an Intel Gallium3D driver.