24 ms·

Valve sponsors Mesa development

217 points by Rovanion 12y ago

thejosh 12y ago
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 12y ago
  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 12y ago
    It would be nice to play the Battlefield series on Linux.
    - Mikeb85 12y ago
      Battlefield is EA, not going to happen.
    - thejosh 12y ago
      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 12y ago
        > 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.
pachydermic 12y ago
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_video_games.svg http://en.wikipedia.org/wiki/File:Linux_kernel_and_OpenGL_vi...) 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?
- edwintorok 12y ago
  Because the OpenGL specification is actually something very complex, and doesn't map directly to hardware. There are many things that are higher-level, or that are features of the OpenGL implementation, and not of the hardware. (you'll notice that if you run a newer version of Mesa on older hardware you get some new extensions supported) So it is beneficial if code can be shared between hardware drivers. You could have a full implementation for each GPU/vendor, each with its own set of bugs, missing features and incompatibilities. Or you can do as Mesa did and try to implement the hardware independent parts in a common place, and have just the hardware-specific parts implemented by the drivers. For example you definitely don't want a separate implementation of the GLSL compiler for each GPU/vendor, GLSL is compiled to an intermediate representation and that is then further translated to hardware specific instructions. (although in practice I think you still have 2 implementations: one for Intel, and another for all other Gallium drivers) Think of it this way: would you like a full C compiler written from scratch for each CPU architecture, or would you want to share where possible (parser, type checker, hardware-independent optimizers, etc.). So an analogy would be: GCC frontend is like core Mesa, and a GCC backend is like a Mesa hardware driver. Another analogy would be libc: the majority of the code is hardware-independent that implements the various C99/POSIX APIs (i.e. like core Mesa), with just the hardware-specific parts / optimizations implemented in assembly (i.e. like Mesa drivers).
- Danieru 12y ago
  I cannot say how mesa is structured but graphics drivers are not simple for good reasons. First you don't want every draw call to cause a system trap. Thus some drivers include a dynamic library which gets loaded into the program’s memory space. Then after the library comes a daemon. Between the library and the daemon is where the OpenGL implementation lives. The daemon then hands off to the driver. The driver is meant to be a light interface to the GPU. The thinking being the kernel is not the right place to transform OpenGL to hardware instructions. If one did write an OpenGL implementation in a kernel driver then we could expect some harsh words from Linus. Now on a pedantic note the GPU already handles pushing the bits to the screen without the driver's help. Which is good because you do not want to introduce yet another timing dependent driver class like the networking stack. I'm not sure where the shader compilation occurs.
bpierre 12y ago
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/
base698 12y ago
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.
- Narishma 12y ago
  Neither Valve nor LunarG make hardware, so buying new hardware won't matter.
- vrodic 12y ago
  Probably AMD, they fund open source driver development and release good documentation for their GPUs. Intel is ok too, but their hardware is not really targeted for gamers. That being said, if you are fine with using proprietary drivers, currently nothing beats nVidia in terms of performance, features and stability of OpenGl drivers. You would be supporting the ecosystem with any purchase, but if you are politically inclined on free software then the choice is AMD or Intel.
  - claudius 12y ago
    > Intel is ok too, but their hardware is not really targeted for gamers. FWIW, I find the latest graphics units from Intel, e.g. HD 4600, rather okay. Even graphically nontrivial things like Crusader Kings II or KSP run decently, although usually far from the highest possible settings. But on the other hand, the drivers are rock-solid, delivered directly in Debian without any fiddling around as was/is necessary for the Nvidia drivers and I don’t need my own powerplant just to run a computer :)
    - anon4 12y ago
      I don’t need my own powerplant just to run a computer The Maxwell-based 750ti is the card to buy then. It's tiny, draws a reasonable amount of power and I've yet to see a game that doesn't run well on high.
- arjie 12y ago
  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.
northisup 12y ago
Thought this was going to be an announcement about http://www.blackmesasource.com http://www.blackmesasource.com or HL3
- JetSpiegel 12y ago
  Maybe it's another ARG?
maxjus 12y ago
That was a joke, haha, fat chance.
vrodic 12y ago
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.
Mikeb85 12y ago
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...
touhad 12y ago
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 ?????

