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.

Right now gamers don't use Linux. They don't cause their games are running DirectX 9 minimum and it runs slow. But offer nearly the same performance as Windows and lots of people will switch. Developers will take notice and future games will be made using OpenGL for Linux. But all those old games will never see a native port to Linux.

As it is I doubt developers are happy to see Directx 11.2 exclusive to Windows 8.1. So eventually we'll see OpenGL replacing DirectX over time anyway. But not all of them will.

Erm I think that's a bit of a stretch there... Once someone knows how to program in d3d9, how trivial is it to write OpenGL? What (monetary) incentives are there to do so?
Remember that we're still talking about the case where d3d9 runs natively on Linux at near same performance, and microsoft still has deep pockets and lots of patents, hence both carrots (such as freebie dev kits and courses) and sticks to keep smaller developers in line. They don't necessarily need to use them, waving them around is enough if you look at their history.
As for dx11.2 I believe microsoft is hedging on the success of the xboxone, still a big unknown.

Originally Posted by BO$$

Right now it's so much easier and less error prone to just boot windows when you wanna play.... For many years nothing will change in Linux when it comes to games.

First half of the sentence, which boils down to unhealthy focus on personal short-term convenience, is part of the reason for the second half.

[...]The problem is will this state tracker see continued development? If nobody works on it, then it'll be left for dead. Then there's Wine, who seems to hate the idea cause it's Linux only. CodeWeavers basically runs Wine and they do make CrossOver. So it's against their business model I think?

sounds nice, and now that there is decent performance for amd users i hink it might hold ... a little bit longer.
actually i hope that the DX10/11 code to be revived. it would be a complete set for DX. aand maybe steam will get interested in the gallium drivers aswell. So AMD will have really no purpose for their blob anymore except for some heavy duty workstation loads. But then they really can focus on the fireGL without the need to test the radeon devices.
sry bridgman if im talking crap again

I wonder why some don't consider this state tracker "native". The fact it's used on WINE has nothing to do with this support being native or not, but with the fact there are no native apps using D3D. I agree with someone who said it's not a good idea because is a tech dependent on MS, but saying it's not native is wrong. Gallium drivers work based on state trackers, and this D3D9 support is as native as OpenGL 3.0 is.

I'm probably not getting the whole picture since getting driver level native D3D (9c) compatibility and the 400000% increase in the # of supported games that it would bring is too huge of a deal to be worth just 7 pages.

It's only "native", if you consider WINE to be native. Which it sort of is....

Originally Posted by mrugiero

I wonder why some don't consider this state tracker "native". The fact it's used on WINE has nothing to do with this support being native or not, but with the fact there are no native apps using D3D

The D3D API isn't completely self-contained. It uses various windows APIs and structures that windows provides for it. In linux, those are reimplemented as part of the WINE project, so anything that uses this is going to have to link into wine to get that support. To make it "native" outside of wine, you'd need to modify it to start using glx or egl, for a start, which should be possible but then it's not entirely D3D anymore but some hybrid API.

It's only "native", if you consider WINE to be native. Which it sort of is....

Really? Because it compiles into a linux native library that loads linux native driver modules that speak to the linux kernel through a linux native libdrm. Is libGL.so not native because wine dlopen's it? Because that's the exact same thing we do.

Edit because apparently it's trendy:

Originally Posted by smitty3268

The D3D API isn't completely self-contained. It uses various windows APIs and structures that windows provides for it. In linux, those are reimplemented as part of the WINE project, so anything that uses this is going to have to link into wine to get that support. To make it "native" outside of wine, you'd need to modify it to start using glx or egl, for a start, which should be possible but then it's not entirely D3D anymore but some hybrid API.

I suggest you learn how it works before you go ahead and make sweeping statements about it that are flat out lies.
In fact, the first thing I did was map X11 directly to IDirect3D9, exposing the exact same API as on Windows, so I could test the setup without wine.

Really? Because it compiles into a linux native library that loads linux native driver modules that speak to the linux kernel through a linux native libdrm. Is libGL.so not native because wine dlopen's it? Because that's the exact same thing we do.

Yeah, that's my point. I basically consider apps compiled with wine-lib to be native, but i know a lot of people do not and throw hissy fits if you even attempt to explain such a view to them. So it depends on what a person defines as native.

I suggest you learn how it works before you go ahead and make sweeping statements about it that are flat out lies.
In fact, the first thing I did was map X11 directly to IDirect3D9, exposing the exact same API as on Windows, so I could test the setup without wine.

Ouch. Ok, you're right, i didn't actually look at the code and was trying to go off what i thought. However, doesn't this go against what was earlier said that native apps couldn't run against it? Is there some other reason this is true? I confess to not really understanding the commit you linked to, because it's just a big deletion of the wine code, so it doesn't really show how you achieved the support without it and i'm not familiar enough with mesa/graphics code to find that on my own.

However, doesn't this go against what was earlier said that native apps couldn't run against it?

The point is that native applications _can_ do that, but currently there are no such applications.
So the only way to use this _right now_ is through wine. And this should not surprise anyone, because until recently there was no native direct3d 9 on linux ;-)