Intel Geometry Shaders Code Merged Into Mesa

[mendieta]

That's true, and it's why some people may choose to use it in their SteamBox. There are tons of really good games on Steam that will work just fine on Intel graphics. Maybe not all of them, but you can still have a really fun time if you choose the right games.

Yes, and back to the original 'are you nuts' post: the natural alternative to Intel would be AMD, not NVIDIA. A good APU from AMD paired with their ample Open Source support (so you get the code and you are free to improve/customize it), plus the fact that you won't be number crunching on such a box, so the place where Intel has a huge age (CPU power) is not a big deal ... and you get the reason why ALL next generation gaming consoles are running AMD now

http://www.pcmag.com/article2/0,2817,2419289,00.asp

Now, Intel keeps improving its APU's. and it offers the best Open Source drivers, so it does tie things out somehow, so it's not crazy at all to think of an intel steambox ...

[mrugiero]

Yes, and back to the original 'are you nuts' post: the natural alternative to Intel would be AMD, not NVIDIA. A good APU from AMD paired with their ample Open Source support (so you get the code and you are free to improve/customize it), plus the fact that you won't be number crunching on such a box, so the place where Intel has a huge age (CPU power) is not a big deal ... and you get the reason why ALL next generation gaming consoles are running AMD now

http://www.pcmag.com/article2/0,2817,2419289,00.asp

Now, Intel keeps improving its APU's. and it offers the best Open Source drivers, so it does tie things out somehow, so it's not crazy at all to think of an intel steambox ...

I don't see why Valve would want to improve the drivers by themselves, when AMD and NVIDIA already help tuning up their drivers to games as they come out. They could as well just work with the proprietary version, with feedback from Valve with things to fix, since they are already experts on their own closed source drivers. Also, using free drivers implies that at least changes to kernel drivers must be released (I'm not sure which license mesa drivers use), and if tuning is done, they have an advantage to offer their users against just using a PC, which would be counteracted by the releasing the source code.

[Veerappan]

I don't see why Valve would want to improve the drivers by themselves, when AMD and NVIDIA already help tuning up their drivers to games as they come out. They could as well just work with the proprietary version, with feedback from Valve with things to fix, since they are already experts on their own closed source drivers. Also, using free drivers implies that at least changes to kernel drivers must be released (I'm not sure which license mesa drivers use), and if tuning is done, they have an advantage to offer their users against just using a PC, which would be counteracted by the releasing the source code.

The Mesa drivers exist in user-space, so you can upgrade the drivers via a ppa without a system restart. As far as license goes, I believe that it's MIT/X11, but don't quote me on that.

In the past, Valve has gone on record stating that they prefer the open drivers because its easier for them to find bottlenecks in their code and the drivers because they have debugging symbols and source available... Or something to that effect.

[mrugiero]

The Mesa drivers exist in user-space, so you can upgrade the drivers via a ppa without a system restart. As far as license goes, I believe that it's MIT/X11, but don't quote me on that.

In the past, Valve has gone on record stating that they prefer the open drivers because its easier for them to find bottlenecks in their code and the drivers because they have debugging symbols and source available... Or something to that effect.

I know they are in user-space, that's why I specifically said "the kernel drivers". If I'd thought both were on the kernel, I'd have just said "drivers". Since the kernel ones I know are GPL, and mesa I'm not completely sure (as you, I believe they are MIT/X11), the first ones would require any changes to be released as source code, while if mesa is MIT, they can keep their changes for themselves.

On Valve preferring open source drivers, the reasons they gave according to you will be available for them in the case of a closed source fork being made by them. I mean, closed source only means the author doesn't release the source, not that it doesn't exist.

[smitty3268]

I know they are in user-space, that's why I specifically said "the kernel drivers". If I'd thought both were on the kernel, I'd have just said "drivers". Since the kernel ones I know are GPL, and mesa I'm not completely sure (as you, I believe they are MIT/X11), the first ones would require any changes to be released as source code, while if mesa is MIT, they can keep their changes for themselves.

I really have no idea what you are trying to say here. You think Valve wants to modify the drivers and then not release the source code for some reason?

Anyway, the kernel portion of the drivers is unlikely to be something they would ever want to touch - it mostly just bangs on the hardware registers, and isn't something that would be useful to try and optimize games. All that would be in the userspace portion of the drivers.

Also, the kernel portions of the drivers are the same MIT/X11 licenses that the userspace drivers are under. That's why they can be ported over to the BSD's. That license is just compatible with the GPL so it doesn't matter that it gets pulled in to the linux kernel.

[mrugiero]

I really have no idea what you are trying to say here. You think Valve wants to modify the drivers and then not release the source code for some reason?

What I say is that, with the reasons given to prefer open source drivers, if they are to modify them, they'd probably want to keep the changes for themselves, as that'd mean a relative advantage on using their console, and thus a reason to buy it. Or at least they might see it that way.

Anyway, the kernel portion of the drivers is unlikely to be something they would ever want to touch - it mostly just bangs on the hardware registers, and isn't something that would be useful to try and optimize games. All that would be in the userspace portion of the drivers.

Anyway, that's the part I thought they could not modify without releasing the changes.

Also, the kernel portions of the drivers are the same MIT/X11 licenses that the userspace drivers are under. That's why they can be ported over to the BSD's. That license is just compatible with the GPL so it doesn't matter that it gets pulled in to the linux kernel.

I thought it was GPL, but yeah, they are under a non copyleft license.

[crymsonpheonix]

What I say is that, with the reasons given to prefer open source drivers, if they are to modify them, they'd probably want to keep the changes for themselves, as that'd mean a relative advantage on using their console, and thus a reason to buy it. Or at least they might see it that way.


Anyway, that's the part I thought they could not modify without releasing the changes.


I thought it was GPL, but yeah, they are under a non copyleft license.

Yes, mesa is and has always been MIT, so valve *could* build custom versions of any of the drivers and only release binaries, but that doesn't make sense, since their business is not in selling consoles (or graphics drivers), it's in selling games. the console is just another way to sell games. So, keeping that code closed means that they have to rebase upstream work against those patches, and hope mesa doesn't break that too bad, or send them upstream, and reap the benefits of someone else keeping that code working.

I lean towards the later, since that is what a smart company would do, and Valve is a smart company.

[mrugiero]

Yes, mesa is and has always been MIT, so valve *could* build custom versions of any of the drivers and only release binaries, but that doesn't make sense, since their business is not in selling consoles (or graphics drivers), it's in selling games. the console is just another way to sell games. So, keeping that code closed means that they have to rebase upstream work against those patches, and hope mesa doesn't break that too bad, or send them upstream, and reap the benefits of someone else keeping that code working.

I lean towards the later, since that is what a smart company would do, and Valve is a smart company.

You've got a good point, sir.