Actually I would be very much interested in some pointers on where to start. I'm currently looking at the code of the r300 CS checker and trying to understand how the compressed formats are handled there. It seems natural to me to first get the DRM to accept these formats (instead of just disabling all texture checks) before moving into gallium territory.
And yes, I'm just looking at the hardware support for pre-compressed textures. I don't think libtxc_dxtn needs to be reimplemented, since it already does its work well.
@smitty3268: Like monraaf pointed out, there is already code in r600g to handle texture compression. It's just disabled by default (like tiling) and even if forcibly enabled clashes with the CS checker. This one can however be disabled for these specific tests. Since I wanted to know what already worked I disabled the CS texture check. Turns out that base levels are rendered correctly, but mip levels are not. And that's all what I explained in the bug and also here. Nothing more, nothing less.
Announcement
Collapse
No announcement yet.
AMD Releases Cayman Documentation, Open Driver Is Close
Collapse
X
-
Originally posted by monraaf View PostHmm, I'm not so sure about that. There's already some code related to S3TC in r600g, and afaik that was written by Red Hat employee Dave Airlie. Reading the bug report linked to by LiquidAcid (which btw was filed by a VMware employee), VMware also requires the drivers to have S3TC support, so it's not just only useful for games.
Leave a comment:
-
Originally posted by popper View Postohh right, so is this right LiquidAcid ? you may or not be looking into writing another algorithm that provides the same functionality and is OSS compliant to patch mesa ?
Leave a comment:
-
Originally posted by smitty3268 View PostHe also understands that Red Hat has no interest in fixing texture compression
Leave a comment:
-
Originally posted by smitty3268 View PostI think he was pretty clear the issue only appears WITH texture compression, not without it. He also understands that Red Hat has no interest in fixing texture compression, which is why he's looking into the code in the first place.
Leave a comment:
-
Originally posted by LiquidAcid View PostThere is no such issue. Read my post again.
it seems you are a dev and so can provide a simple GL test program as requested, and if your not a dev and looking for support then at least describe the exact steps you took to see this problem you want fixed.
without that, you're just going around in circles and wasting time.
Leave a comment:
-
Originally posted by glisse View PostI will make it crystal clear for you, provide a simple GL test program showing the issue with mipmap and no texture compression (ie something like RGB888 texture) and we will fix it. In all GL apps i use mipmap are working fine and i don't see any issue. You really need to be specific and to clearly shows the issue which you are not doing.
Leave a comment:
-
Originally posted by glisse View PostI will make it crystal clear for you, provide a simple GL test program showing the issue with mipmap and no texture compression (ie something like RGB888 texture) and we will fix it.
Leave a comment:
-
Originally posted by LiquidAcid View PostSry, but I think you're the one confusing things.
I don't know what you mean by orthogonal (since we lack a scalar product here *g*), but compressed textures are not limited to one base level, but can of course have mipmap levels. And that's what I'm taking about here:
Texture compression (BC1, BC2 and BC3 tested) works (see (*)) in r600g for the texture base level. Something goes wrong for the mipmaps and these are rendered incorrectly. You can see this e.g. in quake4, for which texture compression support is mandatory. Disable mipmaps via r_textureMode and everything looks fine (apart from the aliasing artifacts). The same applies to ut2004 which can optionally use texture compression. Near textures are rendered fine, but as soon as mipmaps are used farther away the rendering is broken.
(*) For this to work at all you have to:
1) Enable the R600_ENABLE_S3TC envvar
2) Patch the CS checker for ignore texture checks (otherwise all commands are rejected because of invalid texture formats)
Obviously they don't work for compressed texture formats.
And I never said you did. The only thing I'm doing here is some testing and fiddling around with the code. I very much _know_ that the support isn't there. Otherwise we wouldn't have this experimental envvar, right?
Wait, wait! This is _not_ my bug, ok?
And actually it's pretty clear what I did. In comment #2 I described that I enabled the envvar that enables texture compression advertising. And I also describe that this makes the CS checker angry. Then in comment #4 I describe that I get 'partial' results by disabling the texture check in the CS checker.
What is unclear for you now?
I don't think so. This is a ID Tech engine after all
Leave a comment:
-
Originally posted by glisse View PostGL3 or 4 are not a no go, we will have 99% (% top of my head where 1% is patented stuffed) of it advertised through appropriate extension. Question will be do we advertise GL version 3 or 4 without the patented stuff and throw glerror to program trying to use those, or do we go another way.
you're referring to for instance this S3TC algorithm everyone keep's bringing up right ?
if there's a patent on a given algorithm, then why dont you/mesa just write and use another algorithm that provides the same functionality and is OSS compliant ?
its clear that for instance the FFmpeg version that does so called DXT1 and DXT3 but not DXT5 as yet (as no one's bothered to write that code yet, and the S3TC entry is old too, so get to it and make it better ) see:
http://ffmpeg.org/doxygen/0.5/s3tc_8h-source.html and
is fine to use as your base today and its not even an algorithm as such but using different parts of the ffmpeg code base to simply provide the encode/decode bit exact input/output as required by the standard, with no algorithm patent problems to date.
Leave a comment:
Leave a comment: