Page 12 of 14 FirstFirst ... 21011121314 LastLast
Results 111 to 120 of 131

Thread: Valve & Intel Work On Open-Source GPU Drivers

  1. #111
    Join Date
    Nov 2008
    Posts
    77

    Default

    Quote Originally Posted by Jonno View Post
    There are several other texture compression formats supported by Mesa, and while not being compatible with pre-compressed S3TC textures, Valve could easily re-compress their textures for their Linux ports.
    Quote Originally Posted by petrs View Post
    While I agree it is technically possible I highly doubt this will attract other major developers to Linux/Steam if they have to modify their game resources. I might be wrong but this is probably not going to fly, something else needs to happen.
    They 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.

  2. #112
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,269

    Default

    Quote Originally Posted by Jonno View Post
    They 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.
    You're seriously overestimating the proprietary mindset. With them often losing even their app sources, do you really think they still have the master uncompressed copies of textures, models, and other assets?

    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.

  3. #113
    Join Date
    Jul 2012
    Posts
    4

    Default

    Quote Originally Posted by Jonno View Post
    They 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.
    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.

  4. #114
    Join Date
    Apr 2010
    Posts
    158

    Default

    Quote Originally Posted by petrs View Post
    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."

  5. #115
    Join Date
    Jul 2012
    Posts
    642

    Default

    Quote Originally Posted by KameZero View Post
    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 )

  6. #116
    Join Date
    Oct 2009
    Posts
    132

    Default

    Quote Originally Posted by petrs View Post
    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?

  7. #117
    Join Date
    Sep 2011
    Posts
    707

    Default

    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.

  8. #118
    Join Date
    Oct 2010
    Posts
    331

    Default

    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.

  9. #119
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    1,050

    Default

    Quote Originally Posted by AJSB View Post
    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?
    Last edited by Hamish Wilson; 07-26-2012 at 12:56 PM.

  10. #120
    Join Date
    Jul 2012
    Posts
    642

    Default

    Quote Originally Posted by Hamish Wilson View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •