vap index offset is programmed to 0 by the kernel, it
would add work to kernel checker to allow userspace
programming of this so it's now disallowed with CS
on KMS.
Two parts to this:
One we don't keep pointers to possibly freed memory anymore once we unbind the
drawables from the context. Brian I need to figure out what the comment
you made there, can we get a glean/piglit test so we can fix it properly?
If the new gc is the same as the oldGC, we call the unbind even though
we just bound it in that function. doh.
For the TXP instruction we check if the texcoord is really a 4-component
atttibute which requires the divide by W step. This check involved the
projtex_mask field. However, the projtex_mask field was being miscalculated
because of some confusion between vertex program outputs and fragment
program inputs.
1. Rework the size_masks calculation so we correctly set bits corresponding
to fragment program input attributes.
2. Rename projtex_mask to proj_attrib_mask since we're interested in more
than just texcoords (generic varying vars too).
3. Simply the indexing of the size_masks and proj_attrib_mask fields.
4. The tracker::active[] array was mis-dimensioned. Use MAX_PROGRAM_TEMPS
instead of a magic number.
5. Update comments, add new assertions.
With these changes the Lightsmark demo/benchmark renders correctly, until
we eventually hit a GPU lockup...
For some triangles we can generate quads which lie just outside the
surface bounds. Just check the quad's mask before trying to emit/process
the quad.
Fixes failed assertion in Lightsmark.
glsl compiler will not generate OPCODE_SWZ, and as a first step it would
be translated away to a MOV anyway (why?), but later internally this opcode is
generated (for EXT_texture_swizzling).
Render results are only visible when the render cache is flushed.
softpipe_is_texture_referenced must reflect that or transfers to/from the
textures bound in the framebuffer won't be proceeded of the necessary
flush, causing transfer data to be outdated/clobbered.
This fixes conform drawpix test with softpipe.
Reverts part of commit d7ea9ddf58.
We were calling _mesa_reference_buffer_object() on some heap-allocated
memory that was uninitialized and could trigger an assertion.
We can actually go back to "looser" ref counting of the Null/default
buffer object in these cases.
...rather than with linear interpolation. Modern hardware should use
perspective-corrected interpolation for colors (as for texcoords).
glHint(GL_PERSPECTIVE_CORRECTION_HINT, mode) can be used to get
linear interpolation if mode = GL_FASTEST.
When the -arb option is specified we use GL_ARB_framebuffer_object intead
of GL_EXT_framebuffer_object.
For some vendors' OpenGL it's important to call the ARB entrypoints
instead of the EXT entrypoints to get correct behaviour. Use some
function pointer tricks to do this (instead of GLEW).
We currently don't have support for SGI_swap_control for direct
contexts with DRI2, so disable reporting the extension. Reporting
the extension, and then having glXSwapIntervalSGI() "succeed"
but do nothing can confuse applications.
https://bugs.freedesktop.org/show_bug.cgi?id=22123