Nouveau Maxwell: Mesa 17.0 + Linux 4.10 vs. NVIDIA's Linux Driver

[Michael]

Everything is implemented up to GL 4.1 other than emulating the FP64 support your chip doesn't have (which no known game uses anyways), so you should be able to over-ride to at least 4.1 and run successfully. There are only a couple of GL 4.2 extensions not implemented and I don't remember seeing them get used either... 4.3 is *probably* the first place you will run into problems over-riding.

https://mesamatrix.net/

I thought I read a recent article here about someone in the community working on emulating FP64, does anyone remember ?

Yes, libSoftFloat - http://www.phoronix.com/scan.php?pag...q=libSoftFloat

https://github.com/Hopetech/libSoftFloat but hasn't been touched now since November.

[andre30correia]

Unlikely to be any real difference between those two driver releases... And 378 wasn't even out when I was doing these tests.

the base is complety different but ok

[bridgman]

Tried overriding and it doesn't work. I tried it on Bioshock Infinite for example and it keeps complaining that I don't have the proper OpenGL profile.

Did you over-ride both GL and GLSL versions to 4.1 ?

In theory BI only requires GL 4.1 but I found a few posts suggesting that it also used some 4.2 and 4.3 extensions, and may actually require the driver to advertise 4.2 or 4.3. That doesn't match what the developers who worked on the port are saying though. I would try over-riding both GL and GLSL to 4.3 as a next step although AFAIK BI received an update to fall back if the 4.3 extension (copy_image) was not available.

It also appears that some people have been over-riding the GLSL version higher than the GL version, eg:

MESA_GL_VERSION_OVERRIDE=4.1 MESA_GLSL_VERSION_OVERRIDE=440 %command%

Is your mesa version reasonably new (last 6 months or so) ?

[dungeon]

According to this, overriding worked even for unreasonable 15 months old 11.0.3

https://www.gamingonlinux.com/forum/topic/1795?page=1

But at least two points to mention - Gentoo user likely isn't average Joe and answer might be hidden as HD6950 is also what Dave had to hack on

It makes sense to force BI to run on that TDP 200W card, but on mobile 6400 serie... he, he, that is 10 times slower even on paper with proper drivers

[nomadewolf]

Not to take this off-topic but does anyone know what is going on with the AMD r600 driver? I am still stuck on OpenGL profile 3.3 with my HP Elitebook 8460p laptop. It has an AMD Radeon HD 6470M GPU with 1 GB RAM.

The question is: do you really need OpenGL > 3.3 on that hardware?

[Hi-Angel]

The question is: do you really need OpenGL > 3.3 on that hardware?

Sorry for meddling, but as someone in the same situations: yes, I need higher OpenGL on mine HD5730. More over: I need specifically that 64 bit support for Space Engine. Because simply overriding OpenGL version leads to SpaceEngine crash, which most probably because it's using those extensions. Which not at all surprising, given how much work SpaceEngine does.

[bridgman]

Something doesn't sound right - doesn't Space Engine only require GL 3.3 in the first place ?

http://en.spaceengine.org/

What happens if you don't override ?

BTW I suspect nomadewolf was talking about processing power, not age of the card, specifically whether a 6470 would have enough processing power to run the most demanding games even if it had the GL support.

Your 5730 has ~4x the processing power and memory bandwidth of a 6470.

[Hi-Angel]

Something doesn't sound right - doesn't Space Engine only require GL 3.3 in the first place ?

http://en.spaceengine.org/

What happens if you don't override ?

BTW I suspect nomadewolf was talking about processing power, not age of the card, specifically whether a 6470 would have enough processing power to run the most demanding games even if it had the GL support.

Your 5730 has ~4x the processing power and memory bandwidth of a 6470.

Hmm, there's something confusing. SpaceEngine popups "Error loading generator shaders, press Yes to run program with procedural planets disabled, No to exit". When I was trying to get it working, I remember seeing in the log ridiculously low OpenGL version, which I assumed to be the cause. Then I looked up in Wikipedia the version my card was supposed to run (4.4), looked up glxinfo | grep version (many different strings, I assumed the version to be "OpenGL core profile version", which is 3.3), asked on Mesa-users ML, and got an answer about the lack of double precision support.

Now that I looked at it again, it's more interesting: the OpenGL SpaceEngine has in logs is just 3.0. It takes it probably from "OpenGL version string", not from "OpenGL core profile version" — well, I'm not versed in the terminology, I thought the latest is the version, in part because it's higher.

Probably, I need to ask on ML another question, for why I'm seeing 3.0 instead of even 3.3. But whatever, even if I override it to 3.3 "MESA_GL_VERSION_OVERRIDE=3.3 wine SpaceEngine.exe" — SpaceEngine just crashes. It might of course be not the problem with OpenGL, but from my research in the past, the app works fine for other peoples through Wine, so I have little to blame.

[bridgman]

Sounds like you found the issue - Space Engine might be looking for a compatibility profile rather than the usual core profile. Compatibility profiles allow an application to mix deprecated API calls with newly added functions, albeit with unspecified behaviour.

I have not found anything saying that Space Engine *does* require a compatibility profile; it just seems likely if it is reporting the 3.0 version.

BTW if this is the case then your GL override would have to be something like "3.3FC" rather than just "3.3".

There is also a check in Space Engine which might be worth disabling for a test:

But you still can try and run SpaceEngine by disabling checking of critical errors at startup. Open main-user.cfg and change value of this parameter to 'true':

IgnoreCriticalCheck true // ignore checking of OpenGL version and critical extensions supporting

NOTE: I can give no guaranties that SpaceEngine will be stable and work correctly if you do make this change.

http://en.spaceengine.org/forum/4-3483-1

[Hi-Angel]

Sounds like you found the issue - Space Engine might be looking for a compatibility profile rather than the usual core profile. Compatibility profiles allow an application to mix deprecated API calls with newly added functions, albeit with unspecified behaviour.

I have not found anything saying that Space Engine *does* require a compatibility profile; it just seems likely if it is reporting the 3.0 version.

BTW if this is the case then your GL override would have to be something like "3.3FC" rather than just "3.3".

There is also a check in Space Engine which might be worth disabling for a test:



http://en.spaceengine.org/forum/4-3483-1

Well, with "3.3FC" it still crashes. And IgnoreCriticalCheck didn't help — though it might be because I have a 1.5 year old version of SpaceEngine (didn't update because it doesn't work). But thank you anyway — at least now I have something to look into. E.g. I could ask a question on their forum. I thought it's purely my fault, but now I could annoy them a bit — AFAIK using compatibility profiles is a moveton, aren't it.