Announcement

Collapse
No announcement yet.

Mesa 19.2 Picks Up The Radeon R300~R500 Series On-Disk OpenGL Shader Cache

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

  • Mesa 19.2 Picks Up The Radeon R300~R500 Series On-Disk OpenGL Shader Cache

    Phoronix: Mesa 19.2 Picks Up The Radeon R300~R500 Series On-Disk OpenGL Shader Cache

    Last week an on-disk GLSL shader cache was proposed for the vintage "R300g" open-source Gallium3D driver for this OpenGL code supporting through the Radeon X1000 (R500) series. That shader cache support has now been merged into Mesa 19.2...

    http://www.phoronix.com/scan.php?pag...he-Merged-19.2

  • prenex
    replied
    Originally posted by HyperDrive View Post
    I guess not. OpenArena crashes quite spectacularly at startup with a shader compilation error. Looks like it's requesting an OpenGL 3.2 core context and falling back to an OpenGL 2 context, but the shader fails to compile anyway (maybe it's too complex for the hardware?). In any case, Nexuiz runs fine (albeit slowly).
    I was happily playing Urban Terror (also an ioquake game) on my Mobility Radeon Xpress 200M for testing and get very good FPS - it was a slideshow before the other performance regression fix though (I was the bisecting and reporting guy). Of course I doubt it uses complex shaders and I guess no shaders at all maybe...

    EDIT: Actually I have a version of Godot 3.1 that starts up on my machine properly. Maybe something there can give a performance testing for shader caching??? Actually there my problem was that some shaders were "too long" for the hardware so I eliminated the generated sky shader for it to start... Even some of the material test demos ran from Godot 3.1 as their renderer is GLES 2.1 now once again if you set that! I can upload my hacked version to github or somewhere if anyone is interested in running the new Godot on these old cards...
    Last edited by prenex; 06-17-2019, 06:38 PM.

    Leave a comment:


  • HyperDrive
    replied
    Originally posted by HyperDrive View Post
    EDIT: It seems that ioquake3 has an OpenGL 2.x renderer. Maybe OpenArena is a good benchmark…?
    I guess not. OpenArena crashes quite spectacularly at startup with a shader compilation error. Looks like it's requesting an OpenGL 3.2 core context and falling back to an OpenGL 2 context, but the shader fails to compile anyway (maybe it's too complex for the hardware?). In any case, Nexuiz runs fine (albeit slowly).

    Leave a comment:


  • Grogan
    replied
    I don't see what trying to benchmark that would achieve. It's more of a feely thing, as it depends on circumstances.

    All I know is that whenever I change my Mesa and/or LLVM, shaders get recompiled when games are first used. What I do is load levels, wander and pan around for a bit until performance improves, then quit the game. On subsequent runs performance is better yet.

    P.S. R9 380 Tonga hardware here, I don't mean to imply that I have tested R300-500 series.
    Last edited by Grogan; 06-12-2019, 03:24 PM.

    Leave a comment:


  • Grogan
    replied
    Originally posted by yurikoles View Post
    I'm wannabe-mesa-dev here, but this low-level C code looks hard to me even with mine 8 years of Mobile Development experience.
    You caused some very useful discussion on the mesa-git AUR PKGBUILD that I'm using. It helped me understand WTF was going on with the llvm build dependency in that PKGBUILD. (yay forcing llvm 9 minimal-git... solution: don't do that)

    At first I thought that was right, as usually you do want a newer llvm for mesa devel but in this case llvm 8 was the right thing to do. I was getting some (but not all) shaders miscompiled such that I was getting lighting/shadow corruption in several games using Vulkan natively and DXVK.

    So thanks for crying foul, I didn't know enough about that PKGBUILD at the time. (never encountered anything like that variable in the AUR). Now I really like that PKGBUILD, I make a few changes to the meson build options. Those helpers are pointless to me now.

    Leave a comment:


  • yurikoles
    replied
    Originally posted by HyperDrive View Post
    Unfortunately, a day only has 24 hours, and Mesa is not really my day job. 😉
    I'm wannabe-mesa-dev here, but this low-level C code looks hard to me even with mine 8 years of Mobile Development experience.

    Leave a comment:


  • HyperDrive
    replied
    Originally posted by yurikoles View Post
    I had read comments in mailing list. It seems no one including patch author not even tested it due to lack of hardware. But Marek had merged it, hopefully at least he had tested it.
    I have tested it, just haven't benchmarked it. It's not easy to find a shader-intensive workload which runs well on an Xpress 200M, and the shader cache mostly helps with lots of shader compile-use-discard cycles. I haven't tried my X1600 laptop yet, but I will, eventually (I'm also getting a laptop with an X700 soon). Unfortunately, a day only has 24 hours, and Mesa is not really my day job. 😉

    Leave a comment:


  • yurikoles
    replied
    I had read comments in mailing list. It seems no one including patch author not even tested it due to lack of hardware. But Marek had merged it, hopefully at least he had tested it.

    Leave a comment:


  • LinuxID10T
    replied
    Minecraft runs surprisingly well on my Radeon 1950XTX. There is also Quake 4 or Doom 3 which is in the PTS.

    Leave a comment:


  • Azrael5
    replied
    Hardware optimization is one of the added value in which Linux Os can excel.

    Leave a comment:

Working...
X