summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* i965: Fix MRF register number assertions for compr4.Kenneth Graunke2015-09-211-2/+2
| | | | | | | | | | compr4 is represented by setting the high bit on the MRF number. We need to mask it out before sanity checking the register number. Fixes ~8000 assert fails on Ironlake and G45. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92066 Signed-off-by: Kenneth Graunke <[email protected]>
* i965/vec4: Use MRF registers 21-23 for spilling in gen6Iago Toral Quiroga2015-09-211-4/+6
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Use MRF registers 21-23 for spilling in gen6Iago Toral Quiroga2015-09-211-4/+7
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Turn BRW_MAX_MRF into a macro that accepts a hardware generationIago Toral Quiroga2015-09-218-28/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are some bug reports about shaders failing to compile in gen6 because MRF 14 is used when we need to spill. For example: https://bugs.freedesktop.org/show_bug.cgi?id=86469 https://bugs.freedesktop.org/show_bug.cgi?id=90631 Discussion in bugzilla pointed to the fact that gen6 might actually have 24 MRF registers available instead of 16, so we could use other MRF registers and avoid these conflicts (we still need to investigate why some shaders need up to MRF 14 anyway, since this is not expected). Notice that the hardware docs are not clear about this fact: SNB PRM Vol4 Part2's "Table 5-4. MRF Registers Available in Device Hardware" says "Number per Thread" - "24 registers" However, SNB PRM Vol4 Part1, 1.6.1 Message Register File (MRF) says: "Normal threads should construct their messages in m1..m15. (...) Regardless of actual hardware implementation, the thread should not assume th at MRF addresses above m15 wrap to legal MRF registers." Therefore experimentation was necessary to evaluate if we had these extra MRF registers available or not. This was tested in gen6 using MRF registers 21..23 for spilling and doing a full piglit run (all.py) forcing spilling of everything on the FS backend. It was also tested by doing spilling of everything on both the FS and the VS backends with a piglit run of shader.py. In both cases no regressions were observed. In fact, many of these tests where helped in the cases where we forced spilling, since that triggered the same underlying problem described in the bug reports. Here are some results using INTEL_DEBUG=spill_fs,spill_vec4 for a shader.py run on gen6 hardware: Using MRFs 13..15 for spilling: crash: 2, fail: 113, pass: 6621, skip: 5461 Using MRFs 21..23 for spilling: crash: 2, fail: 12, pass: 6722, skip: 5461 This patch sets the ground for later patches to implement spilling using MRF registers 21..23 in gen6. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Move MRF register asserts out of brw_reg.hIago Toral Quiroga2015-09-214-7/+16
| | | | | | | | | | | | | | | In a later patch we will make BRW_MAX_MRF return a different value depending on the hardware generation, but it is inconvenient to add a gen parameter to the brw_reg functions only for the assertions, so move these to places where we have the hardware generation available. Ken suggested to add the asserts to brw_set_src0 and brw_set_dest since that would make sure that we catch all uses of MRF registers, even those coming from modules that generate native code directly, like blorp. Unfortunately, this is very late in the process which can make things harder to debug, so add asserts to the generator as well. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Maximum allowed size of SEND messages is 15 (4 bits)Iago Toral Quiroga2015-09-214-2/+10
| | | | | | | | | | | | | | | | | | | Until now we only used MRFs 1..15 for regular SEND messages, so the message length could not possibly exceed the maximum size. Soon we'll allow to use MRF registers 1..23 in gen6, so we need to be careful not to build messages that can go beyond the limit. That could occur, specifically, when building URB write messages, which we may need to split in chunks due to their size. Previously we would simply go and create a new message when we reached MRF 13 (since 13..15 were reserved for spilling), now we also want to check the size of the message explicitly. Besides adding that condition to split URB write messages properly, this patch also adds asserts in the generator. Notice that brw_inst_set_mlen already asserts for this, but asserting in the generators is easy and can make debugging easier in some cases. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4/nir: Remove all "this->" snippetsEduardo Lima Mitev2015-09-201-16/+15
| | | | | | | | For consistency, either we have all class members dereferenced, or none. In this case, very few are so lets get rid of them all. Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri/common: fix gbm-symbols-check regressionMarcin Ślusarz2015-09-201-1/+1
| | | | | | | | Broken by commit c228514c72cb2fd5fb9e510808e29204fc9e7ae1 "dri/common: use sysconfdir when looking for drirc". Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92054 Signed-off-by: Marcin Ślusarz <[email protected]>
* mesa/teximage: reuse compressed format utility functions for base_formatNanley Chery2015-09-191-145/+5
| | | | | | | | | | | | | | | Reuse utility functions instead of reimplementing the same logic. * _mesa_is_compressed_format() performs the required checking to determine format support in the current context. * _mesa_gl_compressed_format_base_format() returns the base format. As a side effect, we now check that we're in a desktop context when determining support for the FXT1 and RGTC formats. This is in agreement with our extension table and the glext headers. Reviewed-by: Anuj Phogat <[email protected]> Signed-off-by: Nanley Chery <[email protected]>
* mesa/texcompress: add compressed formats to base format utility functionNanley Chery2015-09-191-0/+14
| | | | | | | Add S3TC and PALETTE formats. Reviewed-by: Anuj Phogat <[email protected]> Signed-off-by: Nanley Chery <[email protected]>
* mesa/glformats: refactor compressed format support functionNanley Chery2015-09-191-79/+40
| | | | | | | | | | | Instead of case statements, use _mesa_get_format_layout() to determine if a GL format is part of a family of compressed formats. v2. restrict LATC formats to API_OPENGL_COMPAT (Ilia). rename the variable mFormat to m_format. Reviewed-by: Anuj Phogat <[email protected]> Signed-off-by: Nanley Chery <[email protected]>
* mesa/formats: add MESA_LAYOUT_LATCNanley Chery2015-09-195-16/+7
| | | | | | | | | This enables us to predicate statments on a compressed format being a type of LATC format. Also, remove the comment that lists the enum (it was getting a tad long). Reviewed-by: Anuj Phogat <[email protected]> Signed-off-by: Nanley Chery <[email protected]>
* dri/common: use sysconfdir when looking for drircMarcin Ślusarz2015-09-192-1/+6
| | | | | | | | Useful when locally installed mesa has more quirks than the system one. Signed-off-by: Marcin Ślusarz <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* nir/lower_tex: support projector lowering per sampler typeRob Clark2015-09-181-1/+4
| | | | | | | | | | | | Some hardware, such as adreno a3xx, supports txp on some but not all sampler types. In this case we want more fine grained control over which texture projectors get lowered. v2: split out nir_lower_tex_options struct to make it easier to add the additional parameters coming in the following patches Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* nir: rename nir_lower_tex_projectorRob Clark2015-09-181-1/+1
| | | | | | | | | | Since the following patches will add additional tex-lowering related functionality, which doesn't make sense to split out into a separate pass (as they would require duplication of the projector lowering logic), let's give this pass a more generic name. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Change types as needed to propagate source modifiers using ↵Alejandro Piñeiro2015-09-191-2/+28
| | | | | | | | | | | | | | | | | | | | | | current instruction SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to generate. This commit adds support for copy propagation using current instruction as reference. Equivalent to commit 472ef9 but for vec4. v2: include check for saturate, as Jason Ekstrand suggested v3: check that the dst.type and the src type are the same, in order to solve (among others) the following deqp regression with v2: dEQP-GLES3.functional.shaders.operator.unary_operator.minus.lowp_uint_vertex Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Fix comparison between signed and unsigned integer expressionsIago Toral Quiroga2015-09-181-2/+2
| | | | | | | brw_fs_visitor.cpp: In member function 'void fs_visitor::emit_urb_writes()': brw_fs_visitor.cpp:977:58: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Reviewed-by: Tapani Pälli <[email protected]>
* mesa: fix errors when reading depth with glReadPixelsTapani Pälli2015-09-182-1/+7
| | | | | | | | | | | | | | | | | | | | | | | 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 81d2fd91a90e5b2fd9fd74792a7a7c329f0e4d29 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 <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]> [v1] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92009 Cc: "10.6 11.0" <[email protected]>
* i965/vec4: Use nir_move_vec_src_uses_to_destJason Ekstrand2015-09-171-0/+3
| | | | | | | | | | | | | | | | | | | The idea here is not that it gives register coalescing a little bit of a helping hand. It doesn't actually fix the coalescing problems, but it seems to help a good bit. Shader-db results for vec4 programs on Haswell: total instructions in shared programs: 1746280 -> 1683959 (-3.57%) instructions in affected programs: 1259166 -> 1196845 (-4.95%) helped: 11363 HURT: 148 v2 (Jason Ekstrand): - Run nir_move_vec_src_uses_to_dest after going out of SSA - New shader-db numbers Reviewed-by: Eduardo Lima Mitev <[email protected]>
* mesa: Fix texture compression on big-endian systemsUlrich Weigand2015-09-174-7/+14
| | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Tested-by: Oded Gabbay <[email protected]> Cc: "10.6" "11.0" <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: return initial value for VALIDATE_STATUS if pipe not boundTapani Pälli2015-09-171-1/+2
| | | | | | | | | | | | | | | | | | From OpenGL 4.5 Core spec (7.13): "If pipeline is a name that has been generated (without subsequent deletion) by GenProgramPipelines, but refers to a program pipeline object that has not been previously bound, the GL first creates a new state vector in the same manner as when BindProgramPipeline creates a new program pipeline object." I interpret this as "If GetProgramPipelineiv gets called without a bound (but valid) pipeline object, the state should reflect initial state of a new pipeline object." This is also expected behaviour by ES31-CTS.sepshaderobjs.PipelineApi conformance test. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Marta Lofstedt <[email protected]>
* mesa: return initial value for PROGRAM_SEPARABLE when not linkedTapani Pälli2015-09-171-1/+2
| | | | | | | | | | | | | | | | | From OpenGL ES 3.1 spec (7.12): "Most properties set within program objects are specified not to take effect until the next call to LinkProgram or ProgramBinary. Some properties further require a successful call to either of these commands before taking effect. GetProgramiv returns the properties currently in effect for program, which may differ from the properties set within program since the most recent call to LinkProgram or ProgramBinary, which have not yet taken effect. If there has been no such call putting changes to pname into effect, initial values are returned." Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Marta Lofstedt <[email protected]>
* mesa: enable query of PROGRAM_PIPELINE_BINDING for ES 3.1Tapani Pälli2015-09-171-3/+3
| | | | | | | Specified in OpenGL ES 3.1 spec, Table 23.32: Program Object State. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Marta Lofstedt <[email protected]>
* Revert "mesa/extensions: restrict GL_OES_EGL_image to GLES"Dave Airlie2015-09-171-1/+2
| | | | | | | | | | | | | This reverts commit 48961fa3ba37999a6f8fd812458b735e39604a95. glamor/Xwayland use this, the spec saying something when it was written, and the fact that the comment says Mesa relies on it hasn't changed. I also don't have a copy of this patch in my mail archive, which seems wierd, did it get posted to mesa-dev? Signed-off-by: Dave Airlie <[email protected]>
* st/mesa: avoid integer overflows with buffers >= 512MBIlia Mirkin2015-09-161-2/+2
| | | | | | | | | This fixes failures with the newly-submitted max-size texture buffer piglit test for GPUs exposing >= 128M max texels. Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.6 11.0" <[email protected]> Reviewed-by: Glenn Kennard <[email protected]>
* mesa: move GL_APPLE_object_purgeable functions to new fileBrian Paul2015-09-165-388/+460
| | | | | | | Move this code out of bufferobj.c since it's not strongly connected to buffer objects. Acked-by: Matt Turner <[email protected]>
* mesa: remove trailing whitespace in bufferobj.cBrian Paul2015-09-161-7/+7
| | | | Trivial.
* mesa: whitespace, line wrap fixes in varray.cBrian Paul2015-09-161-12/+20
| | | | Trivial.
* glsl: shader-enum to name debug fxnsRob Clark2015-09-161-1/+3
| | | | | Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965/fs: The barrier send uses only 1 payload registerJordan Justen2015-09-152-2/+5
| | | | | | | | | | | | | | | | | | | When preparing the barrier payload, the instructions should operate in simd8 mode since we only use 1 payload register. fs_inst::regs_read is also updated to indicate that it only reads one register for SHADER_OPCODE_BARRIER. These issues were flagged by: commit cadd7dd384b33a779d46bd664f456bed4a21a5b7 Author: Jason Ekstrand <[email protected]> Date: Thu Jul 2 15:41:02 2015 -0700 i965/fs: Add a very basic validation pass Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/vec4: Use the replicated fdot instruction in NIRJason Ekstrand2015-09-152-3/+11
| | | | | Reviewed-by: Connor Abbott <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]>
* i965/vec4_nir: Use partial SSA form rather than full non-SSAJason Ekstrand2015-09-153-4/+20
| | | | | | | | | We made this switch in the FS backend some time ago and it seems to make a number of things a bit easier. In particular, supporting SSA values takes very little work in the backend and allows us to take advantage of the majority of the SSA information even after we've gotten rid of Phi nodes. Reviewed-by: Eduardo Lima Mitev <[email protected]>
* i965/fs: Add a very basic validation passJason Ekstrand2015-09-154-0/+69
| | | | | | | | Currently the validation pass only validates that regs_read and regs_written are consistent with the sizes of VGRF's. We can add more as we find it to be useful. Reviewed-by: Matt Turner <[email protected]>
* i965/fs_surface_builder: Only apply predicate to components that existJason Ekstrand2015-09-151-1/+1
| | | | | | | | | | | | In certain conditions, we have to do bounds-checking in the shader for image_load_store. The way this works for image loads is that we do a predicated load and then emit a series of selects, one per component, that gives us 0 or the loaded value depending on whether or not you're in bounds. However, we were hard-coding 4 components which may not be correct. Instead, we should be using size which is the number of components read. Reviewed-by: Francisco Jerez <[email protected]>
* i965/fs: Only read output_components many components when writing an outputJason Ekstrand2015-09-151-1/+3
| | | | Reviewed-by: Kristian Høgsberg <[email protected]>
* i965/fs: Set output_components for lowered clip distance outputsJason Ekstrand2015-09-151-0/+2
| | | | Reviewed-by: Kristian Høgsberg <[email protected]>
* mesa/teximage: restrict GL_ETC1_RGB8_OES support to GLESNanley Chery2015-09-151-1/+2
| | | | | | | | | | | According to the extensions table and our glext headers, OES_compressed_ETC1_RGB8_texture is only supported in GLES1 and GLES2. Since we may give users a GLES3 context when a GLES2 context is requested, we also allow this extension for GLES3 as well. Reviewed-by: Anuj Phogat <[email protected]> Signed-off-by: Nanley Chery <[email protected]>
* mesa/extensions: restrict GL_OES_EGL_image to GLESNanley Chery2015-09-151-2/+1
| | | | | | | | Driver vendors do this as well. The extension specification lists GLES 1.1 or 2.0 as requirements. Reviewed-by: Chad Versace <[email protected]> Signed-off-by: Nanley Chery <[email protected]>
* mesa/extensions: restrict luminance alpha formats to API_OPENGL_COMPATNanley Chery2015-09-152-4/+6
| | | | | | | According the GL 3.1 spec, luminance alpha formats are deprecated. Reviewed-by: Anuj Phogat <[email protected]> Signed-off-by: Nanley Chery <[email protected]>
* i965: Move perf_debug code to brw_codegen_*_prog()Kristian Høgsberg Kristensen2015-09-145-76/+75
| | | | | | | | | | We're trying to avoid a libdrm dependency in the core compiler, so let's move the perf_debug code one level up from the brw_*_emit() helpers to the brw_codegen_*_prog() helpers. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Signed-off-by: Kristian Høgsberg Kristensen <[email protected]>
* i965: Move brw_fs_precompile() to brw_wm.cKristian Høgsberg Kristensen2015-09-142-58/+59
| | | | | | | | | All other precompile functions live in the brw_<stage>.c files, make fs follow the convention. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Signed-off-by: Kristian Høgsberg Kristensen <[email protected]>
* i965: Move compute shader code aroundKristian Høgsberg Kristensen2015-09-145-333/+362
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This moves the compute shader code around in order to make the way the code is split up more consistent. There should be no functional changes. Typically we have a few files per stage: brw_vs.c, brw_wm.c brw_gs.c: code to drive code generation and implement precompiling and cache search. genX_<stage>_state.c gen specific implementation of the state emission for the shader stage. The brw_*_emit() functions are all in the same files as the visitor classes they use (with the exception of VS, which may use either vec4 or fs). To make compute follow this convention, we move the brw_cs_emit() function into brw_fs.cpp. We can then rename brw_cs.cpp to brw_cs.c and do this in C like the other similar files. Finally, move state setup and atoms to gen7_cs_state.c. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Signed-off-by: Kristian Høgsberg Kristensen <[email protected]>
* meta: Abort meta pbo path if TexSubImage need signed unsigned conversionAnuj Phogat2015-09-141-18/+25
| | | | | | | | | See similar fix for Readpixels in mesa commit 0d20790. Jason suggested we need that for TexSubImage as well. Cc: <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/vec4_nir: Load constants as integersAntia Puentes2015-09-141-2/+2
| | | | | | | | | | | 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" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91716 Reviewed-by: Jason Ekstrand <[email protected]>
* i965/vec4: Fix saturation errors when coalescing registersAntia Puentes2015-09-141-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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" <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* st/mesa: emit TXQS, support ARB_shader_texture_image_samplesIlia Mirkin2015-09-132-1/+6
| | | | | | | | | The image component of the ext is a no-op since there is no image support in gallium (yet). Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965/nir: Support gl_WorkGroupID variableJordan Justen2015-09-131-1/+9
| | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* i965/cs: Initialize gl_WorkGroupID variable from payloadJordan Justen2015-09-132-0/+20
| | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* i965/nir: Support gl_LocalInvocationID variableJordan Justen2015-09-131-0/+17
| | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* i965/cs: Initialize gl_LocalInvocationID from payloadJordan Justen2015-09-132-2/+24
| | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 15:05:43 +0000