Mesa OpenGL Threading Now Ready For Community Testing, Can Bring Big Wins

[M@GOid]

It looks like the executable name in drirc is wrong then. You can find out the real executable name by running "ps -A" while the game is running.

Tanks for the reply. But the results look the same:



ETS2 has a demo on steam. I doubt the executable is the same version of the full game, but maybe you can give it a shot:

http://store.steampowered.com/app/22...k_Simulator_2/

[spstarr]

I'm not sure I understand the question.
OpenGL's problem is that even with rules in place, devs like to implement their own paths. Vulkan does away with rules and says "here's a lower level API, do whatever you want". I'm having a hard time seeing how that's not going to lead to games optimized half-way or even for one of the major players. Professional software (which is where Vulkan can do the most good) will probably be treated better, but games? I think they'll just get the short stick.

Fwiw, I don't have a problem with Vulkan. Between OpebGL and Vulkan, I think now is a great time for open rendering frameworks. It's just that I don't agree with those that see Vulkan taking the world by storm and changing how we do rendering from the ground up.

It shoves the hacks out of the kernel/driver though, if developers want to do whatever they want, there's no silly .drirc conf madness needed for Vulkan...

[marek]

So I was testing ATS and ETS2 (amtrucks and eurotrucks2 respectively) to send Marek the names of the executables, and after much testing I discovered that these 2 games do not engage mesa_glthread via drirc. Both Borderlands games and The Witcher 2 worked without problems. These two truck simulators only engage mesa_glthread putting the command "mesa_glthread=true %command%" on Steam.

It looks like the executable name in drirc is wrong then. You can find out the real executable name by running "ps -A" while the game is running.

[M@GOid]

So I was testing ATS and ETS2 (amtrucks and eurotrucks2 respectively) to send Marek the names of the executables, and after much testing I discovered that these 2 games do not engage mesa_glthread via drirc. Both Borderlands games and The Witcher 2 worked without problems. These two truck simulators only engage mesa_glthread putting the command "mesa_glthread=true %command%" on Steam.

[whitecat]

Isn't there a way to just set LD_LIBRARY_PATH to point to the lib/ folder after a build? I would like to avoid touching the current (working) setup as much as possible.

On the command line:
$ LD_LIBRARY_PATH="/usr/local/lib" LIBGL_DRIVERS_PATH="/usr/local/lib/dri" <your_game>
It must match what you've set up in your build, in this case I've used "--libdir=/usr/local/lib --prefix=/usr/local" to build mesa.

Do I need to start the X server in a way that it is linked against those llibraries?

No need to restart X.

[M@yeulC]

No. Just build Mesa and you can create symlinks in /usr/lib... pointing to your built .so files in your Mesa tree. Then just "make" and you don't have to install.

Isn't there a way to just set LD_LIBRARY_PATH to point to the lib/ folder after a build? I would like to avoid touching the current (working) setup as much as possible.

I just tried that, but glxgears crashed (glinfo as well):

libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  156 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  45
  Current serial number in output stream:  47

Do I need to start the X server in a way that it is linked against those llibraries?

[Stankami]

I could try to test games with an APU I have at home, it's 7660D it's pretty beefy and I can run Dota 2@1080 on low with the render quality at 100% at 60-70fps and 40-50fps when a teamfight happens. Pretty cool huh?

[duby229]

Not sure. I don't find Gallium Nine too useful for me. More modern games use DX11 already, and those which use DX9 work pretty well with regular Wine and its CSMT.

Ok that's fine, but CSMT does at something like 4 times the CPU usage. That's a major problem and definitely causes CPU bottlenecks that don't exist in Gallium Nine due to its much lower CPU usage.

[leipero]

Not sure. I don't find Gallium Nine too useful for me. More modern games use DX11 already, and those which use DX9 work pretty well with regular Wine and its CSMT.

Most work quite well, but try to load some 20000+ blocks stadium map on TMNF (free) or TMUF, even on 24h competition maps limitations of Wine-D3D translation are quite obvious, in most cases gallium nine gives over twice the performance, especially with slower CPU, with superior input latency (even compared to Windows) that is important in such cases, you can try it yourself if you are on AMD GPU, on nvidia GPU, I've tested only on (very) low end GPU (with nouveau), and gallium-nine did hurt performance, but it was bad in both cases (with severe stutters on high cc maps). In such scenarios, that overhead of wine implementation goes to the unbarable levels, and gallium nine is great solution, I don't know for fast CPU's tho, you can try it.

[marek]

Quick question. This OpenGL Threadingb working on R600? I mean HD5850 or HD5650m? Should I try test it? marek

Yes. It's supported by all Mesa drivers. RadeonSI, R600, Nouveau, Intel, ...