217 points by Rovanion 12y ago

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 12y ago
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 12y ago
  It would be nice to play the Battlefield series on Linux.
  - Mikeb85 12y ago
    Battlefield is EA, not going to happen.
  - thejosh 12y ago
    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 12y ago
      > 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.

pachydermic 12y ago

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_video_games.svg http://en.wikipedia.org/wiki/File:Linux_kernel_and_OpenGL_vi...) 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?

edwintorok 12y ago
Because the OpenGL specification is actually something very complex, and doesn't map directly to hardware. There are many things that are higher-level, or that are features of the OpenGL implementation, and not of the hardware. (you'll notice that if you run a newer version of Mesa on older hardware you get some new extensions supported) So it is beneficial if code can be shared between hardware drivers. You could have a full implementation for each GPU/vendor, each with its own set of bugs, missing features and incompatibilities. Or you can do as Mesa did and try to implement the hardware independent parts in a common place, and have just the hardware-specific parts implemented by the drivers. For example you definitely don't want a separate implementation of the GLSL compiler for each GPU/vendor, GLSL is compiled to an intermediate representation and that is then further translated to hardware specific instructions. (although in practice I think you still have 2 implementations: one for Intel, and another for all other Gallium drivers) Think of it this way: would you like a full C compiler written from scratch for each CPU architecture, or would you want to share where possible (parser, type checker, hardware-independent optimizers, etc.). So an analogy would be: GCC frontend is like core Mesa, and a GCC backend is like a Mesa hardware driver. Another analogy would be libc: the majority of the code is hardware-independent that implements the various C99/POSIX APIs (i.e. like core Mesa), with just the hardware-specific parts / optimizations implemented in assembly (i.e. like Mesa drivers).
Danieru 12y ago
I cannot say how mesa is structured but graphics drivers are not simple for good reasons. First you don't want every draw call to cause a system trap. Thus some drivers include a dynamic library which gets loaded into the program’s memory space. Then after the library comes a daemon. Between the library and the daemon is where the OpenGL implementation lives. The daemon then hands off to the driver. The driver is meant to be a light interface to the GPU. The thinking being the kernel is not the right place to transform OpenGL to hardware instructions. If one did write an OpenGL implementation in a kernel driver then we could expect some harsh words from Linus. Now on a pedantic note the GPU already handles pushing the bits to the screen without the driver's help. Which is good because you do not want to introduce yet another timing dependent driver class like the networking stack. I'm not sure where the shader compilation occurs.

bpierre 12y ago

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/

base698 12y ago

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.

Narishma 12y ago
Neither Valve nor LunarG make hardware, so buying new hardware won't matter.
vrodic 12y ago
Probably AMD, they fund open source driver development and release good documentation for their GPUs. Intel is ok too, but their hardware is not really targeted for gamers. That being said, if you are fine with using proprietary drivers, currently nothing beats nVidia in terms of performance, features and stability of OpenGl drivers. You would be supporting the ecosystem with any purchase, but if you are politically inclined on free software then the choice is AMD or Intel.
- claudius 12y ago
  > Intel is ok too, but their hardware is not really targeted for gamers. FWIW, I find the latest graphics units from Intel, e.g. HD 4600, rather okay. Even graphically nontrivial things like Crusader Kings II or KSP run decently, although usually far from the highest possible settings. But on the other hand, the drivers are rock-solid, delivered directly in Debian without any fiddling around as was/is necessary for the Nvidia drivers and I don’t need my own powerplant just to run a computer :)
  - anon4 12y ago
    I don’t need my own powerplant just to run a computer The Maxwell-based 750ti is the card to buy then. It's tiny, draws a reasonable amount of power and I've yet to see a game that doesn't run well on high.
arjie 12y ago
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.

northisup 12y ago

Thought this was going to be an announcement about http://www.blackmesasource.com http://www.blackmesasource.com or HL3

JetSpiegel 12y ago
Maybe it's another ARG?

maxjus 12y ago

That was a joke, haha, fat chance.

vrodic 12y ago

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.

Mikeb85 12y ago

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...

touhad 12y ago

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 ?????