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

[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.

[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?

[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?

[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@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.

[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.

[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...

[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/

[kparal]

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/

I tried the demo and I also see "eurotrucks2" as the process name in htop and ps aux.

However, I have issues running Mesa git master on Fedora 26 (using che/mesa copr). Xorg is crashing:

https://da.gd/l6HQ

https://da.gd/htDfg

https://da.gd/goTP

https://da.gd/RA8a

Has anyone seen the same issue and resolved it?

[marek]

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...

App profiles for Vulkan are just a matter of time. Now it may not seem that way, but in 5, 10, or 15 years, things will most likely be very different and we might have vulkanrc. It's not the API that forces app profiles. The API has nothing to do with the need to have app profiles. Applications and their behaviors do. When we get an app that is buggy and its authors refuse to fix it, that will be the time when vulkanrc will be introduced. So that even the bad Vulkan apps can work.