summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
* i965/reg: Make brw_sr0_reg take a subnr and return a vec1 regJason Ekstrand2016-09-212-13/+9
| | | | | | | | | | | The state register sr0 is really a collection of dwords not a SIMD8 anything. It's much more convenient for brw_sr0_reg to return the particular dword you're looking for rather than a giant blob you have to massage into what you want. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> [ Francisco Jerez: Trivial simplification of brw_ud1_reg(). ] Reviewed-by: Francisco Jerez <currojerez@riseup.net>
* i965: Rename intelScreen to screen.Kenneth Graunke2016-09-2028-170/+170
| | | | | | | | "intelScreen" is wordy and also doesn't fit our style guidelines. "screen" is shorter, which is nice, because we use it fairly often. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Rename __DRIScreen pointers to "dri_screen".Kenneth Graunke2016-09-206-83/+85
| | | | | | | | | | | | | | | | I want to use "screen" as the variable name for a struct intel_screen pointer. This means that we can't use it for __DRIscreen pointers. Sometimes we called it "screen", sometimes "sPriv", sometimes "driScrnPriv", and sometimes "psp" (Pointer to Screen Private?). The last one is particularly confusing because we use "psp" to refer to the Gen4 PIPELINED_STATE_POINTERS packet as well. Let's be consistent. "dri_screen" is clear, and it's not used often enough that I'm worried about the verbosity. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* mesa: Implement ARB_shader_viewport_layer_array for i965Dylan Baker2016-09-201-0/+1
| | | | | | | | | | | | | This extension is a combination of AMD_vertex_shader_viewport_index and AMD_vertex_shader_layer, making it rather trivial to implement. For gallium I *think* this needs a new cap because of the addition of support in tessellation evaluation shaders, and since I don't have any hardware to test it on, I've left that for someone else to wire up. Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Drop assertion about buffer offset at draw time.Eric Anholt2016-09-171-11/+0
| | | | | | | | | Given robust access, we should just be returning zeroes if the user gives us a base pointer that's too big, which is what was happens on a release build. This was caught by a webgl conformance test for out-of-bounds draws on servo. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: enable ARB_ES3_2_compatibility on gen8+Ilia Mirkin2016-09-151-0/+1
| | | | | | | | Note that ASTC support is not actually mandated for this extension to be exposed. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/nir: Roll set_default_interpolation into lower_fs_inputsJason Ekstrand2016-09-153-39/+26
| | | | | | Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/fs: Use NIR for handling forced per-sample interpolationJason Ekstrand2016-09-153-40/+12
| | | | | | Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* nir: Add a flag to lower_io to force "sample" interpolationJason Ekstrand2016-09-152-11/+11
| | | | | | Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/fs: Use sample interpolation for interpolateAtCentroid in persample modeJason Ekstrand2016-09-151-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | From the ARB_gpu_shader5 spec: The built-in functions interpolateAtCentroid() and interpolateAtSample() will sample variables as though they were declared with the "centroid" or "sample" qualifiers, respectively. When running with persample dispatch forced by the API, we interpolate anything that isn't flat as if it's qualified by "sample". In order to keep interpolateAtCentroid() consistent with the "centroid" qualifier, we need to make interpolateAtCentroid() do sample interpolation instead. Nothing in the GLSL spec guarantees that the result of interpolateAtCentroid is uniform across samples in any way, so this is a perfectly fine thing to do. Fixes 8 of the new dEQP-VK.pipeline.multisample_interpolation.* Vulkan CTS tests that specifically validate consistency between the "sample" qualifier and interpolateAtSample() Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Cc: "12.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* intel/blorp: Stop setting 3DSTATE_DRAWING_RECTANGLEJason Ekstrand2016-09-141-0/+5
| | | | | | | | | | | | The Vulkan driver sets 3DSTATE_DRAWING_RECTANGLE once to MAX_INT x MAX_INT at the GPU initialization time and never sets it again. The GL driver sets it every time the framebuffer changes. Originally, blorp set it to the size of the drawing area but meant we had to set it back in the Vulkan driver. Instead, we can easily just do that in the GL driver's blorp_exec implementation and not set it in blorp core. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* intel/blorp: Emit 3DSTATE_MULTISAMPLE directlyJason Ekstrand2016-09-141-13/+0
| | | | | | | | | Previously, we relied on a driver hook for 3DSTATE_MULTISAMPLE. However, now that Vulkan and GL use the same sample positions, we can set up 3DSTATE_MULTISAMPLE directly in blorp and delete the driver hook. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965/vec4: Assert that pull constant load offsets are 16B-aligned.Francisco Jerez2016-09-141-0/+1
| | | | | | | | Non-16B-aligned pull constant loads are unlikely to be particularly useful given that you can get roughly the same effect by using swizzles on the result. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Assert that ATTR regions are register-aligned.Francisco Jerez2016-09-141-0/+1
| | | | | | | It might be useful to actually handle this once copy propagation becomes smarter about register-misaligned offsets. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Don't spill non-GRF-aligned register regions.Francisco Jerez2016-09-142-2/+5
| | | | | | | | | | | A better fix would be to do something along the lines of the FS back-end spilling code and emit a scratch read before any instruction that overwrites the register to spill partially due to a non-zero sub-register offset. In the meantime mark registers used with a non-zero sub-register offset as no-spill to prevent the spilling code from miscompiling the program. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Fix copy propagation for non-register-aligned regions.Francisco Jerez2016-09-141-3/+6
| | | | | | | | | | | | | | This prevents it from trying to propagate a copy through a register-misaligned region. MOV instructions with a misaligned destination shouldn't be treated as a direct GRF copy, because they only define the destination GRFs partially. Also fix the interference check implemented with is_channel_updated() to consider overlapping regions with different register offset to interfere, since the writemask check implemented in the function is only valid under the assumption that the source and destination regions are aligned component by component. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Compare full register offsets in cmod propagation.Francisco Jerez2016-09-141-1/+1
| | | | | | | | | Cmod propagation would misoptimize the program if the destination offset of the generating instruction wasn't exactly the same as the source region offset of the copy instruction. In preparation for adding support for sub-GRF offsets to the VEC4 IR. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Assign correct destination offset to rewritten instruction in ↵Francisco Jerez2016-09-141-2/+1
| | | | | | | | | | | | register coalesce. Because the pass already checks that the destination offset of each 'scan_inst' that needs to be rewritten matches 'inst->src[0].offset' exactly, the final offset of the rewritten instruction is just the original destination offset of the copy. This is in preparation for adding support for sub-GRF offsets to the VEC4 IR. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Don't coalesce registers with overlapping writes not matching the ↵Francisco Jerez2016-09-141-4/+6
| | | | | | | | MOV source. In preparation for adding support for sub-GRF offsets to the VEC4 IR. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Compare full register offsets in opt_register_coalesce nop move ↵Francisco Jerez2016-09-141-1/+1
| | | | | | | | check. In preparation for adding support for sub-GRF offsets to the VEC4 IR. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Check that the write offsets match when setting dependency controls.Francisco Jerez2016-09-141-0/+2
| | | | | | | | | For simplicity just assume that two writes to the same GRF with different sub-GRF offsets will potentially interfere and break the dependency control chain. This is in preparation for adding sub-GRF offset support to the VEC4 IR. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Change opt_vector_float to keep track of the last offset seen in ↵Francisco Jerez2016-09-141-3/+3
| | | | | | | | | bytes. This simplifies things slightly and makes the pass more correct in presence of sub-GRF offsets. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Simplify src/dst_reg to brw_reg conversion by using byte_offset().Francisco Jerez2016-09-141-7/+8
| | | | | | | This should also have the side effect of fixing convert_to_hw_regs() to handle sub-GRF register offsets. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/ir: Update several stale comments.Francisco Jerez2016-09-145-26/+22
| | | | Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/ir: Don't print ARF subnr values twice.Francisco Jerez2016-09-142-8/+0
| | | | Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Print src/dst_reg::offset field consistently for all register files.Francisco Jerez2016-09-141-6/+15
| | | | | | | C.f. 'i965/fs: Print fs_reg::offset field consistently for all register files.'. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Print fs_reg::offset field consistently for all register files.Francisco Jerez2016-09-141-16/+22
| | | | | | | | | | | | The offset printing code in fs_visitor::dump_instruction() was doing things differently for sources and destinations and for each register file -- In some cases it would be added to the base register number fs_reg::nr, in other cases it would follow the base register separated with a plus sign, in other cases (uniforms) it would do both (!). The sub-register offset was also being printed or not rather inconsistently. Fix it. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Misc simplification.Francisco Jerez2016-09-144-6/+6
| | | | | | | Get rid of some leftover redundant arithmetic introduced during the conversion to byte offsets and sizes that can be simplified easily. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Get rid of fs_inst::set_smear().Francisco Jerez2016-09-143-32/+15
| | | | | | | | | | | | | | | | | | | component() was generally a better alternative because of several issues set_smear() had: - It wouldn't take the original stride and offset of the register into account, which means that set_smear() on the result of e.g. another set_smear() call or an offset() call would give a bogus region as result. - It was an inherently destructive operation. See the 'nir_intrinsic_shader_clock' hunk below for how this could lead to subtle bugs in cases where set_smear() was called multiple times on the same register like 'r.set_smear(0), r.set_smear(1)' with the expectation that each call would return a separate value instead of a reference to the same subsequently mutated object. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Use region_contained_in() in compute-to-mrf coalescing pass.Francisco Jerez2016-09-141-3/+2
| | | | Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Move region_contained_in to the IR header and fix for non-VGRF files.Francisco Jerez2016-09-142-14/+13
| | | | | | | Also changed the argument names since 'src' and 'dst' don't make that much sense outside of the context of copy propagation. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Change region_contained_in() to use byte units.Francisco Jerez2016-09-141-15/+10
| | | | | | | | | | | This makes the function less annoying to use and more accurate -- We shouldn't propagate a copy into a register region that wasn't fully contained in the destination of the copy (IOW, a source region that wasn't fully defined by the copy) just because the number of registers written and read by each instruction happened to get rounded up to the same GRF multiple. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Simplify copy propagation LOAD_PAYLOAD ACP setup.Francisco Jerez2016-09-141-3/+2
| | | | | | By keeping track of 'offset' in byte units. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Simplify a bunch of fs_inst::size_written calculations by using ↵Francisco Jerez2016-09-144-15/+19
| | | | | | | | | component_size(). Using component_size() is easier and generally more correct because it takes into account the register type and stride for you. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Simplify result_live calculation in dead_code_eliminate().Francisco Jerez2016-09-141-9/+3
| | | | | | No need to unroll the first iteration of the loop manually. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Simplify and fix buggy stride/offset calculations using subscript().Francisco Jerez2016-09-142-59/+17
| | | | | | | | | | | | | | | These were bashing the 'offset' and 'stride' values of several registers without taking the previous value into account, which probably didn't matter in practice for optimize_frontfacing_ternary() because the 'tmp' register already had a known region, but it would have given the wrong region as result in the other cases in lower_integer_multiplication(). subscript(..., i) is a more straightforward way to take the i-th field of a given type from each channel of a register which should give the right answer as result regardless of the original 'offset' and 'stride' parameters of the register region. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Simplify get_fpu_lowered_simd_width() by using inequalities instead ↵Francisco Jerez2016-09-141-2/+2
| | | | | | of rounding. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Simplify byte_offset().Francisco Jerez2016-09-141-8/+4
| | | | | | | | In the most common case this can now be implemented as a simple addition because the offset is already encoded as a single scalar value in bytes. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Fix signedness of the return value of fs_inst::size_read().Francisco Jerez2016-09-142-2/+2
| | | | Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Switch mask_relative_to() used in compute-to-mrf to byte units.Francisco Jerez2016-09-141-10/+10
| | | | | | | This makes the helper function less annoying to use and somewhat more accurate. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Fix bogus sub-MRF offset calculation in compute-to-mrf.Francisco Jerez2016-09-141-6/+6
| | | | | | | | | | | | The 'scan_inst->dst.offset % REG_SIZE' term in the final 'scan_inst->dst.offset' calculation is obviously bogus. The offset from the start of the copy destination register 'inst->dst' where the destination of the generating instruction 'scan_inst' would be written to (before compute-to-mrf runs) is just the offset of 'scan_inst->dst' relative to the source of the copy instruction (AKA rel_offset in the code below). Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Take into account copy register offset during compute-to-mrf.Francisco Jerez2016-09-141-1/+1
| | | | | | | | | This was dropping 'inst->dst.offset' on the floor. Nothing in the code above seems to guarantee that it's zero and in that case the offset of the register being coalesced into wouldn't be taken into account while rewriting the generating instruction. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Drop backend_reg::in_range() in favor of regions_overlap().Francisco Jerez2016-09-145-20/+12
| | | | | | | | | | This makes sure that overlap checks are done correctly throughout the back-end when the '*this' register starts before the register/size pair provided as argument, and is actually less annoying to use than in_range() at this point since regions_overlap() takes its size arguments in bytes. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/vec4: Port regions_overlap() to the vec4 IR.Francisco Jerez2016-09-141-4/+58
| | | | | | | | | | This is copy-pasted almost line by line from the FS back-end. The only reason it cannot be implemented in terms of backend_reg is that the backend_reg::nr field doesn't have the same meaning for uniforms on both back-ends. It could be easily deduplicated by using a template function. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Stop using fs_reg::in_range() in favor of regions_overlap().Francisco Jerez2016-09-141-1/+3
| | | | | | | | | | | Its only use left in the FS back-end should be using regions_overlap() instead to avoid getting a false negative result in cases where source and destination overlap but the former starts before the latter in the VGRF file. v2: Put back lost components factor (Iago). Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Drop fs_inst::overwrites_reg() in favor of regions_overlap().Francisco Jerez2016-09-147-14/+15
| | | | | | | | | | | fs_inst::overwrites_reg is rather easy to misuse because it cannot tell how large the register region starting at 'reg' is, so in cases where the destination region starts after 'reg' it may give a misleading result. regions_overlap() is somewhat more verbose to use but handles arbitrary overlap correctly so it should generally be used instead. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Fix LOAD_PAYLOAD handling in register coalesce is_nop_mov().Francisco Jerez2016-09-141-1/+3
| | | | | | | | | | | is_nop_mov() was broken for LOAD_PAYLOAD instructions in two ways: On the one hand the original destination register offset wasn't being taken into account which would give incorrect results if it was already non-zero, and on the other hand all source registers were being treated as if they had a size of 32B, which is almost never the case in SIMD16 programs for non-header sources. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Fix can_propagate_from() source/destination overlap check.Francisco Jerez2016-09-141-2/+2
| | | | | | | | | The previous overlap condition only made sure that the VGRF numbers or GRF-aligned offsets were different without taking the amount of data written and read by the instruction into consideration. Use the regions_overlap() helper instead. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Compare full register offsets in cmod propagation pass.Francisco Jerez2016-09-141-2/+1
| | | | | | | This could potentially have misoptimized a program in cases where inst->src[0] had a non-zero sub-GRF offset. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* i965/fs: Don't consider LOAD_PAYLOAD with stride > 1 source to behave like a ↵Francisco Jerez2016-09-141-1/+1
| | | | | | | | raw copy. Noticed the problem by inspection while typing in the previous commit. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
generated by cgit v1.1 at 2025-08-18 08:28:10 +0000