summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* gallium: use fence_finish instead of fence_signalled in state trackersMarek Olšák2015-07-051-1/+1
| | | | Reviewed-by: Brian Paul <[email protected]>
* dri/common: allow BGRX sRGB visualsMarek Olšák2015-07-031-0/+1
|
* mesa: fix sRGB rendering for GLES1Marek Olšák2015-07-031-6/+4
|
* i965/fs: Don't disable SIMD16 when using the pixel interpolatorNeil Roberts2015-07-031-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a comment saying that in SIMD16 mode the pixel interpolator returns coords interleaved 8 channels at a time and that this requires extra work to support. However, this interleaved format is exactly what the PLN instruction requires so I don't think anything needs to be done to support it apart from removing the line to disable it and to ensure that the message lengths for the send message are correct. I am more convinced that this is correct because as it says in the comment this interleaved output is identical to what is given in the thread payload. The code generated to apply the plane equation to these coordinates is identical on SIMD16 and SIMD8 except that the dispatch width is larger which implies no special unmangling is needed. Perhaps the confusion stems from the fact that the description of the PLN instruction in the IVB PRM seems to imply that the src1 inputs are not interleaved so it wouldn't work. However, in the HSW and BDW PRMs, the pseudo-code is different and looks like it expects the interleaved format. Mesa doesn't seem to generate different code on IVB to uninterleave the payload registers and everything is working so I can only assume that the PRM is wrong. I tested the interpolateAt tests on HSW and did a full Piglit run on IVB on there were no regressions. Reviewed-by: Chris Forbes <[email protected]>
* mesa/prog: relative offsets into constbufs are not constantIlia Mirkin2015-07-021-0/+2
| | | | | | | | | | | The optimization logic relies on being able to read out constbuf values from program parameters. However that only works if there's no relative addressing involved. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91173 Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.5 10.6" <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: allocate at least 1 BLEND_STATE elementMike Stroyan2015-07-021-1/+1
| | | | | | | | | | | | | | | | When there are no color buffer render targets, gen6 and gen7 still use the first BLEND_STATE element to determine alpha test. gen6_upload_blend_state was allocating zero elements when ctx->Color.AlphaEnabled was false. That left _3DSTATE_CC_STATE_POINTERS or _3DSTATE_BLEND_STATE_POINTERS pointing to random data from some previous brw_state_batch(). That sometimes suppressed depth rendering when those bits happened to mean COMPAREFUNC_NEVER. This produced flickering shadows for dota2 reborn. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80500 Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa/st: Add checks for signed/unsigned integer conversions in ReadPixelsIago Toral Quiroga2015-07-021-0/+28
| | | | | | | | | | | | | | | | | | These checks were in Mesa prior to commit fbba25bba, but they were not necessary for the purpose that Mesa intended (check if we could resolve ReadPixels via memcpy), so that commit took them away. Unfortunately, it seems that some Gallium drivers rely on these checks to make the decision of whether they should fallback to Mesa's implementation of ReadPixels correctly. Michel Dänzer reported that the following piglit test would fail on radeonsi after commit fbba25bba: spec@ext_texture_integer@fbo_integer_readpixels_sint_uint This patch puts the checks back in Gallium, where they are needed. Tested-by: Michel Dänzer <[email protected]>
* mesa: reset the source packing when creating temp transfer imageIlia Mirkin2015-07-011-0/+1
| | | | | | | | | | | | | | Commit 4b249d2ee (mesa: Handle transferOps in texstore_rgba) introduced proper transferops handling, but in updating the source to the newly allocated temporary image neglected to reset the source packing. Set it to the default which should be appropriate for the floats used. Fixes: 4b249d2ee (mesa: Handle transferOps in texstore_rgba) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91173 Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.5 10.6" <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/gen9: use an unreserved surface alignment valueNanley Chery2015-07-011-4/+4
| | | | | | | | | | | Although the horizontal and vertical alignment fields are ignored here, 0 is a reserved value for them and may cause undefined behavior. Change the default value to an abitrary valid one. v2: add comment about chosen value (Topi). Reviewed-by: Anuj Phogat <[email protected]> Signed-off-by: Nanley Chery <[email protected]>
* i965/fs: Use the builder directly for the gen6 interpolation add(32)Jason Ekstrand2015-07-011-6/+5
| | | | | | | Now that we can create builders with a bigger width than their parent as long as it's exec_all, we don't need to create the instruction manually. Reviewed-by: Francisco Jerez <[email protected]>
* i965/fs: Relax fs_builder channel group assertion when force_writemask_all ↵Francisco Jerez2015-07-013-7/+7
| | | | | | | | | | | | | | | | | | | is on. This assertion was meant to catch code inadvertently escaping the control flow jail determined by the group of channel enable signals selected by some caller, however it seems useful to be able to increase the default execution size as long as force_writemask_all is enabled, because force_writemask_all is an explicit indication that there is no longer a one-to-one correspondence between channels and SIMD components so the restriction doesn't apply. In addition reorder the calls to fs_builder::group and ::exec_all in a couple of places to make sure that we don't temporarily break this invariant in the future for instructions with exec_size higher than the dispatch width. Reviewed-by: Jason Ekstrand <[email protected]>
* nouveau: rename var name for nouveau_vieux to avoid conflict with nouveauIlia Mirkin2015-07-011-2/+2
| | | | | | | | | | | | We want to require different versions for nouveau and nouveau_vieux. autoconf will only check for NOUVEAU once if both drivers are enabled, meaning both version checks don't get executed. Rename the nouveau_vieux one to NVVIEUX to avoid the issue. Signed-off-by: Ilia Mirkin <[email protected]> Tested-by: Alexandre Courbot <[email protected]> Tested-by: Martin Peres <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* glsl: create program resource list after LinkShaderTapani Pälli2015-07-011-0/+2
| | | | | | | | | Resource list can be created properly only after LinkShader hook has been called to make sure all dead variables have been removed. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Martin Peres <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90925
* i965/fs: Fix PIXEL_X/Y in regs_read()Jason Ekstrand2015-06-301-1/+1
| | | | PIXEL_X/Y takes a vec2 in the first argument
* i965/fs: Remove the width field from fs_regJason Ekstrand2015-06-308-107/+30
| | | | | | | | | | | | | As of now, the width field is no longer used for anything. The width field "seemed like a good idea at the time" but is actually entirely redundant with the instruction's execution size. Initially, it gave us the ability to easily set the instructions execution size based entirely on register widths. With the builder, we can easiliy set the sizes explicitly and the width field doesn't have as much purpose. At this point, it's just redundant information that can get out of sync so it really needs to go. Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs_generator: Use inst->exec_size for determining hardware reg widthsJason Ekstrand2015-06-301-7/+7
| | | | | Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Use exec_size instead of dst.width for computing component sizeJason Ekstrand2015-06-305-8/+8
| | | | | | | | There are a variety of places where we use dst.width / 8 to compute the size of a single logical channel. Instead, we should be using exec_size. Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Use the builder dispatch_width for computing register offsetsJason Ekstrand2015-06-301-1/+1
| | | | | Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* i965/fs: Use the builder dispatch width instead of dst.width for pull constantsJason Ekstrand2015-06-301-4/+4
| | | | | Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Remove exec_size guessing from fs_inst::init()Jason Ekstrand2015-06-301-22/+0
| | | | | | | | Now that all of the non-explicit constructors are gone, we don't need to guess anymore. Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs_builder: Use the dispatch width for setting exec sizesJason Ekstrand2015-06-301-9/+11
| | | | | | | Previously we used dst.width but the two *should* be the same. Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Use exec_size for determining regs read/written and partial writesJason Ekstrand2015-06-301-3/+3
| | | | | Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Remove fs_inst constructors that don't take an explicit exec_sizeJason Ekstrand2015-06-304-39/+8
| | | | | Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Make better use of the builder in shader_timeJason Ekstrand2015-06-301-6/+8
| | | | | | | | | Previously, we were just depending on register widths to ensure that various things were exec_size of 1 etc. Now, we do so explicitly using the builder. Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Add a builder argument to offset()Jason Ekstrand2015-06-307-123/+132
| | | | | Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Move offset(fs_reg, unsigned) to brw_fs.hJason Ekstrand2015-06-302-21/+21
| | | | | | | | Shortly, offset() will depend on the builder so we need it moved to some place where it has access to that. Reviewed-by: Iago Toral Quiroga <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/blorp: Explicitly set execution sizes for new'd instructionsJason Ekstrand2015-06-301-4/+5
| | | | | | | | This doesn't affect instructions allocated using the builder. Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Set the builder group for emitting FB-write stencil/AA alphaJason Ekstrand2015-06-301-1/+1
| | | | | | Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Explicitly set the exec_size on the add(32) in interpolation setupJason Ekstrand2015-06-301-4/+6
| | | | | | | | | | | | | | | | | Soon we will start using the builder to explicitly set all the execution sizes. We could make a 32-wide builder, but the builder asserts that we never grow it which is usually a reasonable assumption. Since this one instruction is a bit of an odd-ball, we just set the exec_size explicitly. v2: Explicitly new the fs_inst instead of using the builder and setting exec_size after the fact. v3: Set force_writemask_all with the builder instead of directly. The builder over-writes it if we set it manually. Also, if we don't have force_writemask_all in the builder it will assert-fail on SIMD32. Reviewed-by: Iago Toral Quiroga <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Properly handle LOAD_PAYLOAD in fs_inst::regs_readJason Ekstrand2015-06-301-0/+5
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Report the right value in fs_inst::regs_read() for PIXEL_X/YJason Ekstrand2015-06-301-2/+9
| | | | | | Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Fix fs_inst::regs_read() for uniform pull constant loadsJason Ekstrand2015-06-301-0/+6
| | | | | | | | | | | | Previously, fs_inst::regs_read() fell back to depending on the register width for the second source. This isn't really correct since it isn't a SIMD8 value at all, but a SIMD4x2 value. This commit changes it to explicitly be always one register. v2: Use mlen for determining the number of registers read Reviewed-by: Iago Toral Quiroga <[email protected]> Acked-by: Francisco Jerez <[email protected]>
* i965/fs: Actually set/use the mlen for gen7 uniform pull constant loadsJason Ekstrand2015-06-302-13/+15
| | | | | | | | | Previously, we were allocating the payload with different sizes per gen and then figuring out the mlen in the generator based on gen. This meant, among other things, that the higher level passes knew nothing about it. Acked-by: Francisco Jerez <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Use a switch statement in fs_inst::regs_read()Jason Ekstrand2015-06-301-22/+23
| | | | | | | | This makes things a little simpler, more efficient, and quite a bit more readable. Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/fs: emit constants only onceConnor Abbott2015-06-302-13/+16
| | | | | | | | | | | | | | | | | | | Before, we would lazily emit a MOV whenever we encountered a use of a constant. Now that we have a dedicated file for SSA values, we can instead only emit the MOV's once, which is more consistent and prevents us from relying on CSE to re-combine the constants when they aren't absorbed into the instruction. total instructions in shared programs: 6078991 -> 6073118 (-0.10%) instructions in affected programs: 402221 -> 396348 (-1.46%) helped: 1527 HURT: 0 GAINED: 8 LOST: 2 v2: split this out from the previous commit (Jason) Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: use SSA values directlyConnor Abbott2015-06-305-30/+52
| | | | | | | | | | | Before, we would use registers, but set a magical "parent_instr" field to indicate that it was actually purely an SSA value (i.e., it wasn't involved in any phi nodes). Instead, just use SSA values directly, which lets us get rid of the hack and reduces memory usage since we're not allocating a nir_register for every value. It also makes our handling of load_const more consistent compared to the other instructions. Reviewed-by: Jason Ekstrand <[email protected]>
* nir/from_ssa: add a flag to not convert everything from SSAConnor Abbott2015-06-301-1/+1
| | | | | | | | | | | | | We already don't convert constants out of SSA, and in our backend we'd like to have only one way of saying something is still in SSA. The one tricky part about this is that we may now leave some undef instructions around if they aren't part of a phi-web, so we have to be more careful about deleting them. v2: rename and flip meaning of flag (Jason) Reviewed-by: Jason Ekstrand <[email protected]>
* mesa/st: use EmitNoIndirectSampler if !ARB_gpu_shader5Tapani Pälli2015-06-301-0/+5
| | | | | | | Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Cc: "10.5" and "10.6" <[email protected]>
* i915: use EmitNoIndirectSamplerTapani Pälli2015-06-301-0/+3
| | | | | | Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Cc: "10.5" and "10.6" <[email protected]>
* i965: use EmitNoIndirectSampler for gen < 7Tapani Pälli2015-06-301-0/+4
| | | | | | Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Cc: "10.5" and "10.6" <[email protected]>
* mesa/glsl: new compiler option EmitNoIndirectSamplerTapani Pälli2015-06-301-0/+1
| | | | | | | | | | | | | | | | Patch provides new compiler option for backend to force unroll loops that have non-constant expression indexing on sampler arrays. This makes sure that we can never end up with a shader that uses loop induction variable as sampler array index but does not unroll because of having too much instructions. This would not work without dynamic indexing support. v2: change option name as EmitNoIndirectSampler Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Cc: "10.5" and "10.6" <[email protected]>
* i965: Don't use GCC extension for ?: with only two operands.Kenneth Graunke2015-06-291-3/+5
| | | | | | | | | | | | | | | | | | | From the "apparently I don't know C" files...GCC apparently supports: x ?: y which is equivalent to x ? x : y except that it doesn't cause side-effects to occur twice. See: https://gcc.gnu.org/onlinedocs/gcc/Conditionals.html#Conditionals This was confusing and looked like a typo. It doesn't really buy us anything, so just write the obvious code in normal C. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* i965/skl: Extract the blit command setup in to a helperAnuj Phogat2015-06-291-32/+61
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965/gen9: Add XY_FAST_COPY_BLT support to intelEmitCopyBlit()Anuj Phogat2015-06-294-63/+287
| | | | | | | | | | | | | | | | | | This patch enables using XY_FAST_COPY_BLT only for Yf/Ys tiled buffers. It can be later turned on for other tiling patterns (X,Y) too. V3: Flush in between sequential fast copy blits. Fix src/dst alignment requirements. Make can_fast_copy_blit() helper. Use ffs(), is_power_of_two() Move overlap computation inside intel_miptree_blit(). V4: Use _mesa_regions_overlap() function. Add check for src_buffer == dst_buffer. Simplify horizontal and vertical alignment computations. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* mesa/swrast: Use global function _mesa_regions_overlap()Anuj Phogat2015-06-291-13/+3
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa/st: Use global function _mesa_regions_overlap()Anuj Phogat2015-06-291-27/+3
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Add a new helper function _mesa_regions_overlap()Anuj Phogat2015-06-292-0/+32
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965/gen9: Allocate YF/YS tiled buffer objectsAnuj Phogat2015-06-291-3/+62
| | | | | | | | | | | | | | | | | | | In case of I915_TILING_{X,Y} we need to pass tiling format to libdrm using drm_intel_bo_alloc_tiled(). But, In case of YF/YS tiled buffers libdrm need not know about the tiling format because these buffers don't have hardware support to be tiled or detiled through a fenced region. libdrm still need to know buffer alignment value for its use in kernel when resolving the relocation. Using drm_intel_bo_alloc_for_render() for YF/YS tiled buffers satisfy both the above conditions. V2: Delete min/max buffer size restrictions not valid for i965+. Remove redundant align to tile size statements. Remove some redundant code now when there are no min/max buffer size. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Make a helper function intel_miptree_can_use_tr_mode()Anuj Phogat2015-06-291-11/+19
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Make a helper function intel_miptree_release_levels()Anuj Phogat2015-06-291-6/+12
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 03:33:06 +0000