summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ilo: rename ILO_DEBUG=3dChia-I Wu2014-09-195-6/+6
| | | | | | It has been a bad name since we added the builder. Rename it to ILO_DEBUG=batch to match i965, and call ilo_builder_decode() from ilo_cp_submit_internal().
* ilo: rename ilo_cp_flush()Chia-I Wu2014-09-1911-52/+52
| | | | | | "Flush" is used for too many things already: pipe resource flush, pipe context flush, pipe transfer region flush, and hardware pipeline flush. Rename it to ilo_cp_submit(). As such, ILO_DEBUG=flush is renamed to ILO_DEBUG=submit.
* ilo: remove ilo_cp_empty()Chia-I Wu2014-09-193-22/+12
| | | | Call ilo_builder_batch_used() directly.
* ilo: simplify ilo_cp_set_owner()Chia-I Wu2014-09-195-129/+121
| | | | | | The simplification allows us to get rid of ilo_cp_set_ring() and ilo_cp_implicit_flush(). The 3D query code is refactored for the simplification.
* mesa: Delete VAO _MaxElement code and index buffer bounds checking.Kenneth Graunke2014-09-1915-206/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fredrik's implementation of ARB_vertex_attrib_binding introduced new gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and converted Mesa's older gl_client_array to be derived state. Ultimately, we'd like to drop gl_client_array and use those structures directly. One hitch is that gl_client_array::_MaxElement doesn't correspond to either structure (unlike every other field), so we'd have to figure out where to store it. The _MaxElement computation uses values from both structures, so it doesn't really belong in either place. We could put it in the VAO, but we'd have to pass it around everywhere. It turns out that it's only used when ctx->Const.CheckArrayBounds is set, which is only set by the (rarely used) classic swrast driver. It appears that drivers/x11 used to set it as well, which was intended to avoid segmentation faults on out-of-bounds memory access in the X server (probably for indirect GLX clients). However, ajax deleted that code in 2010 (commit 1ccef926be46dce3b6b5c76e812e2fae4e205ce7). The bounds checking apparently doesn't actually work, either. Non-VBO attributes arbitrarily set _MaxElement to 2 * 1000 * 1000 * 1000. vbo_save_draw and vbo_exec_draw remark /* ??? */ when setting it, and the i965 code contains a comment noting that _MaxElement is often bogus. Given that the code is complex, rarely used, and dubiously functional, it doesn't seem worth maintaining going forward. This patch drops it. This will probably mean the classic swrast driver may begin crashing on out of bounds vertex buffer access in some cases, but I believe that is allowed by OpenGL (and probably happened for non-VBO accesses anyway). There do not appear to be any Piglit regressions, either. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Roland Scheidegger <[email protected]>
* vc4: Add support for stencil operations.Eric Anholt2014-09-188-2/+118
| | | | | | | While depth test state is passed through the fragment shader as sideband, data, the stencil test state has to be set by the fragment shader itself. Many tests are still failing, but this gets most of hiz/ passing.
* vc4: Actually implement VC4_DEBUG=cl.Eric Anholt2014-09-184-0/+141
|
* draw: (trivial) remove duplicated linesRoland Scheidegger2014-09-181-12/+0
|
* mesa: fix prog_optimize.c assertions triggered by SWZ opcodeBrian Paul2014-09-181-5/+4
| | | | | | | | | | | | | The SWZ instruction can have swizzle terms >4 (SWIZZLE_ZERO, SWIZZLE_ONE). These swizzle terms caused a few assertions to fail. This started happening after the commit "mesa: Actually use the Mesa IR optimizer for ARB programs." when replaying some apitrace files. A new piglit test (tests/asmparsertest/shaders/ARBfp1.0/swz-08.txt) exercises this. Cc: "10.3" <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* vc4: Allow copy propagation of uniforms.Eric Anholt2014-09-171-1/+15
| | | | | Fixes 12 piglit tests (and 8 more crash -> fail) from reducing register pressure.
* vc4: Make sure thread end doesn't have a uniform read.Eric Anholt2014-09-171-0/+8
| | | | Prevents regression when I start doing copy propagation on uniforms.
* vc4: Allow dead code elimination of instructions that read uniforms.Eric Anholt2014-09-171-2/+1
|
* vc4: Add support for reordering the uniform stream after optimization.Eric Anholt2014-09-174-0/+87
| | | | | | This allows for introducing dead code eliminating of uniforms, copy propagation of uniforms, and instruction rescheduling between instructions that both read uniforms.
* vc4: Initialize the various qreg arrays when allocating them.Eric Anholt2014-09-171-0/+4
| | | | | | | This is particularly important for outputs, where we try to MOV the whole vec4 to the VPM, even if only 1-3 components had been set up. It might also be important for temporaries, if the shader reads components before writing them.
* vc4: Fix stray disable of the CSE pass.Eric Anholt2014-09-171-1/+0
| | | | Somehow I slipped this in with the original commit of CSE.
* gallivm,tgsi: fix idiv by zero crashrconde2014-09-172-7/+25
| | | | | | | | While the result of signed integer division by zero is undefined by glsl (and doesn't exist with d3d10), we must not crash, so need to make sure we don't get sigfpe much like udiv already does. Unlike udiv where we return 0xffffffff (as required by d3d10) there is no requirement right now to return anything specific so we use zero.
* gallivm: add texture target information for sample opcodes to tgsi infoRoland Scheidegger2014-09-171-14/+43
| | | | | | | | | | | | | | sample opcodes don't have valid texture target information (and I don't think this should be changed), however it would be nice if we had that information ready elsewhere, so stuff that information into the tgsi info when analyzing a shader. v2: Ilja Mirkin spotted some bugs wrt not handling msaa resources. So add them and while there also add them to the tex opcode analysis this was cloned from as well (plus get rid of some bug not detecting indirect textures there in some cases too). Reviewed-by: Jose Fonseca <[email protected]>
* st/mesa: Fix handling of 8888 SNORM and SRGB formats for big-endianRichard Sandiford2014-09-171-16/+36
| | | | | | | | | | | MESA_FORMAT_x8y8z8w8 puts the x channel in the least significant part of the containing 32-bit integer, which is equivalent to PIPE_FORMAT_xyzw8888. PIPE_FORMAT_x8y8z8w8 puts the x channel first in memory. This patch fixes up the mesa<->gallium mapping accordingly. Signed-off-by: Richard Sandiford <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* st/mesa: Fix handling of LA and RG formats for big-endianRichard Sandiford2014-09-171-16/+48
| | | | | | | | | | | | MESA_FORMAT_LnAn puts the luminance in the least significant part of the containing integer, which is equivalent to PIPE_FORMAT_LAnn. PIPE_FORMAT_LnAn puts the luminance first in memory. This patch fixes up the mesa<->gallium mapping accordingly. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: Add MESA_FORMAT_{A8R8G8B8, X8R8G8B8, X8B8G8R8}_SRGB (v2)Richard Sandiford2014-09-179-0/+164
| | | | | | | | | | | | This means that each 8888 SRGB format has a reversed counterpart, which is necessary for handling big-endian mesa<->gallium mappings. v2: fix missing i965 additions. (Jason) fix 127->255 max alpha for SRGB formats. (Jason) v1: Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Richard Sandiford <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: Add MESA_FORMAT_A8L8_{SNORM,SRGB}Richard Sandiford2014-09-179-0/+111
| | | | | | | | | | | | | The associated UNORM format already existed. This means that each LnAn format has a reversed counterpart, which is necessary for handling big-endian mesa<->gallium mappings. [airlied: rebased onto current master] Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallium: Define PIPE_FORMAT_xyzw8888_{SNORM, SRGB} aliasesRichard Sandiford2014-09-171-0/+24
| | | | | | | | | ...i.e. formats in which the first listed component is in the least significant byte of the integer. The corresponding UNORM aliases already exist. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallium: Add PIPE_FORMAT_x8B8G8R8_SNORM formatsRichard Sandiford2014-09-172-0/+6
| | | | | | | | | | | This means that each RnGnBnxn format has a reversed counterpart, which is necessary for handling big-endian mesa<->gallium mappings. The associated UNORM and SRGB formats already exist. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallium: Define PIPE_FORMAT_{LA, AL, RG, GR}nn aliasesRichard Sandiford2014-09-171-0/+32
| | | | | | | | | | ...i.e. formats in which the first listed component is in the least significant half of the integer. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallium: Add PIPE_FORMAT_AnLn and PIPE_FORMAT_GnRn formatsRichard Sandiford2014-09-172-0/+19
| | | | | | | | | | | | ...i.e. formats in which the alpha or green channel is first in memory. This means that each LnAn and RnGn format has a reversed counterpart, which is necessary for handling big-endian mesa<->gallium mappings. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: fix SRGB alpha channel value in pack_float_R8G8B8X8_SRGBDave Airlie2014-09-171-1/+1
| | | | | | | | | Jason pointed out the bug on review adding new formats, but the existing format also appears to have the bug, so use 255 as the max, these are SRGB no SNORM. Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* swrast: Fix handling of MESA_FORMAT_L8A8_SRGB for big-endianRichard Sandiford2014-09-171-3/+3
| | | | | | | | | | | | Luminance is the least-significant byte of the uint16, rather than the lowest byte in memory. Other parts of mesa already handle this correctly for big-endian, and swrast already handles other MESA_FORMAT_x8y8 formats correctly. This case was just an odd-one-out. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Cc: <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: Tweak unpack name for MESA_FORMAT_R8G8B8X8_SNORMRichard Sandiford2014-09-171-2/+2
| | | | | | | | | | | MESA_FORMAT_R8G8B8X8_SNORM used a function called unpack_X8B8G8R8_SNORM while MESA_FORMAT_R8G8B8X8_SRGB used a function called unpack_R8G8B8X8_SRGB. This patch renames the SNORM function to have the same order as the MESA_FORMAT name, like the SRGB function does. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: Fix alpha component in unpack_R8G8B8X8_SRGB.Richard Sandiford2014-09-171-1/+1
| | | | | | | | | | | The function was using the "X" component as the alpha channel, rather than setting alpha to 1.0. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Cc: <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* util: move shared rgtc code to util (v2)Dave Airlie2014-09-177-186/+174
| | | | | | | | | | | This was being shared using a ../../ get out of gallium into mesa, and I swore when I did it I'd fix things when we got a util dir, we did, so I have. v2: move RGTC_DEBUG define Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* vc4: Claim ARB_fbo.Eric Anholt2014-09-161-1/+3
| | | | | | | | This gets a ton of piglit working that crashes in waffle context management stuff otherwise. Actually supporting mismatched FB sizes is at best going to require some more load/store generals for color buffers, but if I can't manage to do that I'll want to just have state_tracker reject those FBOs as unsupported, rather than deny GL 2.1.
* vc4: Fix memory leaks in register allocation.Eric Anholt2014-09-161-0/+3
|
* vc4: Move register allocation to a separate file.Eric Anholt2014-09-164-100/+165
| | | | | I'm going to be rewriting it all, and having it mixed up with the QIR-to-QPU opcode translation was messy.
* glsl: fix error message for redeclaring gl_PerVertex as outputChris Forbes2014-09-171-1/+1
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: slightly improve insn dumping with no srcsChris Forbes2014-09-171-1/+4
| | | | | | | Previously, we would get a trailing ', ' which looked strange. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* vc4: Add support for computed depth writes.Eric Anholt2014-09-163-2/+26
| | | | Fixes piglit glsl-1.10-fragdepth and early-z.
* vc4: Restructure depth input/output in fragment shaders.Eric Anholt2014-09-164-12/+17
| | | | | | The goal here is to have an argument for the depth write opcode so that I can do computed depth. In the process, this makes the calculations that will be emitted more obvious in the QIR.
* freedreno: add a standalone ir3_compiler binary for building TGSIIlia Mirkin2014-09-162-0/+191
| | | | | | Compiler taken from the combo old/new compiler comparer + simulator. Signed-off-by: Ilia Mirkin <[email protected]>
* freedreno: add default .dir-locals.el for emacs settingsIlia Mirkin2014-09-161-0/+8
| | | | Signed-off-by: Ilia Mirkin <[email protected]>
* i965: add support for RGBA dma_buf imports.Gwenole Beauchesne2014-09-161-0/+6
| | | | | | | | | This allows for importing foreign buffers in RGB32 native endian byte order, i.e. DRM_FORMAT_XBGR8888, and DRM_FORMAT_ABGR8888. Signed-off-by: Gwenole Beauchesne <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Cc: "10.3" <[email protected]>
* i965: Mark delta_x/y as BAD_FILE if remapped away completely.Kenneth Graunke2014-09-162-5/+15
| | | | | | | | | | | | | | | | | | | | | | | Commit afe3d1556f6b77031f7025309511a0eea2a3e8df (i965: Stop doing remapping of "special" regs.) stopped remapping delta_x/delta_y, and additionally stopped considering them always-live. We later realized delta_x was used in register allocaiton, so we actually needed to remap it, which was fixed in commit 23d782067ae834ad53522b46638ea21c62e94ca3 (i965/fs: Keep track of the register that hold delta_x/delta_y.). However, that commit didn't restore the "always consider it live" part. If all the code using delta_x was eliminated, fs_visitor::delta_x would be left pointing at its old register number. Later code in register allocation would handle that register number specially...even though it wasn't actually delta_x. To combat this, set delta_x/y to BAD_FILE if they're eliminated, and check for that. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83127 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Cc: "10.3" <[email protected]>
* st_glsl_to_tgsi: init have_sqrt field.Dave Airlie2014-09-161-0/+1
| | | | | | Coverity reported this. Signed-off-by: Dave Airlie <[email protected]>
* llvmpipe: fix rast debugging outputDave Airlie2014-09-161-0/+11
| | | | | | | | The triangle_32_ rast functions never made it into the debug output, confused me for a few seconds. Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* util: Add big-endian layout for a number of formats.Richard Sandiford2014-09-162-35/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch builds on 6c8f547f66e68b495c708f8ffcb67370caa5ffe8 and previous patches by allowing u_format.csv to specify separate big-endian and little-endian layouts. It then uses this to specify the correct layouts for various depth/stencil formats. Later patches handle other formats. To recap, the idea is that u_format.csv lists the channels for an N-byte value as though it were an N-byte integer. For little-endian targets the channels are listed starting at the least-significant bit of the integer while for big-endian targets the channels are listed starting at the most-significant bit. This means that for something like PIPE_FORMAT_B8G8R8A8_UNORM (blue in first byte of memory, alpha in last byte of memory) the orders are the same for both endiannesses. But for something like PIPE_FORMAT_S8_UINT_Z24_UNORM, where the stencil is in the least significant byte of a 32-bit integer, there need to be separate channel definitions for each endianness. The effect of this patch is to make the affected PIPE_FORMAT_*s have the same layout as the associated MESA_FORMAT_*s for big-endian. The MESA_FORMAT_*s are already handled correctly. Fixes various piglit tests on z. No regressions on x86_64. [airlied: squash subsequent patches] util: Add big-endian layout for 5551 and 565 formats util: Add big-endian layout for 10/10/10/2 formats util: Add big-endian layout for 4444 formats util: Add big-endian layout for 233 format util: Add big-endian layout for 44 formats Signed-off-by: Dave Airlie <[email protected]>
* llvmpipe: Fix PIPE_FORMAT_Z32_FLOAT_S8X24_UINT handling for big-endian.Richard Sandiford2014-09-161-1/+2
| | | | | | | | | | | | | | | | | llvmpipe treats PIPE_FORMAT_Z32_FLOAT_S8X24_UINT as a bit of a special case, handling it as two 32-bit pieces rather than a single 64-bit block: /* 64bit d/s format is special already extracted 32 bits */ total_bits = format_desc->block.bits > 32 ? 32 : format_desc->block.bits; The format_desc describes the whole 64-bit block, so the z shift will be 32 for big-endian. But since we're accessing the z channel as a 32-bit value rather than a 64-bit value, we need to mask the shift with 31. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallivm: Fix uses of 2^24Richard Sandiford2014-09-161-4/+4
| | | | | | | | | | Fallback cases in lp_bld_arit.c used 2^24 to mean "2 to the power 24", but in C it's "2 xor 24", i.e. 26. Fixed by using 1<< instead. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Cc: "10.2 10.3" <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallivm: Add SNORM clamping to lp_build_{add, sub}Richard Sandiford2014-09-161-6/+28
| | | | | | | ...fixing the associated TODO. Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Richard Sandiford <[email protected]>
* gallivm: attach DataLayout to module too, not just pass manager.Rafael Ávila de Espíndola2014-09-161-0/+7
| | | | | | | | | It looks like it was possible to attach it to both for a long time, however since llvm r217548 attaching it to just the pass manager is no longer sufficient and causes bugs (see http://llvm.org/bugs/show_bug.cgi?id=20903). Tested-by: Vinson Lee <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: handle SAMPLE opcode in aos samplingRoland Scheidegger2014-09-162-13/+50
| | | | | | | | | | | This is just a very limited version, in particular sampler and sampler view index must be the same. It cannot handle any modifiers neither. Works much the same as soa version otherwise, to figure out the target we need to store the sampler view dcls. While here, also handle (no-op) RET and get rid of a couple bogus deprecated comments. Reviewed-by: Jose Fonseca <[email protected]>
* tgsi: accept offsets for sample opcodes too in the text parserRoland Scheidegger2014-09-161-3/+2
| | | | | | | | | | sample opcodes are a little oddly represented in the opcode_info, since they don't count as texture instructions - they don't have valid target information, but they may have offsets (unlike "ordinary" texture instructions, the texture token may be optional for them). So just make sure with these opcodes the optional offsets are accepted. Reviewed-by: Jose Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 15:09:28 +0000