53 Patches Published For Gallium3D's Direct3D 9 Support

[vitalif]

It's not true anymore.

Since Fedora wanted to ship Gallium Nine support, we made patches to have a DRI2 fallback. So it'll work with DRI2 (but there is a small perf hit)

Cool! Just checked it - Nine works again! Thank you!

As I understand it still misses some features (?), because for example Flatout 2 doesn't start when Nine is enabled with message "Failed to create effect: data/shaders/pro_static2x.sha", and if I copy native windows d3dx9_30.dll to flatout folder it starts but cars are black. Should I file a bug for this issue?

NFS Underground and Underground 2 also don't start with Nine with the following message:

../../../../../../src/gallium/drivers/r600/r600_state.c:1076:r600_init_depth_surface: Assertion `format != ~0' failed.

[mannerov]

Cool! Just checked it - Nine works again! Thank you!

As I understand it still misses some features (?), because for example Flatout 2 doesn't start when Nine is enabled with message "Failed to create effect: data/shaders/pro_static2x.sha", and if I copy native windows d3dx9_30.dll to flatout folder it starts but cars are black. Should I file a bug for this issue?

NFS Underground and Underground 2 also don't start with Nine with the following message:

../../../../../../src/gallium/drivers/r600/r600_state.c:1076:r600_init_depth_surface: Assertion `format != ~0' failed.

The first flatout message is due to missing d3dx9_30.dll functions. That part is entirely in wine, and nine only replaces d3d9.dll
We solved a lot of black thing issue recently, but there are some remaining ones. Probably going to be fixed in some time.

For NFS, it means it uses a depth stencil format without checking its support first, but that the card doesn't support it.
That means all vendors are supporting the format and that NFS doesn't even check.
Checking the formats r600 actually support, I think I know what common format NFS could be trying to use. it's a format
radeonsi support, so it was more difficult to notice.
What we map for the d3d9 depth format to gallium depth format doesn't matter that much, because applications are not allowed
to read the content with a pointer (or write to it). That's why wine for example maps a lot of depth formats to gl formats that aren't
really matching, but it works.
If you are willing to try out more, I can send you a patch, and you would tell me if it fixes it for you.

[vitalif]

The first flatout message is due to missing d3dx9_30.dll functions. That part is entirely in wine, and nine only replaces d3d9.dll
We solved a lot of black thing issue recently, but there are some remaining ones. Probably going to be fixed in some time.

For NFS, it means it uses a depth stencil format without checking its support first, but that the card doesn't support it.
That means all vendors are supporting the format and that NFS doesn't even check.
Checking the formats r600 actually support, I think I know what common format NFS could be trying to use. it's a format
radeonsi support, so it was more difficult to notice.
What we map for the d3d9 depth format to gallium depth format doesn't matter that much, because applications are not allowed
to read the content with a pointer (or write to it). That's why wine for example maps a lot of depth formats to gl formats that aren't
really matching, but it works.
If you are willing to try out more, I can send you a patch, and you would tell me if it fixes it for you.

Thanks, send the patch to vitalif %at% mail ru, I'll check it

[V10lator]

..except native 2d acceleration and support for not tearing. Glamor is not enough.

There is no native 2d hardware on any modern AMD GPUs.

He knows, he was simply arguing that glamor sucks so much to not even be considerated "acceleration"

What? My 2d is butter smooth and tear-free with glamor, I even use it instead of EXA with r600g. Not using a compositor is your own fault: Compositing is faster than no compositing on modern hardware and Wayland will require it.

[darkbasic]

There is no native 2d hardware on any modern AMD GPUs.

He knows

What? My 2d is butter smooth and tear-free with glamor, I even use it instead of EXA with r600g. Not using a compositor is your own fault: Compositing is faster than no compositing on modern hardware and Wayland will require it.

Since when do you use glamor? I used it long enough to know why lots of people get hives when they hear "glamor". Glamor was a completely different beast at the early radeonsi stages and some hatred developed towards it, even if it works fine now

[curaga]

Not using a compositor is your own fault: Compositing is faster than no compositing on modern hardware and Wayland will require it.

Yes, it is my choice. Under X compositing means an extra layer of software, an extra memory copy before display. Under Wayland this is not so, no extra copy there, but Wayland won't be ready for another five years (gut feeling, happy to be proven wrong).

We're extremely lucky now that we can pick between *multiple* open-source vendors based on smaller criteria like this. My next GPU will be an Intel since it doesn't need a compositor under X to not tear. If hw A requires less software than hw B, everything else being equal, I will buy (and recommend to others) hw A

(I'm also disliking everything GCN-based because of the choice to go with LLVM - it is greatly slower to compile than r600sb which in turn is greatly slower than the without-sb compiler. Not to mention a huge dependency, huge on disk, and in RAM. Stutters in games due to compile pauses suck, and glamor means you also have those stutters in 2d use.)

[Ansla]

My next GPU will be an Intel since it doesn't need a compositor under X to not tear.

Are you sure Intel hardware does not need compositing for tear-free? Intel devs seem to think otherwise (http://www.phoronix.com/forums/showt...ht=#post346637).

And as far as I know all video cards launched after M$ released Windows Vista are designed to work only with compositing as that's how Windows is going to use it.

[JS987]

Are you sure Intel hardware does not need compositing for tear-free? Intel devs seem to think otherwise (http://www.phoronix.com/forums/showt...ht=#post346637).

And as far as I know all video cards launched after M$ released Windows Vista are designed to work only with compositing as that's how Windows is going to use it.

Intel driver has built-in compositor which is disabled by default.

Option "TearFree" "boolean"
Disable or enable TearFree updates. This option forces X to perform all rendering to a backbuffer prior to updating the actual display. It requires an extra memory allocation the same size as a framebuffer, the occasional extra copy, and requires Damage tracking. Thus
enabling TearFree requires more memory and is slower (reduced throughput) and introduces a small amount of output latency, but it should not impact input latency. However, the update to the screen is then performed synchronously with the vertical refresh of the display
so that the entire update is completed before the display starts its refresh. That is only one frame is ever visible, preventing an unsightly tear between two visible and differing frames. Note that this replicates what the compositing manager should be doing, however
TearFree will redirect the compositor updates (and those of fullscreen games) directly on to the scanout thus incurring no additional overhead in the composited case. Also note that not all compositing managers prevent tearing, and if the outputs are rotated, there will
still be tearing without TearFree enabled.

Default: TearFree is disabled.

[V10lator]

He knows

Then I really don't understand what he meaned with "native 2d".

Since when do you use glamor? I used it long enough to know why lots of people get hives when they hear "glamor". Glamor was a completely different beast at the early radeonsi stages and some hatred developed towards it, even if it works fine now

I tried it a few times before it got included into xorg and am using it on my "stable" machines since xorg 1.16, so I remeber the "different beast" but as you said: times change.

Intel driver has built-in compositor

So he wants to avoid using a compositor by using a compositor? Sounds logical...

[darkbasic]

I tried it a few times before it got included into xorg and am using it on my "stable" machines since xorg 1.16, so I remeber the "different beast" but as you said: times change.

Yes, but you didn't *HAVE* to use it like radeonsi users. Also beware that even before the inclusion it got quite decent in recent times.