[Linux]No 3D Rendering with Intel HD 4000 and Mesa about dota-2

[chaserhkj]

Confirmed same behaviour with Gentoo Linux 64bit, Intel HD4000 with mesa 10.5.6

But works without error with my discrete graphic card GeForce 610M, using Bumblebee 3.2.1, primus git version, Linux 3.17.6 and Nvidia proprietary driver version 352.09.

It seems like it does not works well with Intel cards on Linux...

Any further information including complete log could be provided if requested.

[suhaaktas]

it could be related to arch and gentoo are both rolling-distros. so maybe packaged relatively unstable mesa drivers for them?

[ananace]

I can add that I have no issues on Intel HD4400 laptop with Mesa 10.5.6, maybe it's an issue with unimplemented features for the HD4000?
(Running Gentoo x86_64 here too)

[icanttakeitanymore]

debian 8.1 and sid
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Bay Trail
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.3.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.3.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:

ii libdrm-intel1:amd64 2.4.58-2
ii libdrm-intel1:i386 2.4.58-2
ii xserver-xorg-video-intel 2:2.21.15-2+b2

[danginsburg]

It looks like the issue is that we are unable to run on implementations supporting GL_MAX_TEXTURE_IMAGE_UNITS < 32 (you can check what you support with glxinfo | grep GL_MAX_TEXTURE_IMAGE_UNITS). This is actually a regression on our side when we added deferred specular to the map, I will work on a fix.

[crisim]

I have the same problem using the radeonsi drivers from "ppa:oibaf/graphics-drivers" and mesa 10.7git1506230730.176256gd on my laptop

ASUS K55DR (R500D)
Amd APU A8-4500M
8GB ddr
256GB SSD Samsung

[danginsburg]

Can you provide the output of the following:

glxinfo -l | grep TEXTURE_IMAGE_UNITS

Upon further review, I believe we should only have a problem if GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS < 20. There was at one time a bug in mesa where it checked the binding = # qualifier against GL_MAX_TEXTURE_IMAGE_UNITS instead of GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS. I wonder if that's the bug we are hitting here.

[icanttakeitanymore]

glxinfo -l | grep TEXTURE_IMAGE_UNITS
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 48
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS = 16
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 48
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16

[sgsdxzy]

glxinfo -l | grep TEXTURE_IMAGE_UNITS
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 48
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS = 16
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 48
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16

[danginsburg]

Thanks. Sampler bindings 18 and 19 do not exceed GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS so it looks like an old mesa bug I have encountered before. Odd that you guys are seeing it on recent mesa builds (10.5.x) though. I'm going to grab the mesa source and debug it on my SNB machine here.

[imirkin]

@danginsburg that issue should be fixed by http://patchwork.freedesktop.org/patch/52603/

[danginsburg]

I've checked in a fix that should get things working on Sandy Bridge using mesa 10.3.2. This should go out in the next update.

After that update, if you still experience the issue, you will need to either grab the mesa patch from @imirkin or specify on the command-line -gl_force_sm30. Using -gl_force_sm30 will (after the update) not use bindings higher than 16 which works around the mesa bug.

One of the problems currently on Sandy Bridge is that mesa only supports #version 140 and the code was improperly detecting the supported GLSL version. So we were passing in #version 330 shaders when only #version 140 is supported. That is what I fixed along with limiting the sampler count to 16 when in SM30 mode.

[imirkin]

FWIW I pushed the patch, and it should make it into the next 10.5.x and 10.6.x releases. Older mesa trees are well past their "best-by" date :) [ As an aside, SNB gained GS and GL 3.3 support in newer mesa releases... 10.5 iirc? You can see what hardware supports what in which mesa version over at http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html ]

[MatthewJamesMartin]

Confirming the mesa patch works on arch64 + HD4000

[crisim]

I confirm the patch works with radeonsi drivers on APU A8-4500M too

[chaserhkj]

confirm that mesa patch works with my HD4000 system

[z0mbieprocess]

confirm working with HD3000

[DM-]

Ubuntu 64, mesa 10.3.2, Intel® Core™ i7-3612QM CPU (has HD4000 integrated graphics)
I added dota2.sh as a nonsteam game and have ( %command% -gl_force_sm30 ) as launch options.
Still having this bug, as described 50+ fps in menu, drops to ~3 in game similar to issue #53 and.
Nothing 3D renders, such as heros in the hero tab, and game looks as screenshotted above with two colors each taking up half the view.

Will try to update mesa with mesa patch and try again with more info later.

....@....:~$ glxinfo -l | grep TEXTURE_IMAGE_UNITS
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 48
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS = 16
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 48
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16

[MatthewJamesMartin]

@DM-
That's because the client update with the sm30 fix hasn't been pushed yet, you'll need grab and patch mesa yourself for the time being

[DM-]

Oh ok. Thanks, I thought it was already pushed when the people above said it was working. My bad.

Time to figure out how to patch mesa.

[SuperFlick]

@Hoonboof does it mean that i can just wait for another dota 2 reborn patch? or i have to patch mesa? (because i dont know how:D im new with linux)

[MatthewJamesMartin]

@SuperFlick
Yeah just wait for the next update and use the force flag if you have problems.

[danginsburg]

Since a lot of people are probably going to hit this mesa bug, I added some detection code that will automatically force SM30 if it detects a driver with this bug. So hopefully when the next update is released it should just work on mesa 10.5.x/10.6.x without the driver patch or requiring -gl_force_sm30.

[imirkin]

@danginsburg ideally your workaround would be s.t. it'd only trigger on 10.5.8 and older and 10.6.0, but not the future 10.5.9 and 10.6.1 which both ought to contain my patch.

[SuperFlick]

mesa 10.7 fixed this issue

[gdrewb-valve]

The workaround should fix things in the 6/24 update.