- Sep 28, 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>
-
When validating format+type+internalFormat for texture pixel operations on GLES3, the effective internal format should be used if the one specified is an unsized internal format. Page 127, section "3.8 Texturing" of the GLES 3.0.4 spec says: "if internalformat is a base internal format, the effective internal format is a sized internal format that is derived from the format and type for internal use by the GL. Table 3.12 specifies the mapping of format and type to effective internal formats. The effective internal format is used by the GL for purposes such as texture completeness or type checks for CopyTex* commands. In these cases, the GL is required to operate as if the effective internal format was used as the internalformat when specifying the texture data." v2: Per the spec, Luminance8Alpha8, Luminance8 and Alpha8 should not be considered sized internal formats. Return the corresponding unsize format instead. v4: * Improved comments in _mesa_es3_effective_internal_format_for_format_and_type(). * Splitted patch to separate chunk about reordering of error_check_subtexture_dimensions() error check, which is not directly related with this patch. v5: Dropped the splitted patch because it was actually a work around 3 dEQP tests that are buggy: dEQP-GLES2.functional.negative_api.texture.texsubimage2d_neg_offset dEQP-GLES2.functional.negative_api.texture.texsubimage2d_offset_allowed dEQP-GLES2.functional.negative_api.texture.texsubimage2d_neg_wdt_hgt Cc: "11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Jason Ekstrand <jason.ekstrand@intel.com> Tested-by:
Mark Janes <mark.a.janes@intel.com> (cherry picked from commit 5edd9961) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91582
-
This function will be needed as part of validating the combination of format, type and internal format of texture pixel operations, which happens in glformats files. Specifically, we want to be able to obtain the base format of a resolved effective internal format, to compare it with the original internal format passed. Also, since this function deals solely with GL formats, it fits better in glformats where the rest of similar format functionality rests. The function is moved as-is, without any modification. Cc: "11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Jason Ekstrand <jason.ekstrand@intel.com> Tested-by:
Mark Janes <mark.a.janes@intel.com> (cherry picked from commit c6bf1cd1) Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Conflicts: src/mesa/main/teximage.c src/mesa/main/teximage.h
-
The more specific GLES constrains should be checked after the general validation performed by _mesa_error_check_format_and_type(). This is also for consistency with the error checks order of glTexSubImage ops. v3: The change of order uncovered a bug that regresses a couple of piglit tests written against OpenGL-ES 1.1 spec, which expects an INVALID_VALUE instead of the INVALID_ENUM returned by _mesa_error_check_format_and_type() when an invalid format is passed to glTexImage2D. This version of the patch accounts for those cases. Fixes 1 dEQP test: * dEQP-GLES3.functional.negative_api.texture.teximage2d Cc: "11.0" <mesa-stable@lists.freedesktop.org> Reviewed-by:
Jason Ekstrand <jason.ekstrand@intel.com> Tested-by:
Mark Janes <mark.a.janes@intel.com> (cherry picked from commit 15ab968f)
-
... with only ARB_shader_atomic_counters. I expected to see interactions with ARB_tessellation_shader in the ARB_shader_atomic_counters spec, but they do not exist. It seems that we should unconditionally expose these variables in the presence of ARB_shader_atomic_counters: gl_MaxTessControlAtomicCounters gl_MaxTessEvaluationAtomicCounters This partially reverts commit da7adb99. The commit also affected gl_MaxTessControlImageUniforms and gl_MaxTessEvaluationImageUniforms similarly but the ARB_shader_image_load_store spec does list an interaction with ARB_tessellation_shader. Cc: "11.0" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92095 Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit d6bb46bb)
-
When we assign hw regs to attributes, we don't incorporate the stride and subreg_offset from the fs_reg. It's rarely used, but the integer multiplication lowering uses unusual stride and subreg_offset combination breaks when one source is an attribute. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91970 Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> Signed-off-by:
Kristian Høgsberg Kristensen <krh@bitplanet.net> Reviewed-by:
Matt Turner <mattst88@gmail.com> (cherry picked from commit 2ea16966)
-
- 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>
-
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)
-