If the user calls glRenderBufferTexture(texture=N) but texture N
doesn't name an existing texture, raise GL_INVALID_ENUM.
Plus, add a comment about some questionable error checking code in
framebuffer_texture(). Ian?
This fixes a problem in glReadPixels when reading from an FBO's texture
attachment. We have a better chance at hitting a fast path for
glReadPixels now.
There was a DrawBuffer/ReadBuffer typo and we were neglecting to invert
the texture coords when copying from a window to an FBO.
Plus, add some surface dump/debug code (disabled).
(cherry picked from commit 34f02071618624263eba839b5aeb930d0e794078)
Could result in use of freed memory and consequently random crashes, e.g. on
screen resize.
(cherry picked from commit 21c91b410a2a2cbf8eb677e59e3322f86320f2b0)
Conflicts:
src/gallium/state_trackers/xorg/xorg_tracker.h
add_dispatch (driver) and maybe get_proc_address (client) may be called before
set_dispatch is called, which results in generate_entrypoint using an unreloced
function template.
drivers need to handle NULL cso vertex elements (and others) objects.
It is possible the cso code saves/restores NULL objects (if no normal
cso object was bound before this was invoked).
This led to segfaults (for example demos/cubemap) for apps which were using
things like creating mipmaps before drawing anything.
This was a good idea, but ended up tying the build systems in knots.
We can revisit this later, in particular if we can put in place dummy
implementations of cell_create_screen(), llvmpipe_create_screen()
which just return NULL if the driver isn't available.
In the meantime, just duplicate this smallish function in the two
places it was being called.
Components such as state trackers, drivers, etc, should be free to be
recombined in arbtrary ways to build driver stacks. They should not
be reaching out and trying to build the stack themselves - this is now
expected to be handled by the "target" abstraction.
Add a helper gallium_wrap_screen() for injecting the commonly
used extra layers into a gallium stack. Currently that's just the
trace module and identity layer, but there could be more in the
future, eg. a validation layer.
Eric Anholt