Valve & Intel Work On Open-Source GPU Drivers

[KameZero]

I'd be very glad to see this _anyhow_ resolved as we have all of our recent production compatible with Linux (we have developed _all_ of our projects natively on Linux), but without being able to run natively without the hassle, we have refrained the platform to avoid technical support issues.

Or just do what every other game release ever does: "We support nvidia/amd graphics with the binary blob drivers. Others may work but are unsupported."

[AJSB]

Or just do what every other game release ever does: "We support nvidia/amd graphics with the binary blob drivers. Others may work but are unsupported."

I believe that they gonna do just that....at least in a initial phase....

Then , as Nouveau increases and reaches an adequate level of performance, Valve will simply patch source engine to use it (assuming that it ever needs to be patched for Nouveau....possibly don't even will need to )

[Khudsa]

Why should anyone have to recompile their textures just for Linux? If Steam wants its Linux strategy to succeed, they need other publishers to step in and have the titles ready as soon as possible and with the smallest hassle.
I really do not see Valve telling everyone who ported their stuff to OSX (and for whose Linux is thus just around the corner) to somehow pick the game source data (which might even not exist today) and recompile everything, because of - oh, we're sorry, there is still unsorted patent issue on this platform we all have to workaround.

But the problem is elsewhere. Last time I tried to somehow sort this thing out, I asked on the dev-list if mesa would allow for precompressed texture pass through. This strategy required no patented algorithm implementation whatsoever. No S3TC, no S2TC, no libdxtn, no nothing, because no game in the last decade really depends on the true functionality of the EXT_texture_compression_s3tc. This extension merely states that the driver can compress/decompress the data on the fly. But everything is easily doable without having to support that extension by just using the generic ARB_texture_compression framework and having the textures precompressed with tools covered with the license and passing it to the s3tc capable hardware that is covered with a license. With this, the implementation can just report it accepts the S3TC data and can pass it through to the hardware. Done. No patented stuff touched at all.

But I was rejected because of (understandable) fears that the S3TC license terms are extremely broad and that it is possible that the license has to be granted on hardware/platofrm basis to even enable the circuitry of the hardware to enable the decompression. There is just common fear that we all have to avoid touching S3TC anything, data, hardware... you name it, unless the issue is correctly sorted.

Now tell me how the S2TC stuff workarounds this? In the end, the library tricks mesa and pushes the S2TC data through the very same hardware which I was forbidden even thinking about without the written consent of the patent holder.
I somehow doubt this is the way Valve wishes to go through and believe they have already sorted this out given their possible future plans. My question is - what did they do?

Please do not get me wrong, I would love to see the mesa accept S3TC data in any form, but I was rejected so many times that I have lost the faith that it can happen before the patent expires in 2017. And no, S2TC is apparently not a solution.

I have played Bastion. The introduction and little more with s3tc lib and the rest of the game with s2tc and I have seen any difference, why s2tc is not a solution?

[AJenbo]

The difference in quality between s3tc and s2tc is minimal, yet almost as wide as it is between s3tc and uncompressed. Personally if find it acceptable.

[Ansla]

Most games use precompressed textures, and for those all the driver has to do is to set a flag to let the hardware know that the texture is compressed. Bastion is most likely one of them.
There are however cases when the texture is not precompessed, for example a compositing window manager that will generate the textures at run time. I know Compiz has an option to enable texture compression so you could test that to see if the difference in quality is noticeable, not sure about other WMs.

[Hamish Wilson]

Then , as Nouveau increases and reaches an adequate level of performance, Valve will simply patch source engine to use it (assuming that it ever needs to be patched for Nouveau....possibly don't even will need to )

Since when was Nouveau the only free software graphics driver? Or even the most important?

[asdx]

Or just do what every other game release ever does: "We support nvidia/amd graphics with the binary blob drivers. Others may work but are unsupported."

If they are going to exclude Intel, why are they even working with the Intel people?

It doesn't make sense.

There needs to be a better solution for this.

[AJSB]

Since when was Nouveau the only free software graphics driver? Or even the most important?

I was using Nouveau as an example. It applies to others.

[Kano]

until nouveau has proper powermanagement it is useless for demanding games. even 2 monitor support can be critical when it stays at lowest performance level.

[9a3eedi]

I have played Bastion. The introduction and little more with s3tc lib and the rest of the game with s2tc and I have seen any difference, why s2tc is not a solution?

To be fair, Bastion is a pretty low-end 2D game, so maybe the difference between S3 and S2tc did't really matter. I think it would matter for other high-end 3D games though.

Why should anyone have to recompile their textures just for Linux? (etc.)

I might be missing something here, but if one wanted to port something to Linux, they'd most probably have to recompile everything anyway and generally optimize it for the platform (i.e. use X-related libraries, switch to OpenGL if they have to, or whatever).. so why not textures? They might as well recompile textures, it shouldn't be too much of a hassle, right? I haven't ported a game to Linux before so I wouldn't know but that's what I would imagine the process to be like.