https://bugs.freedesktop.org/show_bug.cgi?id=77693
--- Comment #2 from Roland Scheidegger <srol...@vmware.com> --- Ideally you'd just say you don't support s3tc, and leave it up to the application to not use such textures. I suspect it wouldn't get you very far though today (though I know some apps indeed can deal with this), and you can't actually even do it without deleting (or not installing...) libtxc_dxtn. If you'd really want to fake s3tc support that way for sw renderers, there's obviously some problems with your implementation: 1) there is a reason why the decode/encode code is not in mesa itself, this doesn't change if you decode the texture as a whole up front. The code admittedly is very inefficient for decompressing complete textures, though nothing would prevent a more efficient whole-block decompression interface. 2) You can't just intercept texstoreimage2d that way, that will give a lot of trouble. You'd also have to catch the texstoresubimage2d calls, and (more complicated) deal with all the other stuff which this affects. E.g. things like getCompressedTexImageARB would more or less require you to store the original image too, or just hope that it won't get called (which is very likely). You'd never get all the error conditions right neither (as compressed textures have a lot of restrictions) though I guess you might not particularly care about these neither. It would probably be cleaner if you'd still treat it as a compressed texture everywhere just with hacked up (and converted) format. In any case it would need to be configurable too. As a side note, it would of course be possible to make this code faster for llvmpipe's simd execution (with a different interface). -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
