- Jul 19, 2011
-
-
Ian Romanick authored
-
Brian Paul authored
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
-
Kenneth Graunke authored
This is a squash cherry pick commit of: glsl: Find the "closest" signature when there are multiple matches. Previously, ir_function::matching_signature had a fatal bug: if a function had more than one non-exact match, it would simply return NULL. This occured, for example, when looking for max(uvec3, uvec3): - max(vec3, vec3) -> score 1 (found first) - max(ivec3, ivec3) -> score 1 (found second...used to return NULL here) - max(uvec3, uvec3) -> score 0 (exact match...the right answer) This did not occur for max(ivec3, ivec3) since the second match found was an exact match. The new behavior is to return a match with the lowest score. If there is an exact match, that will be returned. Otherwise, a match with the least number of implicit conversions is chosen. Fixes piglit tests max-uvec3.vert and glsl-inexact-overloads.shader_test. NOTE: This is a candidate for the 7.10 and 7.11 branches. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit 60eb63a8) glsl: Suppress warning from matching_signature change. gcc isn't smart enough to see that we only look at matched_score after we've initialized it (because match != NULL happens at the same time) (cherry picked from commit b043409a) glsl: Reject ambiguous function calls (multiple inexact matches). According to the GLSL 1.20 specification, "it is a semantic error if there are multiple ways to apply [implicit] conversions [...] such that the call can be made to match multiple signatures." Fixes a regression caused by 60eb63a8, which implemented the wrong policy of finding a "closest" match. However, this is not a revert, since the original code failed to continue looking for an exact match once it found two inexact matches. It's OK to have multiple inexact matches if there's also an exact match. NOTE: This is a candidate for the 7.10 and 7.11 branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38971 Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 7304909d)
-
Paul Berry authored
This brings us into compliance with page 17 (page 22 of the PDF) of the GLSL 1.20 spec: "[Sampler types] can only be declared as function parameters or uniform variables (see Section 4.3.5 "Uniform"). ... [Samplers] cannot be used as out or inout function parameters." The spec isn't explicit about whether this rule applies to structs/arrays containing shaders, but the intent seems to be to ensure that it can always be determined at compile time which sampler is being used in each texture lookup. So to avoid creating a loophole, the rule needs to apply to structs/arrays containing shaders as well. Fixes piglit tests spec/glsl-1.10/compiler/samplers/*.frag, and fixes bug 38987. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38987 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit f0722105)
-
Paul Berry authored
The new location, as a member function of glsl_type, is more consistent with queries like is_sampler(), is_boolean(), is_float(), etc. Placing the function inside glsl_type also makes it available to any code that uses glsl_types. (cherry picked from commit ddc1c963)
-
Ian Romanick authored
The GLSL spec says: "If a built-in function is redeclared in a shader (i.e., a prototype is visible) before a call to it, then the linker will only attempt to resolve that call within the set of shaders that are linked with it." This patch enforces this behavior. When a function call is processed a flag is set in the ir_call to indicate whether the previously seen prototype is the built-in or not. At link time a call will only bind to an instance of a function that matches the "want built-in" setting in the ir_call. This has the odd side effect that first call to abs() in the shader below will call the built-in and the second will not: float foo(float x) { return abs(x); } float abs(float x) { return -x; } float bar(float x) { return abs(x); } This seems insane, but it matches what the spec says. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31744 (cherry picked from commit 66f4ac98)
-
Ian Romanick authored
This version is mostly Dan's post to the mesa-dev mailing list on 6/22/2011. NOTE: This is a candidate for the 7.10 and 7.11 branches. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Dan Nicholson <dbn.lists@gmail.com> (cherry picked from commit db311b45)
-
Kenneth Graunke authored
This is exactly analogous to Eric's Gen6 change in commit 6861a701. His explanation: "This is just like PointSprite overrides, but it's always on for that attribute." Fixes glsl-fs-pointcoord and gtf/point_sprites. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> (cherry-picked from commit 186e37c7)
-
Kenneth Graunke authored
This is exactly analogous to Eric's Gen6 change in commit f304bb8a. His explanation: "We were assuming that the input attribute n to the FS was FRAG_ATTRIB_TEXn, which happened to be true often enough for our testcases." Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> (cherry-picked from commit 147d0102)
-
Kenneth Graunke authored
This is exactly analogous to Eric's Gen6 change in commit e7280b16. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> (cherry-picked from commit 5edb3ddf)
-
Kenneth Graunke authored
Commit b46dc45c claimed that NEW_POLYGONSTIPPLE is gratuitous, but somehow just changed comments and whitespace instead of actually removing the flag. While we're at it, 3DSTATE_PS doesn't appear to need NEW_LINE or NEW_POLYGON either (those are in 3DSTATE_WM). Also, 3DSTATE_WM doesn't appear to need BRW_NEW_NR_WM_SURFACES or BRW_NEW_CURBE_OFFSETS either (those are in 3DSTATE_PS). Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> (cherry-picked from commit 57b57f6d)
-
Henri Verbeet authored
This fixes a regression introduced by commit a26121f3 (fd.o bug #39219). Since the __glXInitialize() call should be unnecessary anyway, this is probably a nicer fix for the original problem too. NOTE: This is a candidate for the 7.10 and 7.11 branches. Signed-off-by: Henri Verbeet <hverbeet@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Tested-by: <padfoot@exemail.com.au> (cherry picked from commit 0f20e2e1)
-
Lina Versace authored
Until now, the stencil buffer was allocated as a Y tiled buffer, because in several locations the PRM states that it is. However, it is actually W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part 2, Section 4.5.2.1 W-Major Format: W-Major Tile Format is used for separate stencil. The GTT is incapable of W fencing, so we allocate the stencil buffer with I915_TILING_NONE and decode the tile's layout in software. This fix touches the following portions of code: - In intel_allocate_renderbuffer_storage(), allocate the stencil buffer with I915_TILING_NONE. - In intel_verify_dri2_has_hiz(), verify that the stencil buffer is not tiled. - In the stencil buffer's span functions, the tile's layout must be decoded in software. This commit mutually depends on the xf86-video-intel commit dri: Do not tile stencil buffer Author: Chad Versace <chad@chad-versace.us> Date: Mon Jul 18 00:38:00 2011 -0700 On Gen6 with separate stencil enabled, fixes the following Piglit tests: bugs/fdo23670-drawpix_stencil general/stencil-drawpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-copypixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-readpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-copypixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-readpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-copypixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-drawpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-readpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-copypixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-readpixels spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-copypixels spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels spec/EXT_packed_depth_stencil/readpixels-24_8 Note: This is a candidate for the 7.11 branch. Signed-off-by: Chad Versace <chad@chad-versace.us> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit f7dbcba2)
-
- Jul 18, 2011
-
-
Vadim Girlin authored
-
Christoph Bumiller authored
-
Christoph Bumiller authored
Because we don't support them. For instance, R32G32B32 is not R32G32B32X32 as was assumed. Add support for R8G8B8X8_UNORM instead of R8G8B8_UNORM surfaces.
-
- Jul 15, 2011
-
-
Vadim Girlin authored
Use all zpass data for predication instead of the last block only. Use query buffer as a ring instead of reusing the same area for each new BeginQuery. All query buffer offsets are in bytes to simplify offsets math.
-
Alex Deucher authored
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
- Jul 14, 2011
-
- Jul 13, 2011
-
-
Emma Anholt authored
We advertised ARB_draw_buffers, but either fell back to software when using this output, or assertion failed. Fixes glsl-fs-fragdata-1, and failures in some webgl conformance tests. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39024 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34906 (cherry picked from commit 556a47a2)
-
Emma Anholt authored
We were failing at rounding, misplacing the non-baselevels. Fixes: 3DFX_texture_compression_FXT1/fbo-generate-mipmaps ARB_texture_compression/fbo-generate-mipmaps EXT_texture_compression_s3tc/fbo-generate-mipmaps Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit f2fd0d63)
-
Emma Anholt authored
The first rendering after context create didn't know of the color buffer yet, triggering a sw fallback. The intel_prepare_render() from intelSpanRenderStart then found the buffer and turned off fallbacks, but intelSpanRenderFinish was never called and things were left mapped. By checking buffers before making the call on whether to do the fallback pipeline or not, we avoid the fallback change inside of the rendering pipeline. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31561 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 6e6b3886)
-
Emma Anholt authored
There's no pretty way to avoid the overwriting of the src operands, so just use a temporary destination and rely on the MOV optimization. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 46a76391)
-
Emma Anholt authored
We were stomping over the source for the body of the LIT instruction when doing the MOV of 1.0 to the uninteresting channels. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit e3ea5bc0)
-
Emma Anholt authored
Even if we don't have a current context, if we're freeing the rb we should free its region (and BO). The renderbuffer unreference checks appear to be just cargo-cult from the region unreference code. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30217 Reviewed-by: Chad Versace <chad@chad-versace.us> (cherry picked from commit 007c2d6c)
-
Emma Anholt authored
This should help us avoid leaking regions in region reference code by making the API more predictable. Reviewed-by: Chad Versace <chad@chad-versace.us> (cherry picked from commit 036b74a7) (cherry picked from commit d8f65c07)
-
Emma Anholt authored
(cherry picked from commit abbbd14d)
-
Emma Anholt authored
This was a requirement we didn't run into until we started using STATE_BASE_ADDRESS for instruction data. (cherry picked from commit a09c5c2e)
-
Emma Anholt authored
The scissor state was incorrectly in a .prepare function instead of .emit, so the packet would end up in the batch before the STATE_BASE_ADDRESS. It appears that this doesn't actually hurt, as the scissor address gets dereferenced according to the current SBA at draw time. (cherry picked from commit cd7bfd5d)
-
Stéphane Marchesin authored
-
- Jul 12, 2011
-
-
Alex Deucher authored
Need to be initialized to a reasonable value as compute code may change it. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=39119 NOTE: This is a candidate for the 7.11 branch. Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
-
Brian Paul authored
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38842 NOTE: This is a candidate for the 7.11 branch. (cherry picked from commit d60880db)
-
Brian Paul authored
(cherry picked from commit bb0d5cae)
-
Benjamin Franzke authored
NOTE: This is a candidate for the 7.11 branch. (cherry picked from commit 7ed1826e)
-
Benjamin Franzke authored
NOTE: This is a candidate for the 7.11 branch. (cherry picked from commit 9b8cd499)
-
Benjamin Franzke authored
NOTE: This is a candidate for the 7.11 branch. (cherry picked from commit b18b2994)
-
Benjamin Franzke authored
NOTE: This is a candidate for the 7.11 branch. (cherry picked from commit b2d6375e)
-
Benjamin Franzke authored
NOTE: This is a candidate for the 7.11 branch. (cherry picked from commit 992680c8)
-
- Jul 11, 2011
-
-
Marek Olšák authored
NOTE: This is a candidate for the 7.10 and 7.11 branches. (cherry picked from commit d1214cca)
-
Marek Olšák authored
From ARB_framebuffer_object: If a buffer is specified in <mask> and does not exist in both the read and draw framebuffers, the corresponding bit is silently ignored. (cherry picked from commit 83478e5d)
-