Summary: | Mesa software rasterizers - decompress textures on load to improve performance | ||
---|---|---|---|
Product: | Mesa | Reporter: | Liam Wilson <cosinusoidally> |
Component: | Drivers/Gallium/llvmpipe | Assignee: | mesa-dev |
Status: | RESOLVED MOVED | QA Contact: | |
Severity: | enhancement | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | Texture decompression patch |
Description
Liam Wilson
2014-04-20 18:38:39 UTC
Created attachment 97645 [details] [review] Texture decompression patch 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). -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/231. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.