- Jan 13, 2012
-
-
Jakob Bornecrantz authored
Signed-off-by:
Jakob Bornecrantz <jakob@vmware.com>
-
Brian Paul authored
(cherry picked from commit 548526f2)
-
Emma Anholt authored
Fixes piglit EXT_framebuffer_multisample/negative-copypixels. Reviewed-by:
Brian Paul <brianp@vmware.com> NOTE: This is a candidate for the 8.0 branch. (cherry picked from commit 9be6654c)
-
Emma Anholt authored
Fixes piglit EXT_framebuffer_multisample/negative-copyteximage. Reviewed-by:
Brian Paul <brianp@vmware.com> NOTE: This is a candidate for the 8.0 branch. (cherry picked from commit 6950a4fa)
-
Emma Anholt authored
Fixes piglit EXT_framebuffer_multisample-negative-readpixels. Reviewed-by:
Brian Paul <brianp@vmware.com> NOTE: This is a candidate for the 8.0 branch. (cherry picked from commit 86b7c670)
-
Emma Anholt authored
Fixes piglit EXT_framebuffer_multisample/renderbuffer-samples. Reviewed-by:
Brian Paul <brianp@vmware.com> NOTE: This is a candidate for the 8.0 branch. (cherry picked from commit 0e8d156c)
-
Emma Anholt authored
Fixes some _mesa_problem()s in oglconform. Reviewed-by:
Brian Paul <brianp@vmware.com> NOTE: This is a candidate for the 8.0 branch. (cherry picked from commit f83756f8)
-
Emma Anholt authored
Previously, we were saying that everything from the starting tile to region width+height was part of the limits of our depthbuffer, even if the tile was near the bottom of the depthbuffer. This mean that our range was not clipping to buffer buonds if the start tile was anything but the start of the buffer. In bebc91f0, this was changed to saying that we're just rendering to a region of the size of the renderbuffer. This is great -- we get a range that should actually match what we want. However, the hardware's range checking occurs after the X/Y offset addition, so we were clipping out rendering to small depth mip levels when an X/Y offset was present. Just add tile_x/y to the width in that case -- the WM won't produce negative x/y values pre-offset, so we just need to get the left/bottom sides of the region to cover our buffer. Fixes the following Piglit regressions on gen7: spec/ARB_depth_buffer_float/fbo-clear-formats spec/ARB_depth_texture/fbo-clear-formats spec/EXT_packed_depth_stencil/fbo-clear-formats NOTE: This is a candidate for the 8.0 branch. (cherry picked from commit e6d6a10c)
-
When using Mesa with a GLES API, calling _mesa_FramebufferRenderbuffer with GL_DRAW_FRAMEBUFFER will report a 'user error' because get_framebuffer_target validates that this enum from the framebuffer blit extension is only used on GL. To work around it this patch makes it use the GL_FRAMEBUFFER enum instead in that case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43418 Note: This is a candidate for the 8.0 branch. Signed-off-by:
Chad Versace <chad.versace@linux.intel.com> (cherry picked from commit 9462b844)
-
Brian Paul authored
(cherry picked from commit 27915708)
-
Brian Paul authored
The AL44 format occupies one byte, not two. NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit b0af16ab)
-
Brian Paul authored
The gl_renderbuffer::Format field wasn't always set properly. This didn't matter much in the past but with the recent swrast/renderbuffer mapping changes, core Mesa will be directly touching OSMesa colorbuffers so using the right MESA_FORMAT_x value is important. Unfortunately, there aren't MESA_FORMATs for all the possible OSmesa format/type combinations, such as GL_FLOAT / OSMESA_ARGB. If anyone runs into these we can add new Mesa formats. v2: add warnings for unsupported formats, fix ARGB_REV mix-up. NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit 540a8b2c)
-
Brian Paul authored
(cherry picked from commit 0c14bbbc)
-
Brian Paul authored
Needed to implement the Map/UnmapRenderbuffer() driver hooks. This fixes glRead/Draw/CopyPixels, etc. See https://bugs.freedesktop.org/show_bug.cgi?id=44723 Note: This is a candidate for the 8.0 branch. Tested-by:
Kevin Hobbs <hobbsk@ohiou.edu> (cherry picked from commit cb254b75)
-
Brian Paul authored
(cherry picked from commit 062a4b60)
-
Brian Paul authored
This fixes accum buffer operations. The accumulation buffer is the only malloc-based renderbuffer for the intel drivers. v2: apply x/y offset to returned pointer NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit 6dbdc039)
-
Brian Paul authored
The array holds GLuint values so remove the float cast. Note, however, that to compute the average of four GLuints we really want to do (a+b+c+d)/4 but that could overflow. This change doesn't address that for now. NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit 003dd8ad)
-
Brian Paul authored
NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit 706400f0)
-
Brian Paul authored
ir_variable is a class, not a struct. NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit decd018b)
-
Brian Paul authored
In the first case, the newImage[] array contains GLuint values. In the second case, the parameter type is GLuint, but the maxDepth value is never used in this case (GL_FLOAT_32_UNSIGNED_INT_24_8_REV). Pass ~OU just to be safe. NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit a240c998)
-
Brian Paul authored
And pass integer width, height values. NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit 2f0fa456)
-
Brian Paul authored
(cherry picked from commit 0c57323d)
-
Brian Paul authored
glsl_to_tgsi_visitor is earlier defined as a class, not a struct. Fixes MSVC warning. NOTE: This is a candidate for the 8.0 branch. (cherry picked from commit 9f2963b6)
-
Brian Paul authored
Fixes build problems with the r200, radeon drivers. NOTE: This is a candidate for the 8.0 branch. (cherry picked from commit c7188ece)
-
Dave Airlie authored
This as per GL3 specification. Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Still some work to be done before this is finished. This is a candidate for 8.0 branch. Signed-off-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 3e044bcc)
-
- Jan 12, 2012
-
-
Thomas Hellstrom authored
Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com>
-
Thomas Hellstrom authored
Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com>
-
Jose Fonseca authored
Dirty flags also need to be updated in face of recent interface change. Fixes regression in compiz. Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Thomas Hellstrom authored
Some hardware versions rely on it to render correctly. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
José Fonseca <jfonseca@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com>
-
Brian Paul authored
The args to _mesa_reference_shader_program() can't be const. (cherry picked from commit 459a4446)
-
Brian Paul authored
(cherry picked from commit fe1b3896)
-
- Jan 11, 2012
-
-
Jakob Bornecrantz authored
Fix suggested by Kenneth Graunke. Signed-off-by:
Jakob Bornecrantz <jakob@vmware.com> Kenneth Graunke <kenneth@whitescape.org>
-
Anuj Phogat authored
glDrawBuffer(GL_FRONT_AND_BACK) results in to segmentation fault if intel->is_front_buffer_rendering is not enabled with GL_FRONT_AND_BACK. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44153 Reported-by:
Yi Sun <yi.sun@intel.com> Signed-off-by:
Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by:
Eric Anholt <eric@anholt.net>
-
Jakob Bornecrantz authored
Signed-off-by:
Jakob Bornecrantz <jakob@vmware.com> Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Jakob Bornecrantz authored
Signed-off-by:
Jakob Bornecrantz <jakob@vmware.com> Reviewed-by Brian Paul <brianp@vmware.com>
-
Ian Romanick authored
Instead, do the uniform setting and input / output mapping directly in brw_link_shader. Hurray for not generating Mesa IR! However, once the i965 driver stops calling _mesa_ir_link_shader, UsesClipDistance and UsesKill are no longer set. Ideally gen6_upload_vs_push_constants should use the gl_shader_program, but I don't see a way to propagate the information there. The other alternative, since this is the only usage, is to move gl_vertex_program::UsesClipDistance to brw_vertex_program. The compile (and precompile) stages use UsesKill to determine the cache key for the shader. This is then used to determine whether or not to compile the shader. Calculating this data during compilation is too late. Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com> Acked-by:
Kenneth Graunke <kenneth@whitecape.org> Acked-by:
Eric Anholt <eric@anholt.net>
-
Ian Romanick authored
This previously enabled some optimizations in the fragment shader (interpolation, etc.) if some input components were always 0.0 or 1.0. However, this data was generated by analyzing Mesa IR. The next patch in this series removes generation of Mesa IR for GLSL paths. When we detect that case, just set the used mask to ~0 and circumvent the optimizations. Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org>
-
Ian Romanick authored
It used to be done in ir_to_mesa, and that was kind of a bad place. I didn't change st_glsl_to_tgsi because there is some strange stuff happening in the code that generates glDrawPixels shaders. It looked like this would break horribly if I touched anything. Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org>
-
Ian Romanick authored
Track the calculated data in gl_shader_program instead of the individual assembly shaders. Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org>
-