aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
* i965/nir/vec4: Select between new nir_vec4 or current vec4_visitor code-pathsEduardo Lima Mitev2015-08-032-10/+22
| | | | | | | | | | The NIR->vec4 pass will be activated if both the following conditions are met: * INTEL_USE_NIR environment variable is defined and is positive (1 or true) * The stage is vertex shader (support for geometry shaders and ARB_vertex_program will be added later). Reviewed-by: Jason Ekstrand <[email protected]>
* i965/nir/vec4: Add implementation placeholders for a new NIR->vec4 passEduardo Lima Mitev2015-08-033-0/+273
| | | | | | | | | | This patch will add a brw_vec4_nir.cpp file filled with entry point methods to the main functionality, following a structure similar to brw_fs_nir.cpp. Subsequent patches in this series will be adding the implementations for these methods, incrementally. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Fix regression with SIMD8 VS since ↵Francisco Jerez2015-07-311-1/+2
| | | | | | | | | | | | | | b5f1a48e234d47b24df38cb562cffb8941d43795. With num_direct_uniforms == 0 there's no space allocated in the param_size array for the one block of direct uniforms -- On the FS stage this would be a harmless no-op because it would simply re-set one of the param_size entries allocated for the sampler units to zero, but on the VS stage it has been reported to cause memory corruption followed by a crash -- Surprising how a full piglit run on Gen8 didn't catch it. Reported-and-reviewed-by: "Lofstedt, Marta" <[email protected]>
* i965/gen9: Add hs, ds, and cs thread + urb infoBen Widawsky2015-07-301-0/+10
| | | | | | | | | | | | | | | | | For SKL: These are the production values. For BXT: These are low estimates to enable platforms. This patch was originally part of i965/skl: Add production thread counts and URB size but was split out at Jordan's request (which I found to be reasonable). Note on stable inclusion: 10.6 does not care about hs, and ds. It does care about cs, but since Jordan was the one that asked me to extract it, I'll leave it up to him to deal with a backport to stable is required. Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965/bxt: Use more conservative thread countsBen Widawsky2015-07-301-2/+4
| | | | | | | | | | | | Since we really do not know what may occur in the future, pick a more conservative value for thread counts until we know better what values are correct. As far as I can tell, the old values will work fine, but some of the registers seem to indicate that going even lower is possible and the purpose of having early support is to enable as many configurations that can possibly exist (we can trim things down after platforms begin shipping later). Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965/skl: Add production thread counts and URB sizeBen Widawsky2015-07-301-5/+5
| | | | | | | | | | | | | This patch adjusts the SKL values to the best known values we have. v2: Remove HS/DS/CS fields. Adding this makes most sense to add to the GEN9_FEATURES macro, however, doing that would require updating BXT values, and Jordan requested I not do that. Conveniently, this request makes a lot of sense wrt to stable backport as HS, and DS do not even exist there. Cc: [email protected] Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965/bxt: Don't use brw_device_info_skl_early on BXTNeil Roberts2015-07-301-1/+3
| | | | | | | | Previously it could end up using the “SKL early” device on BXT depending on the revision number. This would probably break things because for example has_llc would be wrong. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Change the type of max_{vs, hs, ...}_threads variables to unsignedAnuj Phogat2015-07-292-7/+7
| | | | | | | | | Fixes following compiler warning: brw_cs.cpp:386:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* Delete duplicate function is_power_of_two() and use _mesa_is_pow_two()Anuj Phogat2015-07-297-15/+15
| | | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* i965/bxt: Support 3src simd16 instructionsBen Widawsky2015-07-291-3/+1
| | | | | | | | | This is easily accomplished by moving simd16 3src to GEN9_FEATURES. v2: small cleanup to make it more similar to GEN8_FEATURES Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Use float calculations when double is unnecessary.Matt Turner2015-07-2914-34/+35
| | | | | | | | | | | | | | | | | Literals without an f/F suffix are of type double, and implicit conversion rules specify that the float in (float op double) be converted to a double before the operation is performed. I believe float execution was intended (in nearly all cases) or is sufficient (in the case of gen7_urb.c). Removes a lot of float <-> double conversion instructions and replaces many double instructions with float instructions which are cheaper. text data bss dec hex filename 4928659 195160 26192 5150011 4e953b i965_dri.so before 4928315 195152 26192 5149659 4e93db i965_dri.so after Reviewed-by: Iago Toral Quiroga <[email protected]>
* mesa: Use floats for viewport bounds.Matt Turner2015-07-297-7/+7
| | | | | | | | | | | | | | | | | | ARB_viewport_array specifies that DEPTH_RANGE consists of double- precision parameters (corresponding commit d4dc35987), and a preparatory commit (6340e609a) added _mesa_get_viewport_xform() which returned double-precision scale[3] and translate[3] vectors, even though X, Y, Width, and Height were still floats. All users of _mesa_get_viewport_xform() immediately convert the double scale and translation vectors into floats (which were floats originally, but were converted to doubles in _mesa_get_viewport_xform(), sigh). i965 at least cannot consume doubles (see SF_CLIP_VIEWPORT). If we want to pass doubles to hardware, we should have a different function that does that. Acked-by: Mathias Froehlich <[email protected]>
* i965/fs: Make the default builder 64-wide before entering the optimization loop.Francisco Jerez2015-07-292-2/+7
| | | | | | | | | | | Not a typo. Replace the default builder with one of bogus width to catch cases in which optimization passes assume that the default dispatch width is good enough. The execution controls of instructions emitted during optimization should in general match the original code that is being manipulated. Many of the problems fixed in this series were caught by the assertions introduced in this patch. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Don't set exec_all on instructions wider than the original in ↵Francisco Jerez2015-07-291-9/+11
| | | | | | | | | | | | | lower_simd_width. This could have led to somewhat increased bandwidth usage for lowered texturing instructions on Gen4 (which is the only case in which lower_width may be greater than inst->exec_size). After the previous patches the invariant mentioned in the comment should no longer be assumed by any of the other optimization and lowering passes, so the exec_all() call shouldn't be necessary anymore. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Initialize a builder explicitly in the gen4 send dependency ↵Francisco Jerez2015-07-291-4/+7
| | | | | | | | | | | work-arounds. Instead of relying on the default one. This shouldn't lead to any functional changes because DEP_RESOLVE_MOV overrides the execution size of the instruction anyway and other execution controls are irrelevant. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/cfg: Assert that cur_do/while/if pointers are non-NULL.Matt Turner2015-07-291-0/+3
| | | | More.. like in commit 4d93a07c.
* 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 05:00:35 +0000