| Age | Commit message (Collapse) | Author |
|---|
|
Replace calls to ctx->Driver.CompressedTextureSize with calls to
_mesa_format_image_size. The former always called the later.
|
|
And remove other unneeded #includes while we're at it.
|
|
Call it from in the main Mesa glTexImage functions.
|
|
Just call ctx->Driver.CompressedTextureSize() when we need to get
the compressed image size.
|
|
|
|
Use _mesa_is_format_compressed() instead.
|
|
Now gl_texture_image::TexFormat is a simple MESA_FORMAT_x enum.
ctx->Driver.ChooseTexture format also returns a MESA_FORMAT_x.
gl_texture_format will go away next.
|
|
|
|
|
|
|
|
|
|
Per the suggestion in the Intel driver, move the calls to
ctx->Driver.GenerateMipmap() into core Mesa so that drivers don't
have to worry about it.
|
|
We need to figure out if the compression format changes.
without this texcmp segfaults if you change format
enough times.
|
|
Converted r100 to use shared debug code with sed and fast compile check. New
code has compability layer so old debugging code doesn't have to be changed
all immidiatly.
|
|
- fix not respecting required hardware stride with compressedTexImage -
this fixes #22615.
- make sure correct stride is used in various places
- fix stored miptree never matching with a TexImage call with compressed
texture
- don't always store data with compressedtexsubimage at offset 0,
and actually use the supplied pixel data... (untested)
- make sure rows for compressed texture handling are rounded up not down
Note that trying to access stored compressed textures in hardware miptrees
from core mesa (get_compressed_teximage, swrast fallbacks) can't work correctly,
since RowStride isn't really set to anything useful, plus some places (at least
get_compressed_teximage) assume this data has native stride and no padding.
|
|
|
|
into r6xx-rewrite
This builds, but I get an assertion in radeonGetLock() due to
the drawable being null.
|
|
need to pass target parameter to radeon_teximage/radeon_subteximage functions
otherwise mipmap generation for cube maps can't work (assert/segfault in
_mesa_generate_mipmap)
|
|
|
|
Tested with glean/texture_srgb and wine/d3d9 tests on RV535
|
|
|
|
This gets the correct srclvl image map when uploading images to the new mipmap.
|
|
|
|
When a NULL value of pixels is passed to TexImage2D and
SGIS_generate_mipmap is enabled, don't try to generate the
mipmap tree: we don't have data yet for the texture and will
crash.
https://bugs.freedesktop.org/show_bug.cgi?id=21648
|
|
|
|
This might trip up some serious FBO users, will have to see, but
it avoids the slow paths for all the demos I have.
|
|
|
|
|
|
if you hit this you've already failed but we shouldn't crash
|
|
|
|
|
|
This replaces a miptree if it won't distrub anything else.
|
|
this makes compressed subimages work properly.
|
|
|
|
Since texture images are now stored in miptrees, we cannot usually
access them directly via the Data pointer.
So we wrap Mesa's implementation by map/unmap calls.
This crash was triggered by Sauerbraten, Piglit now contains a
regression test.
Signed-off-by: Nicolai Haehnle <nhaehnle@gmail.com>
|
|
|
|
|
|
|
|
tested on r200, texcmp works. May need more verification
|
|
|
