
Valve sponsors Mesa development - Rovanion
http://lunarg.com/glassymesa/
======
pachydermic
I don't quite understand how Mesa and device drivers play together... can
someone explain this for me? I read the wiki
([http://en.wikipedia.org/wiki/Mesa_(computer_graphics)](http://en.wikipedia.org/wiki/Mesa_\(computer_graphics\)))
and this
([http://en.wikipedia.org/wiki/File:Linux_kernel_and_OpenGL_vi...](http://en.wikipedia.org/wiki/File:Linux_kernel_and_OpenGL_video_games.svg))
graphic makes it clear that Mesa is the implementation of the OpenGL
specification... what I don't get is the relationship between drivers and
Mesa. Why aren't the drivers the implementation of the OpenGL specification?
Is pushing bits from the GPU to the screen the only thing that the drivers do?

~~~
chubot
You may want to read this (long) article:

[http://blog.mecheye.net/2012/06/the-linux-graphics-
stack/](http://blog.mecheye.net/2012/06/the-linux-graphics-stack/)

Not claiming I understand it all, but it's long because graphics are
complicated :) I have been surprised at how device-dependent graphics software
is.

I wonder if Windows or OS X has nicer graphics abstractions than Linux? i.e.
that make it less of a mess?

~~~
mwfunk
I think the graphics stack is a sore point on most or all platforms that have
to support multiple GPUs from multiple vendors, at least the stuff in between
userland GL calls and the bare metal.

In an ideal world it would be obvious where to draw the line between the GPU-
and vendor-independent bits and the common code shared by everyone, but not
only is that very hard to do, it can change drastically over the years. Couple
that with the fact that platform vendors have to maintain these imperfect
interfaces for many years regardless, and that vendors can have their own
abstraction layers in between the top layer of their driver code and the bare
metal of all their GPUs, and you have a perfect storm of too many layers
getting in the way and imperfectly defined interfaces to many of those layers,
which necessitates occasional layering violations at every level of the stack
if you want to avoid some pathological performance bottlenecks for some GPUs.

At best you end up with a bunch of ugly, imperfect, but generally functional
software that more or less gets the job done at an acceptable level of
performance.

I would imagine that the situation with Linux just adds yet more issues to
that bag of hurt. GPU vendors don't always want to help out, and are likely to
withhold valuable technical information that they don't want to be public. The
whole process of defining how many layers there are, what functionality exists
at what layer, and what interfaces are used between the layers is almost by
definition (for GPU driver models at least) a bunch of questions for which
there are no good answers, which is also a perfect storm for Open Source
development. Any solution anyone comes up with is always going to have some
caveats and gotchas, which for open, egalitarian development models means
endless arguments and bikeshedding in which everyone involved is correct in
pointing out the weaknesses of the system as designed, but there are no
alternatives that anyone can point to that don't have similar problems in
someone else's eyes.

For example, back in the '90s, for right or wrong I was very optimistic about
GGI solving a lot of graphics problems for Linux, and that was limited to the
2D stuff (I can't imagine how controversial it would've been had it included
3D as well):

[http://en.wikipedia.org/wiki/General_Graphics_Interface](http://en.wikipedia.org/wiki/General_Graphics_Interface)

It didn't pan out that way, but so much energy was burned by so many people
arguing about it over so many years. :( I don't have authoritative knowledge
of the whole thing, so maybe the doubters were correct, but at the time it
felt like a bunch of people shooting down an imperfect solution while offering
no solution at all.

EDIT: TL;DR designing a graphics stack that ultimately goes down to the metal
is a set of very hard problems, many of which have no perfect answers. This,
coupled with secretive vendors and the level of specialized knowledge required
to even contribute to stuff like this, makes it an even harder problem in the
Open Source world. Not an insurmountable obstacle, but a really hard set of
problems nonetheless, for both technical and human reasons.

------
base698
If you were in the market for new hardware and wanted the purchase to support
initiatives such as this--what would you buy?

I don't really game any more but like to support the ecosystem.

~~~
arjie
The standard response is AMD, but both their open source drivers and
proprietary drivers are very bad. It's not performance, it's stability. AMD
Linux drivers crash on all sorts of things. Having an accelerated desktop can
do it.

I had a 7770 for a year before I switched to Nvidia. Better all around.

Still AMD do sponsor open source driver development, I'm told, so it's up to
how much you're willing to sacrifice for this.

~~~
throwaway2048
on older r600 GPUS (4000/5000 series) the open driver is much better than the
closed source one, over the past while it has been improving massively.

~~~
mpyne
Plus I can confirm that the open source driver is much more stable on pre-
radeonsi hardware than it used to be.

I eventually ended up buying a radeonsi card and while the extra GPU oomph is
nice, the lower stability is not.

------
Mikeb85
More good news for open source and Linux.

Valve is probably the most influential single entity in PC gaming, for them to
embrace open-source to this degree is massive...

------
thejosh
You would think with Steam banking it big with the Steambox that they would
want people working on these sorts of projects, as it's not only Steam that
wins big (having a FOSS OS to run their steam box on), but everyone else.

~~~
jagger27
Valve understands that without other incentives for developers to target
Linux, gamers will never switch. It's looking to be a huge win for the FOSS
community.

~~~
jebblue
It would be nice to play the Battlefield series on Linux.

~~~
thejosh
The future games I see being game changers for Linux are Half Life 3, Portal 3
and the new Left 4 Dead - these are all games that would work well with the
steam controller on the Linux box and would drive sales to the Steambox.

~~~
ekianjo
> work well with the steam controller on the Linux box and would drive sales
> to the Steambox.

I am a gamer on Linux, but there's no reason these games will run better on
Linux vs Windows or use the controller better (since they will probably
support the controller drivers for Windows systems as well). Valve has
repeatedly said they would not do any exclusive titles for any platform as
well, so I don't think just a couple of great games will drive much Steambox
sales. There are going to be several drivers for Steamboxes: 1) the hardware
needs to be cheap enough 2) the experience needs to be seamless and AS GOOD as
a console if not more 3) enough big games to ensure you do not miss too much
by not staying on Windows.

------
vrodic
I'm not conviced this will help that much for Intel GPUs. Developers from
Intel have been optimizing shader compilers specifically for Dota 2 for some
time without much impact on performance.

Dota 2 is probably memory bandwidth limited on Intel/Linux/OpenGL and that is
likely the case for other games too.

So maybe modifying the OpenGL part of the game engine a bit to take memory
bandwidth constraints of Intel GPUs into account would help more.

When I was looking into the issue of Intel GPU peformance on Linux many months
ago there were no tools to profile memory bandwidth bottlenecks.

------
touhad
Presently each SCM (Subsea Control Module) uses a specific protocol to
communicate with the topside system. The topside system often polls the SCM
for data. In the case of RRC there are currently three different types of SCM
and these use the following protocols: 2000, 3000 and 1024. how we can program
a common driver interface and that will include the three protocols and the
top side don't three package to control the three different subsea module
?????

------
northisup
Thought this was going to be an announcement about
[http://www.blackmesasource.com](http://www.blackmesasource.com) or HL3

~~~
JetSpiegel
Maybe it's another ARG?

------
maxjus
That was a joke, haha, fat chance.

------
bpierre
At first reading, I thought it was about Black Mesa [1], the Half-Life (first
Valve game) remake made by the community.

[1] [http://www.blackmesasource.com/](http://www.blackmesasource.com/)

