Hello,

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.

(*) https://01.org/linuxgraphics/documentation/driver-documentation-prms

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 [0]. 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?

[0] https://github.com/ValveSoftware/Source-1-Games/issues/19#issuecomment-13801640

(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 [0]. 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?
> 
> [0]
> 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.

(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 [0]. 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?
> > 
> > [0]
> > 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:

- gl_ClipDistance

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

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

http://cgit.freedesktop.org/mesa/mesa/commit/?id=0967c362bf378b7415c30ca6d9523d3b2a3a7f5d

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:

  http://lists.freedesktop.org/archives/mesa-dev/2013-April/038550.html

Alternatively, there's a git tree based on master here:

  https://github.com/chrisforbes/mesa/tree/ilk-source-games-fix

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!

great work!

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:

commit 06a503ca7163174e9763adcf64186d38997fee83
Author: Chris Forbes <chrisf@ijw.co.nz>
Date:   Mon May 20 22:10:29 2013 +1200

    i965/vs: add support for emitting gl_ClipVertex