| Age | Commit message (Collapse) | Author |
|---|
|
|
|
We now share the type/format -> MESA_FORMAT_* mappings with software
mesa, and the core supports most of the fallbacks hardware drivers
will want.
|
|
In testing on Ironlake, the histogram of clocks/pixel results for the
system memcpy and magic unaligned memcpy show no noticeable difference
(and no statistically significant difference with the 5510 samples
taken, though the stddev is large due to what looks like the cache
effects from the different texture sizes used).
|
|
This provides the optimizer with hints about code hotness, which we're
quite certain about for debug printouts (or, rather, while we
developers often hit the checks for debug printouts, we don't care
about performance while doing so).
|
|
|
|
This is already NULL'ed in _mesa_init_driver_functions.
|
|
|
|
It always returned 1 (GL_TRUE), which is the same thing that happens when
the driver hook isn't present.
|
|
|
|
Need to restore code that fixed up the intel_texture_image state.
|
|
Need to check if we'll take the software path so which requires mapping the
src texture image.
Fixes crash in piglit gen-compressed-teximage, bug 24219. However, the
test still does not pass (it may never have).
|
|
|
|
|
|
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.
|
|
|
