- Mar 21, 2012
-
-
Jakob Bornecrantz authored
Signed-off-by:
Jakob Bornecrantz <jakob@vmware.com>
-
Jakob Bornecrantz authored
Signed-off-by:
Jakob Bornecrantz <jakob@vmware.com>
-
Jakob Bornecrantz authored
Signed-off-by:
Jakob Bornecrantz <jakob@vmware.com>
-
Brian Paul authored
-
- Mar 20, 2012
-
-
There's even a comment in the code containing the right swizzling computations! Previously this has not been noticed because we need to manually enabled swizzling on snb/ivb (kernel 3.4 will do that) and we don't use the separate stencil on ilk (where the bios enables swizzling). This fixes piglit ./bin/fbo-stencil readpixels GL_DEPTH32F_STENCIL8 -auto on recent drm-intel-next kernels. Also remove the comment about ivb, it's stale now. Swizzling detection is done by allocating a temporary x-tiled buffer object. Unfortunately kernels before v3.2 lie on snb/ivb because they claim that swizzling is enable, but it isn't. The kernel commit that fixes this for backport to pre-v3.2 is commit acc83eb5a1e0ae7dbbf89ca2a1a943ade224bb84 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Sep 12 20:49:16 2011 +0200 drm/i915: fix swizzling on gen6+ But if the kernel doesn't lie, this now works on swizzling and not swizzling machines. NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit f172eae8)
-
This checks for advertised LLC support by the GPU instead of relying on the GPU generation for detection. Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> (cherry picked from commit 84e5f1c6)
-
Rely on libdrm HAS_LLC parameter to verify if hardware supports it. In case the libdrm version does not supports this check, fallback to older way of detecting it which assumed that GPUs newer than GEN6 have it. Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> (cherry picked from commit 7def2932)
-
Kenneth Graunke authored
Kernels prior to 271d81b84171d84723357ae6d172ec16b0d8139c (March 2011) don't support relocations outside of the target buffer object. Rather than guarding this with a I915_PARAM_HAS_RELAXED_DELTA check, just smash the bound to 0xfffff001 like we do on Ironlake. This effectively gives us no upper bound check, just like we did prior to commit 271d81b84171d84723357ae6d172ec16b0d8139c. Daniel Vetter would also like to mention that this relies on the guard page at the end of the GTT. Fixes a regression since 271d81b84171d84723357ae6d172ec16b0d8139c. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46766 Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit b2ace06c)
-
Dylan Noblesmith authored
The error was removed in: commit 71990969 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Tue Oct 18 16:01:49 2011 -0700 mesa: Rewrite the way uniforms are tracked and handled The GL_ARB_robustness spec doesn't say the implementation should truncate the output, so just return after setting the required error like it did before the above commit. Also fixup an old comment and add an assert. NOTE: This is a candidate for the 8.0 branch. (cherry picked from commit b536ac6b)
-
- Mar 19, 2012
-
-
Yuanhan Liu authored
Although some hardware support NPOT cubemap, but it seems we don't know the right layout for NPOT cubemap. Thus seems we need do fallback for other platforms as well. See comments inline the code for more detailed info. v2: give a more detailed info about why we need fallback for other platfroms as well. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46666 NOTE: This is a candidate for stable release branches. Signed-off-by:
Yuanhan Liu <yuanhan.liu@linux.intel.com> (cherry picked from commit 40c995c1)
-
- Mar 17, 2012
-
-
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston <jeremyhu@apple.com> (cherry picked from commit 90a51753)
-
Jeremy Huddleston Sequoia authored
Fixes a build regression from: 588042a8 Signed-off-by:
Jeremy Huddleston <jeremyhu@apple.com> (cherry picked from commit f9e1295c)
-
Jeremy Huddleston Sequoia authored
Set our default compiler based on what our installed XCode prefers Signed-off-by:
Jeremy Huddleston <jeremyhu@apple.com> (cherry picked from commit 61f6aff5)
-
- Mar 16, 2012
-
-
Yuanhan Liu authored
This patch add the support of gl_PointCoord gl builtin variable for platform gen4 and gen5(ILK). Unlike gen6+, we don't have a hardware support of gl_PointCoord, means hardware will not calculate the interpolation coefficient for you. Instead, you should handle it yourself in sf shader stage. But badly, gl_PointCoord is a FS instead of VS builtin variable, thus it's not included in c.vue_map generated in VS stage. Thus the current code doesn't aware of this attribute. And to handle it correctly, we need add it to c.vue_map manually to let SF shader generate the needed interpolation coefficient for FS shader. SF stage has it's own copy of vue_map, thus I think it's safe to do it manually. Since handling gl_PointCoord for gen4 and gen5 platforms is somehow a little special, I added a lot of comments and hope I didn't overdo it ;) v2: add a /* _NEW_BUFFERS */ comment to note the state flag dependency and also add the _NEW_BUFFERS dirty mask (Eric). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45975 Piglit: glsl-fs-pointcoord and fbo-gl_pointcoord NOTE: This is a candidate for stable release branches. Signed-off-by:
Yuanhan Liu <yuanhan.liu@linux.intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit 43af02ac)
-
Yuanhan Liu authored
We have to do fallback when the 'Clipped Drawing Rectangle X/Y Max' exceed the hardware's limit no matter the drawing rectangle offset changed or not. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46665 NOTE: This is a candidate for stable release branches. Signed-off-by:
Yuanhan Liu <yuanhan.liu@linux.intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit cf2f9ef0)
-
Yuanhan Liu authored
The current code would ignore the point size specified by gl_PointSize builtin variable in vertex shader on Pineview. This patch servers as fixing that. This patch fixes the following issues on Pineview: webglc: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/rendering/point-size.html piglit: glsl-vs-point-size NOTE: This is a candidate for stable release branches. v2: pick Eric's nice tip for fixing this issue in hardware rendering. v3: the last arg of EMIT_ATTR specify the size in _byte_. (Eric) Signed-off-by:
Yuanhan Liu <yuanhan.liu@linux.intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit 058fc652)
-
Yuanhan Liu authored
We may specify the point size in a glsl vertex shader. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46311 piglit: glsl-vs-point-size NOTE: This is a candidate for stable release branches. Signed-off-by:
Yuanhan Liu <yuanhan.liu@linux.intel.com> Reviewed-by:
Brian Paul <brianp@vmware.com> (cherry picked from commit 9962280c)
-
- Mar 14, 2012
-
-
Brian Paul authored
There are several cases in which we need to explicity "rebase" colors (ex: set G=B=0) when getting GL_LUMINANCE textures: 1. If the luminance texture is actually stored as rgba 2. If getting a luminance texture, but returning rgba 3. If getting an rgba texture, but returning luminance Fixes https://bugs.freedesktop.org/show_bug.cgi?id=46679 Also fixes the new piglit getteximage-luminance test. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit f5d0ced2)
-
Brian Paul authored
NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com>
-
Brian Paul authored
See the comments for _mesa_rebase_rgba_float() for details. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=46679 NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit ad897fff)
-
Brian Paul authored
These will be used by glReadPixels() and glGetTexImage() to fix issues with reading GL_LUMINANCE and other formats. NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit 774c4027)
-
The linked list of memory allocations was not protected by a mutex. This lead to sporadic failures with multi-threaded apps. Reviewed-by:
Jose Fonseca <jfonseca@vmware.com>
-
- Mar 09, 2012
-
-
Brian Paul authored
Based on a patch submitted by Vic Lee. The other part of his patch which checked the fs pointer wasn't needed. This fixes a crash when clear() is called before any VS or FS is set. But this can only happen when the driver is used without the Mesa state tracker. NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit 99179882)
-
draw module calls back into the driver and sets certain parts of the state to whatever it needs, unfortunately unless you get the ordering of calls to draw just right you'll end up reseting your own driver state. That's what was happening to us draw module would under certain conditions reset our own driver state. Reviewed-by:
Brian Paul <brianp@vmware.com> (cherry picked from commit 831de96d)
-
We were inverting the meaning of the stencil op flags: in svga/d3d the normal incr/decr wraps and the SAT ops clamp. This fixes piglit failures (at least stencil-twoside and stencil-wrap). We should backport this everywhere we can. Reviewed-by:
Brian Paul <brianp@vmware.com> (cherry picked from commit 5d9bfc4d)
-
In certain situations API's will call pipe->clear which doesn't require fragment shader, but then we'd try to verify the pipeline and assume fragment shader was always set. This was leading to crash when API would just call simple clear's before anything else. NOTE: This is a candidate for the 8.0 branch. Reviewed-by:
José Fonseca <jfonseca@vmware.com> (cherry picked from commit cff0eac7)
-
- Mar 05, 2012
-
-
Mesa has a fast path for the generic fallback when using glReadPixels for RGBA data which uses memcpy. However it was really difficult to hit this case because it would not be used if any transferOps are enabled. Any type apart from floating point or non-normalized integer types (so any of the common types) would force enabling clamping so the fast path could not be used. This patch makes it ignore clamping when determining whether to use the fast path if the data type of the buffer is an unsigned normalized type because in that case clamping will not have any effect anyway. https://bugs.freedesktop.org/show_bug.cgi?id=46631 NOTE: This is a candidate for the 8.0 branch. Signed-off-by:
Brian Paul <brianp@vmware.com> (cherry picked from commit d9c42097)
-
- Mar 01, 2012
-
-
Some backends may advertise more temps than SVGA3D_TEMPREG_MAX, but the driver is hardwired to only support up to the value defined by SVGA3D_TEMPREG_MAX, so clamp to it. Reviewed-by:
Brian Paul <brianp@vmware.com>
-
While the ARB_map_buffer_range extension spec says nothing about these queries -- they were added in GL 3.0 --, it seems like this could be an error in the extension spec. This is one of the extensions, like ARB_framebuffer_object, that "back ports" OpenGL 3.0 functionality to previous versions. These extensions are supposed to provide identical functionality to OpenGL 3.0. The other cases of mismatches have been determined to be bugs in the extension specs. And tools like apitrace rely on such queries to function properly. Signed-off-by:
Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by:
José Fonseca <jfonseca@vmware.com> Acked-by:
Brian Paul <brianp@vmware.com> Acked-by:
Ian Romanick <ian.d.romanick@intel.com>
-
- Feb 28, 2012
-
-
Kenneth Graunke authored
Fixes GPU hangs in OilRush, Trine, and Amnesia: The Dark Descent, which all use MRT (multiple render targets). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38720 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40059 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45216 Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 172bb92d)
-
- Feb 27, 2012
-
-
Tom Stellard authored
KILP instruction inside IF blocks were being lowered to an unconditional KIL. Since r300 doesn't support branching, when the IF's were lowered to conditional moves, the KIL would always be executed. This is not a problem with the mesa state tracker, because the GLSL compiler handles lowering IF's, but this bug was appearing in the VDPAU state tracker, which does not use the GLSL compiler. (cherry picked from commit 342cac71)
-
Marek Olšák authored
This should fix crashes on ancient processors. (cherry picked from commit 74d30352)
-
- Feb 17, 2012
-
-
Ian Romanick authored
Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com>
-
Ian Romanick authored
Signed-off-by:
Ian Romanick <ian.d.romanick@intel.com>
-
- Feb 16, 2012
-
-
r300g is able to sleep until a fence completes rather than busywait because it creates a special buffer object and relocation that stays busy until the CS containing the fence is finished. Copy the idea into r600g, and use it to sleep if the user asked for an infinite wait, falling back to busywaiting if the user provided a timeout. Signed-off-by:
Simon Farnsworth <simon.farnsworth@onelan.co.uk> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8cd03b93) Conflicts: src/gallium/drivers/r600/r600_pipe.c
-
Noticed by taiu on IRC. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 5e1495b2) Conflicts: src/gallium/drivers/r600/evergreen_state.c
-
Noticed by taiu on IRC. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit acca690c) Conflicts: src/gallium/drivers/r600/evergreen_state.c
-
Kenneth Graunke authored
I recently discovered this text in the BSpec. It seems wise to comply, though I haven't observed it to fix anything yet. Fixes a regression in glean/fbo since 28cfa1fa. NOTE: This is a candidate for stable release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45221 Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit 709f5092)
-
Kenneth Graunke authored
Commit dc7f449d introduced a new method for avoiding MOVs: try to rewrite the destination of the instruction that produced the RHS so it writes into the LHS. Unfortunately, this is not safe for swizzled texturing operations, as they return a set of four contiguous registers. Consider the following: (assign (x) (var_ref vec_ctor_x) (swiz x (tex vec4 (var_ref m_sampY) (var_ref m_cordY) 0 1 ()))) In this case, the source and destination registers are equal, since reg_offset is 0 for both. Yet, this is only a partial move: the texture operation generates four registers, and the LHS only covers one. Fixes color distortion in XBMC when using GLSL shaders. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44333 Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 4b274068)
-