WINE 1.1.21 Starts On Shader Model 4 Support

[whizse]

[...] Did you try gl2benchmark too?

Tried it now. In the first test, there's an obvious problem as the lens isn't rendered, filed a bug about it.

As for the rest, it seems to work okay. Not very fast, but not surprising on this hardware (X4500HD).

[whizse]

The native one. But yeah, guess we're off topic here.

[Kano]

Did you use wine or the native Linux binary? As you are in the wine thread...

[whizse]

No, not yet, but I plan to.

[Kano]

Wow, it started, well the look is not really what i a used to. Did you try gl2benchmark too?

[whizse]

Kano, if you're interested, it's now possible to run Zero Ballistics using Mesa. This is what it looks like:



Possible to run, but not really playable still, it's a little bit of progress.

I filed bug 21783 about this.

[NeoBrain]

You could move to a Vista solution: do DirectX 10, and do the old versions on top of that. That's what they do, right ?

It also seems you put a lot of emphasis to porting to proprietary platforms. Great, but I am not interested ... You should see what your users are, I think. And hopefully plan for the next gen free desktop rather than try to fight it (at which point I think they won't care and will use virtualzation instead, which I assume will have decent 3D support by then).

I don't think that everyone likes to only get 50% of the performance he'd get with a binary driver (esp. if one pays 150 euros on it), so there will always be people who use fglrx. Apart from that, we have EVERYONE using NVIDIA graphics cards, who are forced to use their binary blob (and please don't point me to nouveau; it's stable and good and stuff, but it's 3D support is nowhere near to even working for bigger games).
About implementing DX 7/8/9 with DX 10, it would be the same again as implementing a DirectX state tracker. Microsoft was only able to do that because they have WAY more employees to do that job, whereas we have "only" got a dozen of people working on D3D stuff.

As a side note, support for OSS drivers (i.e. radeon) in Wine is comming along at the moment; I don't know the specifics about what else is missing to make them work, but starting with GLSL support in radeon was definetely a huge step forward.

[remm]

By the way, you're oversimplificating (does that word exist?) the G3D pipeline a bit. We'll still need a wrapper around the Direct3D state tracker, as the Direct3D API isn't compatible with Linux. Also, WineD3D supports everything from (at least) Direct3D 7 to Direct3D 9 (10?). The Direct3D state tracker will need the same level of abstraction as we have it today.

You could move to a Vista solution: do DirectX 10, and do the old versions on top of that. That's what they do, right ?

It also seems you put a lot of emphasis to porting to proprietary platforms. Great, but I am not interested ... You should see what your users are, I think. And hopefully plan for the next gen free desktop rather than try to fight it (at which point I think they won't care and will use virtualzation instead, which I assume will have decent 3D support by then).

[whizse]

Ok, let's get into specific stuff then: http://bugs.winehq.org/show_bug.cgi?id=10495

The person is providing the patch, and regularly updates it. The patch is included downsteam in Fedora, with no problems. You say you are not including it because you'd have to support it, but actually Wine support for most "supported" sound systems is non existent, so what difference would it make other than landing you an additional contributor ?

Adding pulse to Wine would probably also mean that the esd backend could be replaced. I very much doubt there's anyone prefering to use esd over pulse anyway.

[NeoBrain]

Then it will be the same for any graphics overhaul, apparently. Exactly why is it nice to do something like:
DX 9 wrapper -> Wine3D -> OpenGL -> DRI driver -> graphics card
rather than:
DX 9 state tracker -> Gallium driver -> graphics card
If some people show up with that, I suppose they will be handled the same as the guy above

The support question you find at the pulseaudio backend is just one point about using G3D in Wine. Basically, it's not easy to "simply add" another graphics backend, so we'd need to completely replace the currently working quite good (apart from the glitches) with one that'll be broken for most things for the next few years (just like our current graphics stack...).
Another reason was that Gallium doesn't run on Macs or BSD, so we'd need to maintain the "old-fashioned" backend anyways for portability (especially since binary drivers don't support G3D either).

Generally speaking is one of the hardest part of reimplementing Direct3D the "little details" that need to be taken care of. A G3D driver would have to deal with these ones, too, so we wouldn't gain anything from it. Investing time in fixing current bugs in Wine is much more effective IMO.


By the way, you're oversimplificating (does that word exist?) the G3D pipeline a bit. We'll still need a wrapper around the Direct3D state tracker, as the Direct3D API isn't compatible with Linux. Also, WineD3D supports everything from (at least) Direct3D 7 to Direct3D 9 (10?). The Direct3D state tracker will need the same level of abstraction as we have it today.