Announcement

Collapse
No announcement yet.

"Soft" FP64/INT64 Implementations Merged To Mesa, Intel Driver Already Making Use

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

  • ms178
    replied
    Thanks for your work, gerddie! As you see there are still some R600 users out there that would appreciate the fruits of your labour. And I hope that your effort did not die alongside your HD 6870. Testing games with a HD5450 is a challange, though but I understand that investing into old hardware would be hard to justify if it is your personal money. Well, on the bright side, seeing you contribute to radeonsi would be also a great thing.

    Leave a comment:


  • gerddie
    replied
    Originally posted by ms178 View Post

    Thanks for the heads-up, I've just found the docs in this repo which describe a bit what his work is all about. As was mentioned in several R600 bug reports already, the SB optimizer has some serious issues. The goal of Gert's work seems to get rid of it alltogether. But will this work also be beneficial for performance? And does it mean we will see additional work for R600 in the radeon driver or in LLVM as well?
    Well, since it's me who is doing this I'd like to chime in: the goal would indeed be to get rid of sb in the end (although the current implementation still can make use of it). BUT, there is still a very long way to get anywhere near the current feature set of the current r600 driver. Also, since my HD 6870 died yesterday and I now only have a HD 5450, so even testing some of the more demanding games will be impossible right now, and it doesn't make much sense to buy another HD 6870 just for that, the now empty slot will more likely be filled with some radeonsi card. Even if someone would sponsor me another HD 6800 class card, I can't put that much time into this work. On the bright side, Dave actually send me some patches to enable the fp64 stuff, but given the state of the work, most of the piglits crash because there is no register allocator yet, and the ssa form of nir just counts the numbers up ...

    I don't do LLVM, AFAIK the r600 support has been removed in the latest versions.

    Leave a comment:


  • ms178
    replied
    Originally posted by xxmitsu View Post
    Hi, while we're still on the 'r600 page' .. particularly those that don't support hardware fp64, and that this implementation relies on NIR lowering, .... sorry for spilling the beans but, have you been aware of Gert Wollny's work related to r600 NIR backend: https://gitlab.freedesktop.org/gerdd...mmits/r600-nir ?
    Thanks for the heads-up, I've just found the docs in this repo which describe a bit what his work is all about. As was mentioned in several R600 bug reports already, the SB optimizer has some serious issues. The goal of Gert's work seems to get rid of it alltogether. But will this work also be beneficial for performance? And does it mean we will see additional work for R600 in the radeon driver or in LLVM as well?
    Last edited by ms178; 12 January 2019, 01:34 PM.

    Leave a comment:


  • Ignatiamus
    replied
    I waited years for this particular feature with my HD6000 series card, just to have games properly recognizing my OpenGL version. Sadly, now it's too late, because I have an RX 580 by now (not so sad).

    This is still very good for all those people out there using older hardware. The open source software stack devs are much friendlier to older hardware than the big companies usually areā€¦ e.g. discontinuing drivers etc. after ~1 year.

    Cheers

    Leave a comment:


  • DanL
    replied
    Originally posted by Slithery View Post
    Are you sure that you're interpreting the output of whichever command you are using correctly?
    Yeah s/he was, because glxinfo output isn't very clear. I'd like to see "glxinfo -B" (basic) be the default output and clearly label the compatibility profile:

    Code:
    OpenGL vendor string: X.Org
    OpenGL renderer string: AMD SUMO (DRM 2.50.0 / 4.15.0-43-generic, LLVM 6.0.0)
    OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.0.5
    OpenGL core profile shading language version string: 3.30
    OpenGL core profile context flags: (none)
    OpenGL core profile profile mask: core profile
    
    OpenGL version string: 3.0 Mesa 18.0.5
    OpenGL shading language version string: 1.30
    OpenGL context flags: (none)
    Instead of "OpenGL version string", it should say "OpenGL compatibility profile version string".

    Leave a comment:


  • mattst88
    replied
    This work is not for Sandybridge. Sandybridge cannot do GL 4.0 regardless of 64-bit support.

    Leave a comment:


  • treba
    replied
    Originally posted by man-walking View Post
    I'm not sure but...
    Code:
    $ glxinfo | grep "OpenGL version"
    OpenGL version string: 3.0 Mesa 18.3.1
    Correction, it's 3.0
    You'll want to use
    Code:
    glxinfo | grep "core profile version"

    Edit: ups, to slow

    Leave a comment:


  • man-walking
    replied
    Ah, when I checked the full output I did it too fast and didn't notice this:
    Code:
    OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.1
    OpenGL core profile shading language version string: 4.50
    Thank you

    Leave a comment:


  • Slithery
    replied
    You're looking at the wrong part, what's the output of...
    Code:
    glxinfo | grep "OpenGL core profile version"
    Last edited by Slithery; 10 January 2019, 12:32 PM.

    Leave a comment:


  • MuPuF
    replied
    Originally posted by man-walking View Post
    I'm not sure but...
    Code:
    $ glxinfo | grep "OpenGL version"
    OpenGL version string: 3.0 Mesa 18.3.1
    Correction, it's 3.0
    It's not, you are just looking at the OpenGL core profile. SNB should have OpenGL 3.3.

    Leave a comment:

Working...
X