meta: Fix invalid PBO access from DrawPixels when trying to just alloc.
This whole reuse of buffers (TexSubImage instead of TexImage, SubData
instead of Data) is bad for hardware drivers, but it's even worse when
we accidentally try to access the 2x2 PBO to fill the new 16x16 texture
we're creating, producing GL errors.
Fixes piglit pbo-drawpixels. Bug #14163.
Fix build on non GLIBC platforms (FreeBSD at least)
Build was broken by commit 9666529b5a
I'm not certain that this is entirely the correct fix since the demo
from bug #23774 seemed to work before the commit that broke the build.
Signed-off-by: Robert Noland <rnoland@2hip.net>
Signed-off-by: Brian Paul <brianp@vmware.com>
The main issue is we didn't always have a gallium texture object with
enough space to store the to-be-generated mipmap levels. When that's
the case, allocate a new gallium texture and use st_texure_finalize()
to copy images from the old texture to the new one.
We also had the baseLevel parameter to st_render_mipmap() wrong.
Don't compute the st_texture_object::lastLevel field based on the texture
filters. Use the _MaxLevel value that core Mesa computes for us.
When called from the GenerateMipmap path, we'll use the lastLevel field
as-is.
why there are two input position semantic tags is that ureg doesn't
set vs input semantic due to commit: 6d8dbd3d1e
so use vs input index instead of semantic name.
Not sure why we are getting a shader with two inputs with position semantic, but we don't know how to handle it correctly so it's better to stop the app than lock the machine.
Not 100% sure this is correct, but its more correct than what was here previous
however it may require changes in the input routing for the frag shader.