Quoting: liamdawe

Quoting: Shmerl

Quoting: Purple Library GuyAnd Steam has definitely remained the natural place to go for Linux gamers.

Not necessarily. Linux gamers tend to be averse to DRM and can avoid Steam altogether. The survey simply doesn't represent such users at all.

I'm afraid such users really will be in the minority.

May be, but a significant one I suspect, to make survey numbers not as valuable, as they are often presented.

View this comment - View article - View full comments

Quoting: Purple Library GuyAnd Steam has definitely remained the natural place to go for Linux gamers.

Not necessarily. Linux gamers tend to be averse to DRM and can avoid Steam altogether. The survey simply doesn't represent such users at all.

View this comment - View article - View full comments

Quoting: KimyrielleWell, it's certainly not doomsday, but I'd still have thought the large supply of Linux games we got in the past two years would have at least helped us to grow -at pace- with the other platforms.

Well, I constantly see posts like "I just switched to Linux [because I can play games]", so clearly Linux user base is growing because of the improving gaming situation. But you can't easily measure that growth. I'd surely wouldn't use Steam numbers for that.

Quoting: KimyrielleBut our market share doesn't seem to change at all.

Linux market share itself is pretty hard to measure, but according to some measurements [External Link] - it's growing.

View this comment - View article - View full comments

Is it tied to Steamworks? Despite being a mulitplayer game, it's not available for non Steam users.

View this comment - View article - View full comments

Quoting: throghWould it be possible having some hints about "Gallium Nine" to be included within the build process? To be honest: For the moment I'm trying this out with an R600 but I don't get the DRI3-support working on my Devuan-System. :(

I didn't use it myself yet, so can't speak from experience. But if you'll figure out how to do it - feel free to add a section about Gallium 9 to the wiki :)

View this comment - View article - View full comments

Quoting: GuestI don't recommend trying to compile llvm yourself from bleeding edge git. If llvm 3.9 is available, just stick with that (if it's a version less, you won't have full GL4.5 support).

llvm 3.9 is available in Debian testing, yes. Using an unstable compiler is in general not the best idea, unless you really need it for some reason.

View this comment - View article - View full comments

Quoting: boltronicsThat's more or less the approach I use. The main difference is that I use a chroot which I enter using schroot, and expose /opt from inside it for deployment directly within the chroot.

Yes, chroot or even a full blown VM is probably a cleaner approach - I mention it in the guide. It's not hard to figure out how to do it, once you know the main process.

Quoting: boltronicsI also use `make install` to install, and am not sure why that wasn't suggested on the wiki. You only need to temporarily allow write access to the target directory (/opt/mesa-master/ in the example) which can easily be reverted afterwards - and the instructions even do this anyway with the `chown root:root` command. In my case, everything is scripted.

You can, but I wanted only a minimal set of files. make install would deploy more stuff, and also if you mess up your prefix by mistake, it will clutter or let alone mess up some system directories. So I'd rather avoid using it in the guide. If you script it all, there is less chance of mistakes once it's tested, then it's more reasonable to use it.

Quoting: boltronicsI also have LIBGL_DRIVERS_PATH exported from a file in /etc/profile.d/ and I add my custom library paths to a file under /etc/ld.so.conf.d/ and use ldconfig so that's one less environment variable to worry about.

I also avoid setting VK_ICD_FILENAMES by adding ICD JSON files under /etc/vulkan/icd.d, which is within the default search path and doesn't seem touched by any current Debian packages.

I didn't want to make global overrides. The whole point was to only use custom Mesa on demand, when you want it, and let the rest of the system and applications use default Mesa. If you are confident that it works well - you can always add those global overrides in /etc/profile.d/ and /etc/vulkan/icd.d as you mentioned.

View this comment - View article - View full comments

Quoting: M@GOidBut for AMD users, LLVM is also a important component when running bleeding edge Mesa, especially if you are looking for fixes of bugs. Can you please do a Wiki for how to build it too?

Yeah, in theory, you might want to chase the latest developments in the kernel drivers (amdgpu for instance), libdrm and llvm. But that's a whole different level of complexity. This guide assumes that you only update Mesa itself, and all the dependencies are same as the rest of the system. I didn't try building libdrm and llvm myself yet. If I'll get to it, I'll document it on the wiki :)

View this comment - View article - View full comments

Yeah, as long as the higher level API doesn't dictate a global design (for instance how to use multithreading) and doesn't mandate stateful approach (like OpenGL), it should be useful.

View this comment - View article - View full comments

Quoting: tuubiSure, but this only applies to projects that start from scratch. And besides, you're underestimating the effort and the risk of dumping existing code bases and know-how in any organization larger than a single developer.

I don't doubt that Rust is a nice programming language though.

Knowledge usually isn't dumped, it's simply extended. I.e. they might be invested in C++, but if they are smart, they can start shifting things to Rust gradually.

View this comment - View article - View full comments