Bugzilla – Bug 59187
[Steam] fix user-clipping / gl_ClipVertex (for pre SandyBridge)
Last modified: 2013-06-08 01:06:52 UTC
Created attachment 72760 [details]
On Ubuntu 12.04 x86_64 with an Intel integrated Chipset HM55 / Ironlake Mobile:
lspci -vnn | egrep "VGA|3D|Display"
00:02.0 VGA compatible controller : Intel Corporation Core Processor Integrated Graphics Controller 8086:0046 (prog-if 00 [VGA controller])
Steam give me this information:
Speed: 2266 Mhz
4 logical processors
3 physical processors
Operating System Version:
Ubuntu 12.04.1 LTS (64 bit)
Kernel Name: Linux
Kernel Version: 3.2.0-35-generic
X Server vendor: The X.Org Foundation
X Server release: 11103000
Driver: Intel Open Source Technology Center Mesa DRI Intel(R) Ironlake Mobile x86/MMX/SSE2
Driver Version: 2.1 Mesa 9.0
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 59 Hz
Number of Monitors: 1
Number of Logical Video Cards: 1
Primary Display Resolution: 1366 x 768
Desktop Resolution: 1366 x 768
Primary Display Size: 13,54" x 7,60" (15,51" diag)
34,4cm x 19,3cm (39,4cm diag)
Primary VRAM Not Detected
Audio device: Intel IbexPeak HDMI
RAM: 3753 Mb
UI Language: English
Microphone: Not set
Total Hard Disk Space Available: 409142 Mb
Largest Free Hard Disk Block: 86328 Mb
Recent Failure Reports:
When i try to launch Team Forteress2 : I have a black screen with my little with mouse only. I heard sound.
Bug for steam: https://github.com/ValveSoftware/steam-for-linux/issues/150
Team Fortress 2 requires some functionality from OpenGL 3.0 and GLSL 1.30, which we currently only support on Sandy Bridge and newer hardware. Unfortunately, Ironlake and earlier currently do not.
It should be possible to implement the missing functionality on Ironlake. The code is open source, and the hardware documentation is freely available on the web(*), so in theory, anyone could make progress toward this.
Sadly, our team is extremely busy working on newer hardware and is unlikely to have time to implement GL 3.0 support for Ironlake...at least not any time soon. I sincerely apologize for this; we'd all love to see it happen too.
In the meantime, I've reassigned the component to Drivers/DRI/i965 as it's a driver specific issue, rather than a Mesa core issue.
*** Bug 60481 has been marked as a duplicate of this bug. ***
In #60481 Ian Romanick said Source-Games would depend on GL3..
I demonstrated that the Source-Games don't need full GL3, but just depend on GLSL 1.30 . I run CS:S using Mesa-9.0's softpipe driver (OpenGL 2.1 & GLSL 1.30). So there is probably just some GLSL 1.30 functionallity missing, which could be implemented as a software fallback or using the graphics hardware (if supported).
Where would we have to implement those missing GLSL 1.30 functions?
(In reply to comment #3)
> In #60481 Ian Romanick said Source-Games would depend on GL3..
> I demonstrated that the Source-Games don't need full GL3, but just depend on
> GLSL 1.30 . I run CS:S using Mesa-9.0's softpipe driver (OpenGL 2.1 &
> GLSL 1.30). So there is probably just some GLSL 1.30 functionallity missing,
> which could be implemented as a software fallback or using the graphics
> hardware (if supported).
> Where would we have to implement those missing GLSL 1.30 functions?
I can't speak to whether Source games require GL 3.0 or not, but here's a rough list of what would need to be added to the i965 driver in order to support GLSL 1.30 on Ironlake (this is based on section 1.2.1 "Summary of Functionality differences from version 1.2" of the GLSL 1.30 spec):
- Texture size queries*
- Texture arrays*
- Texture offsetting*
- Explicit LOD and derivative controls*
- "noperspective" and "flat" interpolation qualifiers
*Some of these may already work on IronLake--I'm not terribly familiar with the texturing code.
(In reply to comment #4)
> (In reply to comment #3)
> > In #60481 Ian Romanick said Source-Games would depend on GL3..
> > I demonstrated that the Source-Games don't need full GL3, but just depend on
> > GLSL 1.30 . I run CS:S using Mesa-9.0's softpipe driver (OpenGL 2.1 &
> > GLSL 1.30). So there is probably just some GLSL 1.30 functionallity missing,
> > which could be implemented as a software fallback or using the graphics
> > hardware (if supported).
> > Where would we have to implement those missing GLSL 1.30 functions?
> > 
> > https://github.com/ValveSoftware/Source-1-Games/issues/19#issuecomment-
> > 13801640
> I can't speak to whether Source games require GL 3.0 or not, but here's a
> rough list of what would need to be added to the i965 driver in order to
> support GLSL 1.30 on Ironlake (this is based on section 1.2.1 "Summary of
> Functionality differences from version 1.2" of the GLSL 1.30 spec):
> - Texture size queries*
> - Texture arrays*
> - Texture offsetting*
> - Explicit LOD and derivative controls*
> - "noperspective" and "flat" interpolation qualifiers
> - gl_VertexID
> *Some of these may already work on IronLake--I'm not terribly familiar with
> the texturing code.
Argh, sorry. I hit submit before I was finished. One more item:
Of all of these items, the trickiest one is gl_ClipDistance, since it requires modifying the Gen4/5-specific "clip" program (brw_clip.c) to perform clipping in a manner more like what happens in Gen6+ (using clip distances provided by the vertex shader rather than performing dot products in the clip program). This is not a project for the faint of heart--the brw_clip.c code isn't terribly well tested, and has a lot of tricky corner cases in it.
Once those things are done, we would of course want to run the driver through a pretty thorough round of piglit testing to make sure we hadn't missed any small details.
This isn't only an IronLake-issue.
This issue is related to any chipsets older then SandyBridge.
Just to nudge things, is anybody working on this/know of anybody working on this? If I had the know-how, I'd have a shot, but this is outside the scope of my abilities.
(In reply to comment #6)
> This isn't only an IronLake-issue.
> This issue is related to any chipsets older then SandyBridge.
Just a side note to anyone who decides to work on this bug;
If you would like to try to make chipsets prior to Gen5 work, please have a look at section 6.2.3 ("Negative-W Clipping Errata") of the i965/G35 manual (pp133-138), available from https://01.org/linuxgraphics/documentation/intel%C2%AE-965-express-chipset-family-and-intel%C2%AE-g35-express-chipset-graphics-controller
Briefly, certain Gen4 chipsets contain a bug which causes vertices with a negative gl_Position.w value to be clipped incorrectly. The workaround uses some of the hardware that was intended to implement gl_ClipDistance (specifically, bit "UC7", which is output by the vertex shader to help the fixed-function clipping hardware determine whether a vertex may be trivially accepted or rejected). At present, applying the workaround is easy, since we don't support gl_ClipDistance on those chipsets, so bit UC7 is otherwise unused. If we want to make Gen4 chipsets implement gl_ClipDistance properly, we'll need to carefully consider the interactions between the bug workaround and gl_ClipDistance.
You can find the workaround code in Mesa by searching for the text "has_negative_rhw_bug".
I'm keen to fix this, I just need to scrounge up a working Ironlake box first.
I would like to see this on my Intel GMA 4500, that would be great
CS:S now runs at about 5 FPS (on Core i5 Ironlake), using the latest LLVMpipe driver, which is part of the mesa9.2-devel and provides GLSL-1.30.
Chris Forbes, can we somehow help you to get a proper box for development?
Is anybody working on this?
team fortress 2 now started working after the following commit on my GMA 4500
but world rendering is garbled.
looks like source game does not require GLSL 1.30
any comment about CS:S since I dont own that game
Eric mentioned that anything using user-clipping (via gl_ClipVertex) will likely be broken. I believe we even have some failing Piglit tests for this. At this point, it appears that we're mostly looking at bugs, not missing features. Which bodes really well for seeing this fixed...
I try with this ppa https://launchpad.net/~oibaf/+archive/graphics-drivers
who give me
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile
OpenGL version string: 2.1 Mesa 9.2.0 (git-b8998f9 precise-oibaf-ppa)
OpenGL shading language version string: 1.20
I could launch TF2. see: https://github.com/ValveSoftware/steam-for-linux/issues/150#issuecomment-16017762
I know that the subjet of this bug changed but, that only i could do: post to say that the progress is on the good way.
Of course this driver is on developpement and have some bugs: Some time i need to reboot because the screen of my desktop is not stable.
Thanks for your work.
Created attachment 77559 [details]
With the ppa who upgrade to Mesa 9.2
@ Lukas M: I am not sure that fix in tittle is a good idea. The driver is not usable and bug with some games who aren't Source's games.
Finally got some Ironlake hardware!
The CSS/TF2 garbled world rendering is fixed in this patch:
Alternatively, there's a git tree based on master here:
The clipping stuff turned out to be a red herring for these games -- they write gl_ClipVertex, but mishandled clipping isn't what was screwing things up.
dont know should I discuss it here, Team Fortress 2 does not get any input (mouse clicks, key press) in the main menu, I guess maybe after steam update. So I cant test the patch
fixed for me! tried with Portal Beta on my GMA 4500 MHD with mesa master.
Now source engine games should run fine!
should this bug be closed now
Created attachment 78952 [details]
With Mesa 9.2 patched
Better with your patch, Chris Forbes.
With Mesa 9.2.0 (git-b4b3041 precise-oibaf-ppa) it work well.
Thanks you and Valve for your work.
Created attachment 78953 [details]
glxinfo with Mesa 9.2 patched
I close the bug, i think it resolved. I hope it will be backported to Mesa 9.1
I think we might want a new bug for gl_ClipVertex itself not being supported -- it turned out it wasn't the issue here, but it's still wrong :).
There are some depth issues while running Portal on my GMA 4500 MHD but not sure if that problem is related to this bug though. Similar problem noticeable while running Windows version of Portal with Wine. Just for information native version runs much faster and better than Windows version with wine.
I have tried both running with Mesa from master git
And Mesa 9.1.2 plus this commit which fixes this bug
(In reply to comment #24)
> There are some depth issues while running Portal on my GMA 4500 MHD but not
> sure if that problem is related to this bug though.
Unrelated, but thanks for the info. That's tracked as bug #64253.
Fixed as of this commit on master:
Author: Chris Forbes <email@example.com>
Date: Mon May 20 22:10:29 2013 +1200
i965/vs: add support for emitting gl_ClipVertex