| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
In addition to being HW accelerated, it avoids the incorrect
(black) rendering of the mipmaps that SW was doing in fbo-generatemipmap.
Improves the performance of the mipmap generation and drawing in
fbo-generatemipmap by 30%.
|
|
|
|
|
|
There were hacks in EmitCopyBlit before to adjust offsets so that y=0 after
the offsets had been adjusted for a negative pitch. It appears that those
hacks were due to an unclear and surprising aspect of the hardware: inverting
the pitch results in the blit into the specified rectangle being inverted,
without the user needing to adjust y and base offset.
Tested with piglit copytexsubimage test on 915GM and GM965. Should fix
serious performance issues with ETQW and other applications.
|
|
Makefile.template
|
|
Previously, the updated images would be ignored because the miptree in the
image matched the miptree in the object, even though Mesa core had just attached
updated contents in ->Data. Additionally, Mesa core could have tried to
free inside our miptree if it had already been validated.
Fixes bug #17077.
|
|
|
|
|
|
function."
This reverts commit c50ffc4cb89b67ae59208eb72cdb664c846ba987.
I'll fix this using the mipmap hooks I just picked from gallium-0.1
|
|
This at least stops the compiz brain explosion we were seeing, I do wonder
though if we should somehow be calling intel_generate_mipmap somehow.
|
|
Failure to consistently do so resulted in mismatched aligned versus
unaligned alloc/free.
|
|
|
|
The core problem was that _mesa_generate_mipmap was not respecting RowStride
of the source image. Additionally, the intel private data associated with the
images (level and face) was not being initialized for the
_mesa_generate_mipmap-generated images.
|
|
This removes the delayed texture upload optimization from 965, in exchange for
bringing us closer to PBO support. It also disables SGIS_generate_mipmap,
which didn't seem to be working before anyway, according to the lodbias demo.
|
|
|
