Announcement

Collapse
No announcement yet.

53 Patches Published For Gallium3D's Direct3D 9 Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • andy_v
    replied
    Originally posted by gutigen View Post
    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).

    Leave a comment:


  • gutigen
    replied
    Hmmm... so how can I compile Wine with DRI2 fallback support? Atm I get DRI3 error during compilation (compiling from this pkgbuild on Arch).
    Last edited by gutigen; 10 January 2015, 08:40 AM.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by bridgman View Post
    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
    Last edited by darkbasic; 10 January 2015, 08:37 AM.

    Leave a comment:


  • mannerov
    replied
    Originally posted by curaga View Post
    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)

    Leave a comment:


  • curaga
    replied
    Originally posted by mannerov View Post
    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.

    Leave a comment:


  • mannerov
    replied
    Originally posted by curaga View Post
    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

    Leave a comment:


  • curaga
    replied
    Originally posted by TAXI View Post
    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.

    Leave a comment:


  • bridgman
    replied
    Originally posted by darkbasic View Post
    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

    Leave a comment:


  • darkbasic
    replied
    Originally posted by TAXI View Post
    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.

    Leave a comment:


  • V10lator
    replied
    Originally posted by darkbasic View Post
    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.

    Originally posted by JS987 View Post
    Intel driver has built-in compositor
    So he wants to avoid using a compositor by using a compositor? Sounds logical...

    Leave a comment:

Working...
X