53 Patches Published For Gallium3D's Direct3D 9 Support

[bridgman]

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.

Also...

(a) initial exa acceleration for radeonsi would probably have been iffy for a while anyways because we would have had to start from scratch with both the exa code and the hand-written shaders... feeling was that even with glamor's limitations at the time the performance wouldn't be much different from an early EXA implementation

(b) as agd5f and others said, the reason for choosing glamor was that it had the potential to accelerate more of the drawing operations being done today than exa and deliver better overall performance

[curaga]

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

Direct code, ie not GL shaders. Written in the native asm. It avoids the compile stutter and extra cpu use.

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

Intel's approach to tearfree is less efficient than radeon's, but it's still more efficient than a standalone compositor program.

[mannerov]

Direct code, ie not GL shaders. Written in the native asm. It avoids the compile stutter and extra cpu use.



Intel's approach to tearfree is less efficient than radeon's, but it's still more efficient than a standalone compositor program.

You can still choose to contribute patches to resolve the compile stutter issue.
I guess all shaders would have to be compiled at the initialisation of glamor.
Also perhaps you can make use of GL_ARB_separate_shader_objects, which allows, like for d3d, to use a vertex shader with several pixel shaders and vice versa without having to link again (no recompilation), but I don't think that's the problem of glamor

[curaga]

You can still choose to contribute patches to resolve the compile stutter issue.

That would involve rewriting LLVM. Hardly a job for one person, even if I cared enough & had such hw.

I guess all shaders would have to be compiled at the initialisation of glamor.
Also perhaps you can make use of GL_ARB_separate_shader_objects, which allows, like for d3d, to use a vertex shader with several pixel shaders and vice versa without having to link again (no recompilation), but I don't think that's the problem of glamor

Compiling in the GL sense helps nothing, because the driver does a separate compile on first use. That is the cause of stutter.

[mannerov]

That would involve rewriting LLVM. Hardly a job for one person, even if I cared enough & had such hw.



Compiling in the GL sense helps nothing, because the driver does a separate compile on first use. That is the cause of stutter.

Are you really sure it's the driver ?
Wit gallium Nine and radeonsi, I really don't the the impression it does recompile at first use, but rather that everything is compiled at start of the program (which is what debug info says)

[darkbasic]

Also...

(a) initial exa acceleration for radeonsi would probably have been iffy for a while anyways because we would have had to start from scratch with both the exa code and the hand-written shaders... feeling was that even with glamor's limitations at the time the performance wouldn't be much different from an early EXA implementation

(b) as agd5f and others said, the reason for choosing glamor was that it had the potential to accelerate more of the drawing operations being done today than exa and deliver better overall performance

I'm fine with the glamor choice, but why the hell did you have to wait for Intel (Keith Packard) to fix it? You should have been writing the EXA code anyway if it wasn't for glamor, so why not fixing at least the bigger glamor bottlenecks? Or at least giving your users some fallbacks in the meantime... Intel already had their glamor fallbacks for their driver since ages, and they didn't even need it because they already had both EXA and SNA for daily use

[gutigen]

Hmmm... so how can I compile Wine with DRI2 fallback support? Atm I get DRI3 error during compilation (compiling from this pkgbuild on Arch).

[andy_v]

Hmmm... so how can I compile Wine with DRI2 fallback support? Atm I get DRI3 error during compilation (compiling from this pkgbuild on Arch).

The PKGBUILD seems a little outdated. I'm no expert, mind you, but what I did to get it to build was:
* replaced lines containing '../$pkgname/configure --with-d3dadapter9 \' with '../$pkgname/configure --with-d3dadapter --with-d3dadapter-dri2-fallback \'
* added 'dri2proto' to makedepends (without it you get an error complaining about 'dri2tokens.h' being missing)
* I also added 'dri3proto' and 'presentproto' to makedepends (I'm not sure if these packages are actually required, I was tired and wanted wine to actually build without throwing errors and failing after 15+ minutes of compiling)

Also, you could remove either line 42 or 52, because they seem to contain the same thing (libxcomposite and lib32-libxcomposite).

[mannerov]

Hmmm... so how can I compile Wine with DRI2 fallback support? Atm I get DRI3 error during compilation (compiling from this pkgbuild on Arch).

You are probably missing dri3 headers. The wine build is not yet perfect, and the configure phase should be improved, for example to tell you you need these headers.

[gutigen]

The PKGBUILD seems a little outdated. I'm no expert, mind you, but what I did to get it to build was:
* replaced lines containing '../$pkgname/configure --with-d3dadapter9 \' with '../$pkgname/configure --with-d3dadapter --with-d3dadapter-dri2-fallback \'
* added 'dri2proto' to makedepends (without it you get an error complaining about 'dri2tokens.h' being missing)
* I also added 'dri3proto' and 'presentproto' to makedepends (I'm not sure if these packages are actually required, I was tired and wanted wine to actually build without throwing errors and failing after 15+ minutes of compiling)

Also, you could remove either line 42 or 52, because they seem to contain the same thing (libxcomposite and lib32-libxcomposite).

Native Direct3D 9 is active.

Thank you!

Perhaps it would make sense to update those pkgbuilds for Nine? If maintainer or someone related reads this ofc.