Announcement
Collapse
No announcement yet.
Valve & Intel Work On Open-Source GPU Drivers
Collapse
X
-
Originally posted by Jonno View PostThey don't have to modify their texture sources in any way. Essentially it's a re-compile, which they will have to do for Linux anyway, so I don't see the big problem.
Thus, it'd very likely be lossy->lossy and so crappy quality.
In addition, the supported methods are either not worth anything (like the ETC on intel) or worse than s3tc.
Comment
-
Originally posted by Jonno View PostThey don't have to modify their texture sources in any way. Essentially it's a re-compile, which they will have to do for Linux anyway, so I don't see the big problem.
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.
Comment
-
Originally posted by petrs View PostI'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.
Comment
-
Originally posted by KameZero View PostOr 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."
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 )
Comment
-
Originally posted by petrs View PostWhy 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.
Comment
-
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.
Comment
-
Originally posted by AJSB View PostThen , 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 )Last edited by Hamish Wilson; 26 July 2012, 11:56 AM.
Comment
Comment