Gallium3D Nine Gets Numerous Improvements Ahead Of Next Mesa Release

[phoronix]

Phoronix: Gallium3D Nine Gets Numerous Improvements Ahead Of Next Mesa Release

Axel Davy who has been one of the prolific developers involved on the "Nine" Gallium3D state tracker for providing a basic Direct3D 9 implementation under Linux has sent in a set of 39 patches that he hopes to land in time for next month's Mesa release...

http://www.phoronix.com/scan.php?page=news_item&px=D3D9-Nine-Mesa-11.3-12.0

[artivision]

Any plans to add D3D10-11 support?

[Adriannho]

DRI_PRIME support for wine....WOW!!! This guy is freaking awesome.

artivision I was about to ask the same thing That would be so cool.

[mannerov]

DRI_PRIME support for wine....WOW!!! This guy is freaking awesome.

Well actually DRI_PRIME is supported by wine since it is supported by opengl.

DRI_PRIME was also supported by gallium nine at its release, and very shortly after the release was added the thread_submit option.

When you render on the same card than the card connected to the display, a lot of implicit synchronization is done by the kernel.
However these don't happen when the two cards are different.
Three years ago, some common api in the kernel was introduced for that (also known under the name 'dma-buf fences').

Unfortunately to this day intel still hasn't implemented the feature in their kernel. Thus DRI_PRIME suffers from lack of synchronization between the two cards, which forces either tearings or glitches.

The thread_submit option resolves the issue a different way: the driver waits in a separate thread that the card finishes rendering before submitting.
This can be seen as sort of explicit synchronization. However it means the buffer you want to send is not sent to the display server (Xorg/compositor) at the moment it is supposed to be sent. For Wayland egl for example, this is completly impossible, because the apps rely on messages sent to the compositor when doing eglSwapBuffer.

For X11 egl and glx, this could be ok to do something like thread_submit, but some apps should fail to work with it.

In the case of gallium nine, the window messages expected by apps, and the way apps access the buffers means that thread_submit can be used without issues.

Last information to add is that thread_submit is not just a workaround to the lack of cross device synchronization in the kernel. It is also a bit superior: When you have two cards,
you don't want one card to stall all its work waiting the other card has finished some rendering. thread_submit prevents that.

One issue however with gallium nine's thread_submit was that wine needs to do some work when creating a thread that will do some window calls to have it work properly.
Gallium nine was creating the thread itself, and thus in some multithreaded games, you could run into crash after some minutes of play.
Now it has introduced a new function to have wine create the thread, thus resolving the issue.

[mannerov]

Any plans to add D3D10-11 support?

No, but if you are motivated, you could start a new project for it.

[artivision]

No, but if you are motivated, you could start a new project for it.

Anyway, if I had the time I would start by reverse engineering VMware. I think they have a D3D10 state tracker. Then some WineD3D11 related work 'in progress' may help.

[Julius]

Sorry if this is a bit ignorant (long time Nvidia user), but how is the interoperability of this with the new AMDGPU Pro hybrid drivers? Will it just work, or do you need to switch drivers somehow?

[monohouse]

PRIME is a nice thing, I just read about it in the wiki, you can actually do the 3D work independently of the display output, even fancy thing like do the work in the different card and send the result back to the display out card, I like this ! hopefully in the future it will be possible to use several cards to do the 3D work

[smitty3268]

Sorry if this is a bit ignorant (long time Nvidia user), but how is the interoperability of this with the new AMDGPU Pro hybrid drivers? Will it just work, or do you need to switch drivers somehow?

This is inside the Mesa drivers, so the Pro hybrid drivers don't apply. (Except that they can share the same kernel driver bits, which is the hybrid part of the hybrid drivers)

[adler187]

Anyway, if I had the time I would start by reverse engineering VMware. I think they have a D3D10 state tracker. Then some WineD3D11 related work 'in progress' may help.

Just resurrect the old one: http://www.phoronix.com/scan.php?pag...tem&px=MTMyNDU