- Jun 25, 2011
-
-
Stéphane Marchesin authored
This fixes a crash in llvm draw.
-
Emma Anholt authored
If we happened to allocate a texture result (or other vector) to the highest hardware register slot, and we were in 16-wide, we would under-count the registers used and potentially wrap around to g0 if that allocation crossed a 16-register block boundary. Bad rendering and hangs ensued. Tested-by:
Ian Romanick <idr@freedesktop.org>
-
Stéphane Marchesin authored
Those always return 0, but at least we don't crash when exposing GL 2.0.
-
- Jun 24, 2011
-
-
Stéphane Marchesin authored
-
Stéphane Marchesin authored
-
Brian Paul authored
When the fill mode is PIPE_POLYGON_MODE_LINE we were basically converting the polygon into triangles, then drawing the outline of all the triangles. But we really only want to draw the lines around the perimeter of the polygon, not the interior lines. NOTE: This is a candidate for the 7.10 branch.
-
Paul Berry authored
In gen6 and above, clip distances 0-3 are written to message register 3's xyzw components, and 4-7 to message register 4's xyzw components. Therefore when when writing the clip distances we need to examine the lower 2 bits of the clip distance index to see which component to write to. emit_vertex_write() was examining the lower 3 bits, causing clip distances 4-7 not to be written correctly. Fixes piglit test vs-clip-vertex-01.shader_test
-
Alex Deucher authored
Signed-off-by:
Alex Deucher <alexdeucher@gmail.com>
-
Alex Deucher authored
Evergreen+ don't support multi-writes so we need to emulate it in the shader. Fixes the following piglit tests: fbo-drawbuffers-fragcolor ati_draw_buffers-arbfp-no-option Signed-off-by:
Alex Deucher <alexdeucher@gmail.com>
-
Lina Versace authored
In intel_draw_buffer, there exists a workaround to prevent _mesa_update_framebuffer from creating a swrast depth wrapper when using separate stencil. This commit fixes the workaround, which was incomplete for s8z24 texture renderbuffers. Fixes fbo-blit-d24s8 on gen5 with separate stencil manually enabled. Signed-off-by:
Chad Versace <chad@chad-versace.us>
-
Lina Versace authored
Since all infrastructure is now in place to support packed depth/stencil renderbuffers when using separate stencil, there is no need for special cases when separate stencil is enabled. Signed-off-by:
Chad Versace <chad@chad-versace.us>
-
Lina Versace authored
Also, in order to coerce intel_update_tex_wrapper_regions() to allocate the hiz region, alter intel_update_tex_wrapper_regions() to examine the renderbuffer format instead of the texture image format. Signed-off-by:
Chad Versace <chad@chad-versace.us>
-
Lina Versace authored
... and into new function intel_update_tex_wrapper_regions. This prevents code duplication in the next commit. Also add a note explaining that the hiz region is broken for mipmapped depth textures. Signed-off-by:
Chad Versace <chad@chad-versace.us>
-
Lina Versace authored
... when using separate stencil. Define function intel_tex_image_x8z24_create_renderbuffers and call it in intelTexImage after the miptree has been created and filled with data. Signed-off-by:
Chad Versace <chad@chad-versace.us>
-
Lina Versace authored
... because they will be needed by intel_tex_image_s8z24_create_renderbuffers. Redeclared functions are: intel_alloc_renderbuffer_storage intel_renderbuffer_set_draw_offsets Signed-off-by:
Chad Versace <chad@chad-versace.us>
-
Lina Versace authored
Redeclare as non-static because intel_tex_image_s8z24_create_renderbuffers will use it. Remove the 'wrapper' parameter, because there is no wrapper for intel_texture_image.depth_rb and stencil_rb. Signed-off-by:
Chad Versace <chad@chad-versace.us>
-
Lina Versace authored
Signed-off-by:
Chad Versace <chad@chad-versace.us>
-
Lina Versace authored
... which copy the stencil bits between intel_image->depth_rb and intel_image->stencil_rb. Signed-off-by:
Chad Versace <chad@chad-versace.us>
-
Lina Versace authored
Add the fields depth_rb and stencil_rb, and put hooks in place to release the renderbuffers in intelFreeTextureImageData and intelTexImage. Signed-off-by:
Chad Versace <chad@chad-versace.us>
-
Stéphane Marchesin authored
Otherwise we can end up creating RGBA render targets (which are BGRA on the hardware), and then we bind them as RGBA textures (which are RGBA on the hardware). This generates software fallbacks every time we bind the frame as a texture.
-
Marek Olšák authored
Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Marek Olšák authored
NOTE: This is a candidate for the 7.10 branch. Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Marek Olšák authored
NOTE: This is a candidate for the 7.10 branch.
-
Marek Olšák authored
Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Brian Paul authored
Commit 1a339b6c caused us to take a different path through the glCopyTexSubImage() code. The pipe_get_transfer() call neglected to pass the texture's level, face and slice info. So we were always transferring from the 0th mipmap level even when the source renderbuffer was a non-zero mipmap level in a texture. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38649 NOTE: This is a candidate for the 7.10 branch.
-
Benjamin Franzke authored
-
Vadim Girlin authored
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38440 Signed-off-by:
Vadim Girlin <vadimgirlin@gmail.com>
-
Vadim Girlin authored
Signed-off-by:
Vadim Girlin <vadimgirlin@gmail.com>
-
Vadim Girlin authored
Signed-off-by:
Vadim Girlin <vadimgirlin@gmail.com>
-
Emma Anholt authored
Once again, assuming the compiler is clever works out so poorly. The generated code initialized the structure on the stack, then did a lookup into it. This was a performance regression from 70c6cd39. Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com>
-
Emma Anholt authored
Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com>
-
Emma Anholt authored
This was sucking up 1% of the CPU on 3DMMES. Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com>
-
Emma Anholt authored
It's common in applications just before the advent of EXT_separate_shader_objects to have multiple linked shaders with the same VS or FS. While we aren't detecting those at the Mesa level, we can detect when our compiled output happens to match an existing compiled program. This patch was created after noting the incredible amount of compiled program data generated by Heroes of Newerth. It reduces the program data in use at the start menu (replayed by apitrace) from 828kb to 632kb, and reduces CACHE_NEW_WM_PROG state flagging by 3/4. It doesn't impact our rate of hardware state changes yet, because things depending on CACHE_NEW_WM_PROG also depend on BRW_NEW_FRAGMENT_PROGRAM which is still being flagged. Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com>
-
Brian Paul authored
Fixes regression from d631c19d. See http://bugs.freedesktop.org/show_bug.cgi?id=38626
-
This patch add the support for 24bpp in the dri/swrast implementation. Signed-off-by:
Marc Pignat <marc@pignat.org> Signed-off-by:
Brian Paul <brianp@vmware.com>
-
Brian Paul authored
-
Brian Paul authored
-
Signed-off-by:
Alon Levy <alevy@redhat.com> Signed-off-by:
Brian Paul <brianp@vmware.com>
-
Chia-I Wu authored
Use a typed struct to describe the native buffer and let the backends map the native buffer to winsys_handle for resource_from_handle/resource_to_handle.
-
Chia-I Wu authored
Not used.
-