summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* nvc0/ir: cache vertex out base so that we don't recompute againIlia Mirkin2015-07-291-8/+15
| | | | | | | | The global CSE pass stinks and is unable to pull this out. Easy enough to handle it here and avoid generating unnecessary special register loads (which can allegedly be quite slow). Signed-off-by: Ilia Mirkin <[email protected]>
* nvc0/ir: output base for reading is based on laneidIlia Mirkin2015-07-291-0/+25
| | | | | | | | | | | PFETCH retrieves the address for incoming vertices, not output vertices in TCS. For output vertices, we must use the laneid as a base. Fixes barrier piglit test, which was failing for entirely non-barrier reasons, but rather that it was (a) trying to draw multiple patches and (b) the incoming patch size was not the same as the outgoing patch size. Signed-off-by: Ilia Mirkin <[email protected]>
* Revert "pipe-loader: simplify pipe_loader_drm_probe"Francisco Jerez2015-07-291-4/+9
| | | | | | | | | This reverts commit a27ec5dc460b91dc44675f48cddbbb2631ee824f. It breaks the intended behaviour of pipe_loader_probe() with ndev==0 as relied upon by clover to query the number of devices available to the pipe loader in the system. Acked-by: Emil Velikov <[email protected]>
* i965/fs: Switch opt_cse() to the fs_builder constructor from instruction.Francisco Jerez2015-07-291-8/+8
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Switch lower_logical_sends() to the fs_builder constructor from ↵Francisco Jerez2015-07-291-3/+1
| | | | | | instruction. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Switch lower_load_payload() to the fs_builder constructor from ↵Francisco Jerez2015-07-291-5/+2
| | | | | | instruction. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Don't rely on the default builder to create a null register in ↵Francisco Jerez2015-07-291-1/+1
| | | | | | | | | emit_spill. It's not guaranteed to have the same width as the instruction generating the spilled variable. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Set up the builder execution size explicitly in opt_sampler_eot().Francisco Jerez2015-07-291-4/+7
| | | | | | | | | | | opt_sampler_eot() was relying on the default builder to have the same width as the sampler and FB write opcodes it was eliminating, the channel selects didn't matter because the builder was only being used to allocate registers, no new instructions were being emitted with it. A future commit will change the width of the default builder what will break this assumption, so initialize it explicitly here. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Initialize a builder explicitly in opt_peephole_predicated_break().Francisco Jerez2015-07-291-3/+5
| | | | | | | | This wasn't taking into account the execution controls of the original instruction, but it was most likely not a bug because control flow instructions are typically full width. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Set execution controls explicitly in opt_peephole_sel().Francisco Jerez2015-07-291-3/+9
| | | | | | | | | | | Emit the SELs and MOVs with the same execution controls as the original MOVs, and the CMP with the same execution controls as the IF. Also explicitly check that the execution controls of any pair of MOVs being folded into a SEL are compatible (which is almost always going to be the case), since otherwise it would seem wrong to initialize the builder object below from the then_mov instruction only. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Set execution controls correctly in lower_integer_multiplication().Francisco Jerez2015-07-291-1/+1
| | | | | | | | lower_integer_multiplication() was ignoring the execution controls of the original MUL instruction. Fix it by using the new fs_builder constructor. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Set execution controls correctly for lowered pull constant loads.Francisco Jerez2015-07-291-3/+3
| | | | | | | | | | | | demote_pull_constants() was ignoring the execution size and channel selects of the instruction that wanted the constant, which doesn't matter for uniform pull constant loads because all channels get the same scalar value, but it might for varying pull constant loads. Fix it by using the new fs_builder() constructor that takes care of setting execution controls compatible with the instruction passed as argument. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Set the execution size of the MOVs correctly in ↵Francisco Jerez2015-07-291-1/+1
| | | | | | | | | | opt_combine_constants(). The execution size was being left equal to the default of 8/16, which AFAICT would have overwritten components other than the one we wanted to initialize and could potentially have corrupted other registers. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Define a new fs_builder constructor taking an instruction as argument.Francisco Jerez2015-07-291-0/+16
| | | | | | | | | | | | | | | | | | | | | | | We have a number of optimization passes that repeat the same pattern before inserting new instructions into the program based on some previous instruction: They point the default builder at the original instruction, then call exec_all() and group() to select the same execution controls the original instruction had, and then maybe call annotate() to clone the debug annotation from the original instruction. In fact an optimization pass missing any of these steps is likely to be broken if the intention was to emit new code based on a preexisting instruction, so let's make it easy for passes to do the right thing by having an fs_builder constructor that automates the task of setting up a builder to emit a given instruction provided as argument. The following patches fix all cases I've found in which we weren't explicitly initializing the execution controls of the emitted instructions, and clean-up optimization passes which were already doing the right thing to use the new constructor. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Translate memory barrier NIR intrinsics.Francisco Jerez2015-07-291-0/+7
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Execute nir_setup_uniforms, _inputs and _outputs unconditionally.Francisco Jerez2015-07-291-15/+7
| | | | | | | | | | | | | | | Images take up zero uniform slots in the nir_shader::num_uniforms calculation, but nir_setup_uniforms needs to be executed even if the program has no non-image uniforms so the driver-specific image parameters are uploaded. nir_setup_uniforms is a no-op if there are really no uniforms, so checking the num_uniform count is useless in any case. The nir_setup_inputs and _outputs changes shouldn't lead to any functional change, they are just meant to preserve the symmetry between them and nir_setup_uniforms. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Don't overwrite fs_visitor::uniforms and ::param_size during the ↵Francisco Jerez2015-07-291-3/+4
| | | | | | | | | | | | | SIMD16 run. Image variables need to allocate additional uniform slots over nir_shader::num_uniforms. nir_setup_uniforms() overwrites the values imported from the SIMD8 visitor and then exits early before entering the nir_shader::uniforms loop, so image uniforms are never re-created. Instead leave the imported values alone, they *must* be the same for the uniform layout of both runs to be compatible. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Drop unused untyped surface read and atomic emit methods.Francisco Jerez2015-07-293-127/+5
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Revisit NIR atomic counter intrinsic translation.Francisco Jerez2015-07-291-17/+32
| | | | | | | | | | | Rewrite the NIR atomic counter intrinsics translation code making use of the recently introduced surface builder. This will allow the removal of some of the functionality duplicated between the visitor and surface builder. v2: Drop VEC4 suport. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Import surface message builder helper functions.Francisco Jerez2015-07-293-0/+234
| | | | | | | | | | | Implement helper functions that can be used to construct and send untyped and typed surface read, write and atomic messages to the shared dataport unit easily. v2: Drop VEC4 suport. v3: Reimplement in terms of logical send opcodes. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Handle zero-size allocations in fs_builder::vgrf().Francisco Jerez2015-07-291-4/+7
| | | | | | | | | | | | | | This will be handy to avoid some ugly ternary operators in the next patch, like: fs_reg reg = (size == 0 ? null_reg_ud() : vgrf(..., size)); Because a zero-size register allocation is guaranteed not to ever be read or written we can just return the null register. Another possibility would be to actually allocate a zero-size VGRF what would involve defining a zero-size register class in the register allocator and a considerable amount of churn. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Implement lowering of logical surface instructions.Francisco Jerez2015-07-291-8/+55
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Hook up SIMD lowering to unroll surface instructions of unsupported ↵Francisco Jerez2015-07-291-0/+5
| | | | | | width. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Define logical typed and untyped surface opcodes.Francisco Jerez2015-07-293-0/+129
| | | | | | | | | | | | | | | Each logical variant is largely equivalent to the original opcode but instead of taking a single payload source it expects its arguments separately as individual sources, like: typed_surface_write_logical null, coordinates, source, surface, num_coordinates, num_components This patch defines the opcodes and usual instruction boilerplate, including a placeholder lowering function provided mainly as documentation for their source registers. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Lift the constness restriction on surface indices passed to untyped ops.Francisco Jerez2015-07-294-12/+9
| | | | | | v2: Update NIR atomic intrinsic handling too (Ken). Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Define the setup_vector_uniform_values() backend_visitor interface.Francisco Jerez2015-07-295-19/+44
| | | | | | | | | This cleans up the VEC4 implementation of setup_uniform_values() somewhat and will avoid duplication of the image uniform upload code by having a common interface to upload a vector of uniforms on either back-end. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Remove the emit_texture_gen*() fs_visitor methods.Francisco Jerez2015-07-292-629/+0
| | | | | | | This is now dead code. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Reimplement emit_mcs_fetch() in terms of logical sends.Francisco Jerez2015-07-292-24/+15
| | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Reimplement emit_texture() in terms of logical send messages.Francisco Jerez2015-07-291-17/+49
| | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Hook up SIMD lowering to handle texturing opcodes of unsupported width.Francisco Jerez2015-07-291-0/+33
| | | | | | | | | | | | | | | | | | This should match the set of cases in which we currently call fail() or no16() from the emit_texture_*() methods and the ones in which emit_texture_gen4() enables the SIMD16 workaround. Hint for reviewers: It's not a big deal if I happen to have missed some case here, it will just lead to an assertion failure down the road which is easily fixable, however being stricter than necessary won't cause any visible breakage, it would just decrease performance silently due to the unnecessary message splitting, so feel free to double-check that all cases listed here already cause a SIMD8/16 fall-back with the current texturing code -- You may want to skip over the Gen5-6 cases though if you don't have pencil and paper at hand. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Implement lowering of logical texturing opcodes on Gen4.Francisco Jerez2015-07-291-1/+107
| | | | | | | | | | | | | | | | | | | | | | | | Unlike its Gen5 and Gen7 counterparts this patch isn't a plain refactor of the previous Gen4 texturing code, it's more of a rewrite largely based on emit_texture_gen4_simd16(). The reason is that on the one hand the original emit_texture_gen4() code didn't seem easily fixable to be SIMD width-invariant and had plenty of clutter to support SIMD-width workarounds which are no longer required. On the other hand emit_texture_gen4_simd16() was missing a number of SIMD8-only opcodes. This should generalize both and roughly match their current behaviour where there is overlap. Incidentally this will fix the following piglits on Gen4: arb_shader_texture_lod.execution.arb_shader_texture_lod-texgrad arb_shader_texture_lod.execution.tex-miplevel-selection *gradarb 2d arb_shader_texture_lod.execution.tex-miplevel-selection *gradarb 3d arb_shader_texture_lod.execution.tex-miplevel-selection *projgradarb 2d arb_shader_texture_lod.execution.tex-miplevel-selection *projgradarb 2d_projvec4 arb_shader_texture_lod.execution.tex-miplevel-selection *projgradarb 3d Acked-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Implement lowering of logical texturing opcodes on Gen5-6.Francisco Jerez2015-07-291-0/+103
| | | | | | | | | | This should be largely equivalent to emit_texture_gen5() except for slight codestyle changes and the use i965 opcodes instead of the ir_texture_opcode enum, see "i965/fs: Implement lowering of logical texturing opcodes on Gen7+." for the mapping between them. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Lower SHADER_OPCODE_TXF_UMS/MCS_LOGICAL too on Gen7+.Francisco Jerez2015-07-291-5/+11
| | | | | | | | These weren't being handled by emit_texture_gen7() but we can easily lower them here for consistency with other texturing opcodes. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Implement lowering of logical texturing opcodes on Gen7+.Francisco Jerez2015-07-291-1/+216
| | | | | | | | | | | | | | | | | | | | | | | | | | | This should be largely equivalent to emit_texture_gen7() except that we now get i965 sampling opcodes directly rather than ir_texture_opcode enum values. The mapping is as follows: - ir_tex -> SHADER_OPCODE_TEX - ir_txb -> FS_OPCODE_TXB - ir_txl -> SHADER_OPCODE_TXL - ir_txd -> SHADER_OPCODE_TXD - ir_txf -> SHADER_OPCODE_TXF - ir_txf_ms -> SHADER_OPCODE_TXF_CMS - ir_txs -> SHADER_OPCODE_TXS - ir_query_levels -> SHADER_OPCODE_TXS too, the visitor will make sure that the provided lod value is zero in this case. - ir_lod -> SHADER_OPCODE_LOD - ir_tg4 -> SHADER_OPCODE_TG4_OFFSET if the offset value is not immediate, SHADER_OPCODE_TG4 otherwise. Other than that there are only minor changes and style fixes like the implementation now being factored out in static functions to improve encapsulation. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Fix misleading comment regarding the message header in ↵Francisco Jerez2015-07-291-2/+3
| | | | | | | | | | emit_texture_gen7. This hasn't been overallocating space for the header for a long time. It still leaves the header uninitialized though until the generator fixes it. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Pass a BAD_FILE header source to LOAD_PAYLOAD in emit_texture_gen7().Francisco Jerez2015-07-291-1/+1
| | | | | | | | | So that it's left uninitialized by LOAD_PAYLOAD, we only need to reserve space for it in the message since it will be initialized implicitly by the generator. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Fix opt_zero_samples() for texturing ops not matching dispatch_width.Francisco Jerez2015-07-291-3/+3
| | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Use exec_size instead of dispatch_width to determine the message ↵Francisco Jerez2015-07-291-4/+4
| | | | | | | | | | | | | variant. dispatch_width is global for a single compilation and doesn't necessarily match the desired execution width if we had to lower the original full-width instruction due to hardware limitations. These were all inside a Gen4-specific branch so this patch shouldn't have any effect on more recent hardware. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Define logical texture sampling opcodes.Francisco Jerez2015-07-293-0/+148
| | | | | | | | | | | | | | | | | Each logical variant is largely equivalent to the original opcode but instead of taking a single payload source it expects the arguments separately as individual sources, like: tex_logical dst, coordinates, shadow_c, lod, lod2, sample_index, mcs, sampler, offset, num_coordinate_components, num_grad_components This patch defines the opcodes and usual instruction boilerplate, including a placeholder lowering function provided mostly as documentation for their source registers. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Reimplement emit_single_fb_write() in terms of logical framebuffer ↵Francisco Jerez2015-07-292-187/+21
| | | | | | | | | | | | | writes. The only non-trivial thing it still has to do is figure out where to take the src/dst depth values from and predicate the instruction if discard is in use. The manual SIMD unrolling logic in the dual-source case goes away because this is now handled transparently by the SIMD lowering pass. Reviewed-by: Jason Ekstrand <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965/fs: Implement lowering of logical framebuffer writes.Francisco Jerez2015-07-291-1/+136
| | | | | | | | | | | | | | | | | | | | | This does essentially the same thing as fs_visitor::emit_single_fb_write(), with some slight differences: - We don't have to worry about exec_size and use_2nd_half anymore, 16-wide sources have already been lowered to 8-wide thanks to the previous commit and the manual argument unzipping is no longer required. - The src/dst_depth and sample_mask values are now explicit sources of the instruction instead of being taken from the visitor state directly. The same goes for the kill-pixel mask that will be passed to the instruction explicitly as predicate. - Everything is now done in static functions to improve encapsulation. Reviewed-by: Jason Ekstrand <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965/fs: Hook up SIMD lowering to unroll FB writes of unsupported width.Francisco Jerez2015-07-291-0/+9
| | | | | | | | This shouldn't have any effect because we don't emit logical framebuffer writes yet. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Remove the FS_OPCODE_SET_OMASK pseudo-opcode.Francisco Jerez2015-07-294-42/+0
| | | | | | | This is now unused. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Don't attempt to copy the useless half of oMask for SIMD8 FB writes.Francisco Jerez2015-07-291-8/+18
| | | | | | | | | | | | | | | | | | There's no need to initialize the wrong half of oMask in the payload when we're doing an 8-wide framebuffer write because it will be ignored by the hardware anyway. By doing it this way we can let the SIMD lowering pass split the sample_mask source as a regular per-channel source, otherwise we would have to introduce some sort of per-instruction source query or use fs_inst::header_size for the lowering pass to be able to find out whether some source is header-like, and leave the source untouched in that case. As a bonus this achieves the same purpose as the previous code without making use of the SET_OMASK pseudo-instruction, which will be removed in a future commit. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Move up Gen6 no16 check to emit_fb_writes().Francisco Jerez2015-07-291-9/+11
| | | | | | | And update the comment. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Move up prog_data->uses_omask assignment up to brw_codegen_wm_prog().Francisco Jerez2015-07-292-3/+2
| | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Simplify control flow in emit_single_fb_write().Francisco Jerez2015-07-291-12/+16
| | | | | | | | Flatten the if ladder to match the way that the ordering of these fields is specified in the hardware documentation a bit more closely. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Fix slight layering violation in emit_single_fb_writes().Francisco Jerez2015-07-291-12/+10
| | | | | | | | | | | | | | | | | In cases where the color0 argument wasn't being provided, emit_single_fb_writes() would take the alpha channel directly from the visitor state instead of taking it from its arguments. This sort of hack didn't fit nicely into the logical send-message approach because all parameters of the instruction have to be visible to the SIMD lowering pass for it to be able to split them into halves at all. Fix it by using LOAD_PAYLOAD in fs_visitor::emit_fb_writes() to provide an actual color0 vector with undefined contents except for the alpha component to match the previous behavior when no color buffers are enabled. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Make sure that the type sizes are compatible during copy propagation.Francisco Jerez2015-07-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | It's surprising that we weren't checking for this already. A future patch will cause code like the following to be emitted: MOV(16) tmp<1>:uw, src MOV(8) dst<1>:ud, tmp<8,8,1>:ud The second MOV comes from the expansion of a LOAD_PAYLOAD header copy, so I don't have control over its types. Copy propagation will happily turn this into: MOV(8) dst<1>:ud, src Which has different semantics. Fix it by preventing propagation in cases where a single channel of the instruction would span several channels of the copy (this requirement could in fact be relaxed if the copy is just a trivial memcpy, but this case is unusual enough that I don't think it matters in practice). I'm deliberately only checking if the type of the instruction is larger than the original, because the converse case seems to be handled correctly already in the code below. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Honour the instruction force_sechalf and exec_size fields for FB ↵Francisco Jerez2015-07-291-2/+2
| | | | | | | | | | writes. We were previously guessing the half based on the EOT flag which seems rather gross. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-21 02:59:53 +0000