- Sep 26, 2015
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- Sep 23, 2015
-
-
This is used everywhere else in this file because it avoids problems when count is zero (due to trimming). No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109 Reviewed-by: Brian Paul <brianp@vmware.com> Cc: Marius Predut <marius.predut@intel.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 25543d8e)
-
This was missing in the HAVE_TRIANGLES path, and that could cause incorrect rendering. No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109 Reviewed-by: Brian Paul <brianp@vmware.com> Cc: Marius Predut <marius.predut@intel.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit c0b3b2f7)
-
No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0d475ee2)
-
No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit fad8d54d)
-
The value passed in count previously was "vertex after the last vertex to be processed." Calling that "count" was misleading and kind of mean. Looking at the code, many functions immediately do "count-start" to get back the true count. That's just silly. If it is better for the loops to be 'for (j = start; j < (start + count); j++)', GCC will do that transformation. NOTE: There is some strange formatting left by this patch. That was done to make it more obvious that the before and after code is equivalent. These will be fixed in the next patch. No piglit regressions on i915 (G33) or radeon (Radeon 7500). v2: Fix a remaining (count-start) in render_quad_strip_verts. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> [v1] Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit d7bf7969)
-
From section 9.2. Binding and Managing Framebuffer Objects: "Upon successful return from Get*FramebufferAttachmentParameteriv, if pname is FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, then params will contain one of NONE, FRAMEBUFFER_DEFAULT, TEXTURE, or RENDERBUFFER, identifying the type of object which contains the attached image." And then it clarifies further: "If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then either no framebuffer is bound to target; or the default framebuffer is bound, attachment is DEPTH or STENCIL, and the number of depth or stencil bits, respectively, is zero" Currently, if the default framebuffer is bound, we always return GL_FRAMEBUFFER_DEFAULT for FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, but according to the spec, when GL_DEPTH or GL_STENCIL attachments are the ones being queried, we should return GL_NONE if they don't exist. Fixes the following dEQP test: dEQP-GLES3.functional.state_query.fbo.framebuffer_attachment_x_size_initial Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit cf439951)
-
Fixes bugs exposed by commit 2b1cdb0e in: ES3-CTS.gtf.GL3Tests.shadow.shadow_execution_frag No regressions observed in deqp, CTS or Piglit. v2: address review feedback from Iago Toral: - move rho calculation to else branch - optimize dx and dy calculation - fix documentation inconsistensies Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Signed-off-by: Kevin Rogovin <kevin.rogovin@intel.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91114 Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 7f8815bc)
-
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.gentoo.org/240956 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 6dfc5e28)
-
res_ptr already contains the resource values. fmask_ptr needs to be looked up relative to the start of the resource params. Note that this only affects indirect loads of MS sampler arrays. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Cc: "11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 7d5162bd)
-
OpenGL ES 3.0 spec 3.7.2 "Transfer of Pixel Rectangles" specifies DEPTH_COMPONENT, UNSIGNED_INT as a valid couple, validation for internal format is checked by is_float_depth(). Fix regression caused by 81d2fd91 in: ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels Test uses GL_DEPTH_COMPONENT, UNSIGNED_INT only when GL_NV_read_depth extension is present. v2: change check in _mesa_error_check_format_and_type to be explicit for ES 2.0+, desktop OpenGL does not allow this behaviour + uses this function for both glReadPixels and glDrawPixels validation. (No Piglit regressions seen with v2.) Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> [v1] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92009 Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit afa1efdc)
-
This fixes the newly-added arb_texture_buffer_object-bufferstorage piglit test. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit e844e100)
-
When updating texture buffers, we might end up replacing the whole buffer. Check that the tic address matches the resource address, and if not, update the tic and reupload it. This fixes: arb_direct_state_access-texture-buffer arb_texture_buffer_object-data-sync Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 323c9125)
-
Various pieces of code to create compressed textures will first generate an uncompressed RGBA texture into a temporary buffer, and then read from that buffer while creating the final compressed texture in the requested format. The code reading from the temporary buffer assumes the buffer is formatted as an array of bytes in RGBA order. However, the buffer is filled using a _mesa_texstore call with MESA_FORMAT_R8G8B8A8_UNORM format -- this is defined as an array of *integers* holding the RGBA values in packed format (least-significant to most-significant). This means incorrect bytes are accessed on big-endian systems. This patch fixes this by using the MESA_FORMAT_A8B8G8R8_UNORM format instead on big-endian systems when filling the buffer. This fixes about 100 piglit test case failures on s390x for me. Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com> Tested-by: Oded Gabbay <oded.gabbay@gmail.com> Cc: "10.6" "11.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@gmail.com> (cherry picked from commit bd016a26)
-
Even though luminance formats don't have alpha, we still want the alpha output to go to the blender. This fixes the luminance blending tests. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 545a3cbb)
-
This is what the hardware supports, there never was any sort of 64K limit. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 7a275fcd)
-
This fixes failures with the newly-submitted max-size texture buffer piglit test for GPUs exposing >= 128M max texels. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Glenn Kennard <glenn.kennard@gmail.com> (cherry picked from commit eb081681)
-
At the moment if a gbm buffer is imported and the gbm buffer has an old-style GBM_BO_FORMAT format, the import will crash, since it's passed directly to DRI functions that expect a fourcc format (as provided by the newer GBM_FORMAT definitions) This commit addresses the problem in two ways: 1) it prevents invalid formats from leading to a crash by returning EINVAL if the image couldn't be created 2) it translates GBM_BO_FORMAT formats into the comparable GBM_FORMAT formats. Reference: https://bugzilla.gnome.org/show_bug.cgi?id=753531 CC: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> (cherry picked from commit 4bf151e6)
-
See similar fix for Readpixels in mesa commit 0d207905. Jason suggested we need that for TexSubImage as well. Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> (cherry picked from commit 64e25167)
-
Loads constants using integer as their register type, like it is done in FS backend. No shader-db changes in HSW. Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91716 Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> (cherry picked from commit b8d2263c)
-
If the register types do not match and the instruction that contains the final destination is saturated, register coalescing generated non-equivalent code. This did not happen when using IR because types usually matched, but it is visible in nir-vec4. For example, mov vgrf7:D vgrf2:D mov.sat m4:F vgrf7:F is coalesced to: mov.sat m4:D vgrf2:D The patch prevents coalescing in such scenario, unless the instruction we want to coalesce into is a MOV (without type conversion implied). In that case, the patch sets the register types to the type of the final destination. Shader-db results in HSW (only vec4 instructions shown): total instructions in shared programs: 1754415 -> 1754416 (0.00%) instructions in affected programs: 74 -> 75 (1.35%) helped: 0 HURT: 1 GAINED: 0 LOST: 0 Only one extra instruction in one of the shaders, that comes from eliminating a saturation error by preventing register coalesce. Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> (cherry picked from commit 79f1a7ae)
-
Cc: "11.0 10.6" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91719 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 1037e0a8)
-
As of a10d4937, we would really like things associated with an instruction to be allocated out of that instruction and not out of the shader. In particular, you should be passing the instruction that will ultimately be holding the source into nir_src_copy rather than an arbitrary memory context. We also change the prototypes of nir_dest_copy and nir_alu_src/dest_copy to explicitly take an instruction so we catch this earlier in the future. Cc: "11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Thomas Helland <thomashelland90@gmail.com> (cherry picked from commit 8c8fc5f8)
-
- Sep 12, 2015
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- Sep 11, 2015
-
-
Cuts compile/link time of the fragment shader in #91857 by 19% (16.28 -> 13.05). I didn't bother with the acp sets because they're smaller, but it might be worth doing as well. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91857 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Thomas Helland <thomashelland90@gmail.com> Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au> Tested-by: Tapani Pälli <tapani.palli@intel.com> (cherry picked from commit 4654439f) Nominated-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Cuts compile/link time of the fragment shader in #91857 by 25% (21.64 -> 16.28). v2: Drop unnecessary _mesa_hash_table_destroy call, and use refs.ht->entries == 0 rather than ad-hoc checking (suggested by Timothy Arceri). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91857 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Thomas Helland <thomashelland90@gmail.com> Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au> Tested-by: Tapani Pälli <tapani.palli@intel.com> (cherry picked from commit e20f30eb) Nominated-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Cuts compile/link time of the fragment shader in bug #91857 by 31% (31.79 -> 21.64). It has over 8,000 variables so linked lists are terrible. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91857 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Thomas Helland <thomashelland90@gmail.com> Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au> Tested-by: Tapani Pälli <tapani.palli@intel.com> (cherry picked from commit 2fc0ce29) Nominated-by: Emil Velikov <emil.l.velikov@gmail.com>
-
We may have been called from glGenerateTextureMipmap with CurrentUnit still set to 0, so we don't know when we can skip binding the texture. Assume that _mesa_BindTexture will be fast if we're rebinding the same texture. v2: Remove currentTexUnitSave because it is now unused. Suggested by both Neil and Anuj. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91847 Cc: "11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Neil Roberts <neil@linux.intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> (cherry picked from commit 767c33e8)
-
pb_buffer::size was aligned by 29aaab2b, which broke the CMASK code I think. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91881 Cc: 11.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit 5c6c5b52)
-
This fixes corruption in Unigine Heaven on VI Cc: 11.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 7956eae1)
-
Required for register spilling. Cc: 11.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c6502e88)
-
When parsing an variable declaration qualified with the typename keyword, clang attempted to declare a variable with the type of non type member "enum type type" of module::argument (within the header file clover/core/module.hpp) instead of the typed member of module::argument "enum type". Replaced "typename" with "enum" to force clang to declare the variable marg_type with type "enum type" of module::argument. CC: "11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Albert Freeman <albertwdfreeman@gmail.com> (cherry picked from commit 1691ead1)
-
Our old value of 16384 is the minimum value. DirectX apparently requires 65536 at a minimum; that's also what nVidia and the Intel Windows driver advertise. AMD advertises MAX_INT. Ilia Mirkin noticed that "Shadow Warrior" uses UBOs larger than 16k on Nouveau, which advertises 65536 bytes for this limit. Traces captured on Nouveau don't work on i965 because our lower limit causes the GLSL linker to reject the captured shaders. While this isn't important in and of itself, it does suggest that raising the limit would be beneficial. We can read linear buffers up to 2^27 bytes in size, so raising this should be safe; we could probably even go larger. For now, matching nVidia and Intel/Windows seems like a good plan. We have to reinitialize MaxCombinedUniformComponents as core Mesa will have set it based on a stale value for MaxUniformBlockSize. According to Tapani, there's an unreleased game that asserts on this. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Tapani Pälli <tapani.palli@intel.com> Cc: "11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit bf58a2c3)
-
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91551 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 74b86b97)
-
This can come up if the target register number is > 63, which is fairly rare. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91551 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit ce28ca71)
-
It is advantageous to use r63 instead of r127 since r63 can fit into the shorter encoding. However if we've RA'd over 63 registers, we must use r127 as the replacement instead. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 641eda0c)
-
Unfortunately nv50_ir phi nodes aren't directly connected to the CFG, so the mapping between source and the actual BB is by inbound edge order. So when manipulating edges one has to be extremely careful. We were insufficiently careful when splitting critical edges which resulted in the phi nodes being confused as to where their sources were coming from. This primarily manifests itself with the TXL-lowering logic on nv50, when it is inside of a conditional. I've been unable to trigger the issue anywhere else so far. This resolves rendering failures in a number of games like Two Worlds 2, Trine: Enchanted Edition, Trine 2, XCOM:Enemy Unknown, Stacking. It also improves the situation in Hearthstone, Sonic Generations, and The Raven: Legacy of a Master Thief. However more work needs to be done there (splitting a lot more edges solves it, so it's some other sort of RA-related issue). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90887 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "11.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit a072ef87)
-