aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* i965/vec4: Send from GRF in atomic operations.Matt Turner2015-11-031-12/+18
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add scalar geometry shader support.Kenneth Graunke2015-11-035-24/+666
| | | | | | | | | | | | | | | | | | | | This is hidden behind INTEL_SCALAR_GS=1 for now, as we don't yet support instanced geometry shaders, and Orbital Explorer's shader spills like crazy. But the infrastructure is in place, and it's largely working. v2: Lots of rebasing. v3: (feedback from Kristian Høgsberg) - Handle stride and subreg_offset correctly for ATTRs; use a helper. - Fix missing emit_shader_time_end() call. - Delete dead code after early EOT in static vertex case to avoid tripping asserts in emit_shader_time_end(). - Use proper D/UD type in intexp2(). - Fix "EndPrimitve" and "to that" typos. - Assert that invocations == 1 so we know this is missing. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* i965: Add scalar GS input lowering code.Kenneth Graunke2015-11-031-5/+39
| | | | | | | | | We really ought to compute the VUE map at link time and stash it, rather than recomputing it here, but with the mess of program structures I wasn't sure where to put it. We can improve that later. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* i965: Fix the fs_visitor GS constructor to take shader_time_index.Kenneth Graunke2015-11-032-3/+5
| | | | | | | | Jason reworked this so it isn't simply ST_GS anymore...it's either -1 (not enabled) or an actual offset. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* i965/gen8+: Extract color clear surface stateBen Widawsky2015-11-031-6/+15
| | | | | | | | | | | | | | On future generation platforms the color clear value is stored elsewhere in the surface state. By extracting this logic, we can cleanly implement the difference in an upcoming patch. Should have no functional impact. v2: Move hunk from the next patch into this patch (Matt) Whitespace fix (Ben) Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Neil Roberts <[email protected]>
* i965/gen8+: Remove redundant zeroing of surface stateBen Widawsky2015-11-031-12/+0
| | | | | | | | | | | | | | The allocate_surface_state already zeroes out the surface state, and doing it later in the function is destructive for what we want to accomplish when we split out support for gen9 fast clears (next patch). NOTE: Only dword 12 actually needed to be fixed, but it seemed more consistent to remove the other instances as well. I can make an argument both ways (open coding it, vs. not). I can rework the next patch if requires. Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Neil Roberts <[email protected]>
* i965/skl: Add GT4 PCI IDsBen Widawsky2015-11-031-1/+5
| | | | | | | | | | | | | | | | | | | | Like other gen8+ hardware, the hardware automatically scales up thread counts. We must be careful about the URB sizes since GT4 adds another slice. One of the existing PCI IDs is actually mislabeled as GT3. Arguably this is a real bug since the URB size will be wrong. Because this patch is simply meant to add the missing IDs, that will be fixed in a later patch. v2: No longer relevant. v3: Update the wm thread count to support GT4. The WM thread count is used to determine the maximum scratch space required. Currently the code always allocates the maximum amount even though lower GT SKUs require less. The formula is threads_per_psd * subslices_per_slice * slices Cc: [email protected] Reviewed-by: Jordan Justen <[email protected]> Signed-off-by: Ben Widawsky <[email protected]>
* i965/fs: Clean up FBH code.Matt Turner2015-11-021-4/+3
| | | | Reviewed-by: Ian Romanick <[email protected]>
* i965/vec4: Clean up FBH code.Matt Turner2015-11-021-13/+5
| | | | | | It did a bunch of unnecessary stuff, emitting an extra MOV included. Reviewed-by: Ian Romanick <[email protected]>
* i965: Replace default case with list of enum values.Matt Turner2015-11-025-26/+29
| | | | | | | If we add a new file type, we'd like to get warnings if it's not handled. Reviewed-by: Ian Romanick <[email protected]>
* i965/vec4: Don't disable channels in any/all comparisons.Matt Turner2015-11-021-42/+10
| | | | | | | | | | | | | | | | | | | | | | We've made a mistake in calling the Channel Enable bits "writemask", because they do more than control which channels of the destination are written -- they actually control which channels are enabled (surprise! surprise!) So, if we emit cmp.z.f0(8) null.xy<1>D g10<4,4,1>.xyzzD g2<0,4,1>.xyzzD mov(8) g12<1>.xUD 0x00000000UD (+f0.all4h) mov(8) g12<1>.xUD 0xffffffffUD where the CMP instruction has only .xy channel enables, it won't write the .zw channels of the flag register, which are of course read by the +f0.all4 predicate. We need to always emit CMP instructions whose flag result might be read by such a predicate with all channels enabled. Reviewed-by: Jason Ekstrand <[email protected]>
* nouveau: set MaxDrawBuffers to the same value as MaxColorAttachmentsIlia Mirkin2015-11-011-1/+1
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected]
* i965: Setup pull constant state for compute programsJordan Justen2015-11-014-1/+35
| | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965/sched: don't calculate live intervals for post-RA schedulingConnor Abbott2015-10-311-1/+2
| | | | | | | | | | | For some reason, this causes assertions on gm965 only. In any case, it's unnecessary since we don't need liveness information in the post-RA scheduler. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92744 Cc: Mark Janes <[email protected]> Signed-off-by: Connor Abbott <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Do legacy userclipping in OpenGL ES 1.x contexts.Ian Romanick2015-10-301-1/+2
| | | | | | | | | | | | | | | Commit fba4823a disabled user clipping for everything except compatibility profile. Core profile and OpenGL ES 2.0+ have all removed the classic, OpenGL 1.0 user clip planes. ES 1.x, however, still has them. Fixes OpenGL ES 1.1 conformance mustpass.c and userclip.c Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Tested-by: Olivier Berthier <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92639 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92641
* i965: enable ARB_shader_clock on gen7+Emil Velikov2015-10-301-0/+1
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Implement nir_intrinsic_shader_clockEmil Velikov2015-10-302-0/+19
| | | | | | | | | | | | | | | v2: - Add a few const qualifiers for good measure. - Drop unneeded retype()s (Matt) - Convert timestamp to SIMD8/16, as fs_visitor::get_timestamp() returns SIMD4 (Connor) v3: - Remove unneeded temporary + MOV (Connor) Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Connor Abbott <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/fs: move the fs_reg::smear() from get_timestamp() to the callersEmil Velikov2015-10-301-12/+17
| | | | | | | | | | | | | We're about to reuse get_timestamp() for the nir_intrinsic_shader_clock. In the latter the generalisation does not apply, so move the smear() where needed. This also makes the function analogous to the vec4 one. v2: Tweak the comment - The caller -> We (Matt, Connor). v3: More comment tweaks (Connor) Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Connor Abbott <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Fix invalid memory accesses after resizing brw_codegen's store tableKristian Høgsberg2015-10-301-4/+13
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965/sched: use liveness analysis for computing register pressureConnor Abbott2015-10-301-56/+229
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we were using some heuristics to try and detect when a write was about to begin a live range, or when a read was about to end a live range. We never used the liveness analysis information used by the register allocator, though, which meant that the scheduler's and the allocator's ideas of when a live range began and ended were different. Not only did this make our estimate of the register pressure benefit of scheduling an instruction wrong in some cases, but it was preventing us from knowing the actual register pressure when scheduling each instruction, which we want to have in order to switch to register pressure scheduling only when the register pressure is too high. This commit rewrites the register pressure tracking code to use the same model as our register allocator currently uses. We use the results of liveness analysis, as well as the compute_payload_ranges() function that we split out in the last commit. This means that we compute live ranges twice on each round through the register allocator, although we could speed it up by only recomputing the ranges and not the live in/live out sets after scheduling, since we only shuffle around instructions within a single basic block when we schedule. Shader-db results on bdw: total instructions in shared programs: 7130187 -> 7129880 (-0.00%) instructions in affected programs: 1744 -> 1437 (-17.60%) helped: 1 HURT: 1 total cycles in shared programs: 172535126 -> 172473226 (-0.04%) cycles in affected programs: 11338636 -> 11276736 (-0.55%) helped: 876 HURT: 873 LOST: 8 GAINED: 0 v2: use regs_read() in more places. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: split out calculation of payload live rangesConnor Abbott2015-10-302-22/+31
| | | | | | | | We'll need this for the scheduler too, since it wants to know when the live ranges of payload registers end in order to model them in our register pressure calculations. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: dump scheduling cycle estimatesConnor Abbott2015-10-304-10/+36
| | | | | | | | | | | | | The heuristic we're using is rather lame, since it assumes everything is non-uniform and loops execute 10 times, but it should be enough for measuring improvements in the scheduler that don't result in a change in the number of instructions. v2: - Switch loops and cycle counts to be compatible with older shader-db. - Make loop heuristic 10x to match with spilling code. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: always run the post-RA schedulerConnor Abbott2015-10-301-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before, we would only do scheduling after register allocation if we spilled, despite the fact that the pre-RA scheduler was only supposed to be for register pressure and set the latencies of every instruction to 1. This meant that unless we spilled, which we rarely do, then we never considered instruction latencies at all, and we usually never bothered to try and hide texture fetch latency. Although a later commit removes the setting the latency to 1 part, we still want to always run the post-RA scheduler since it's able to take the false dependencies that the register allocator creates into account, and it can be more aggressive than the pre-RA scheduler since it doesn't have to worry about register pressure at all. Test master post-ra-sched diff %diff bench_OglPSBump2 396.730 402.386 5.656 +1.400% bench_OglPSBump8 244.370 247.591 3.221 +1.300% bench_OglPSPhong 241.117 242.002 0.885 +0.300% bench_OglPSPom 59.555 59.725 0.170 +0.200% bench_OglShMapPcf 86.149 102.346 16.197 +18.800% bench_OglVSTangent 388.849 395.489 6.640 +1.700% bench_trex 65.471 65.862 0.390 +0.500% bench_trexoff 69.562 70.150 0.588 +0.800% bench_heaven 25.179 25.254 0.074 +0.200% Reviewed-by: Jason Ekstrand <[email protected]>
* i965/sched: write-after-read dependencies are freeConnor Abbott2015-10-301-5/+5
| | | | | | | | | | | | Although write-after-write dependencies have the same latency as read-after-write dependencies due to how the register scoreboard works, write-after-read dependencies aren't checked by the EU at all, so they're purely a constraint on how the scheduler can order the instructions. v2: fix accumulator dependencies too. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: fix cycle estimates when there's a pipeline stallConnor Abbott2015-10-301-7/+8
| | | | | | | | | | | | The issue time for an instruction is how many cycles it takes to actually put it into the pipeline. If there's a pipeline stall that causes the instruction to be delayed, we should first take that into account to figure out when the instruction would start executing and *then* add the issue time. The old code had it backwards, and so we would underestimate the total time whenever we thought there would be a pipeline stall by up to the issue time of the instruction. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Add INTEL_DEBUG=nocompact to disable instruction compaction.Matt Turner2015-10-293-0/+5
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add INTEL_DEBUG=hex to print the hex with the disassembly.Matt Turner2015-10-293-1/+3
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Print the type and writemask on null destinations.Matt Turner2015-10-291-1/+1
| | | | | | | | These are often useful in debugging, and the writemask (actually "Channel Enables") determines more than just what goes into the destination. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Test fixed_hw_reg.file against BRW_IMMEDIATE_VALUE, not IMM.Matt Turner2015-10-291-4/+4
| | | | | | | | No functional change, since they were both 3, but BRW_IMMEDIATE_VALUE is the hardware value and IMM was the IR value -- and you can see that BRW_IMMEDIATE_VALUE was correctly used in the context of this patch. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Test against BRW_IMMEDIATE_VALUE, not IMM.Matt Turner2015-10-291-1/+1
| | | | | | | | No functional change, since they were both 3, but BRW_IMMEDIATE_VALUE is the hardware value and IMM was the IR value -- and you can see that BRW_IMMEDIATE_VALUE was correctly used in the context of this patch. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Use group(4, 0) to emit an exec-size 4 MOV.Matt Turner2015-10-291-2/+3
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/cfg: Handle no-idom case in cfg_t::dump_domtree().Matt Turner2015-10-291-1/+3
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/disasm: Remove unused _addr_mode argument from src_ia1().Matt Turner2015-10-291-3/+0
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Set correct field for indirect align16 addrimm.Matt Turner2015-10-291-1/+1
| | | | | | This has been wrong since the initial import of the i965 driver. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Drop brw_set_default_* before popping insn state.Matt Turner2015-10-291-3/+0
| | | | | Reviewed-by: Ben Widawsky <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Remove unnecessary #includes from the generator.Matt Turner2015-10-291-8/+0
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965/vec4: Eliminate the vec4_generator class altogether.Kenneth Graunke2015-10-291-284/+180
| | | | | | | | | | We really weren't taking advantage of vec4_generator being a class. By adding a "p" parameter to the helper methods, and "prog_data" to ones which need binding table information, we can convert everything to static functions. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Move vec4_generator class definition into the .cpp file.Kenneth Graunke2015-10-292-111/+110
| | | | | | | | | The public API for the generator is brw_vec4_generate_code(); nobody actually needs to use the class. This means we can extend it without triggering the recompiles associated with altering brw_vec4.h. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Wrap vec4_generator in a C function.Kenneth Graunke2015-10-294-9/+37
| | | | | | | | | vec4_generator is a class for convenience, but only exports a single method as its public API. It makes much more sense to just export a single function. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Convert src_reg/dst_reg to brw_reg at the end of the visitor.Kenneth Graunke2015-10-294-110/+92
| | | | | | | | | | | | | | | | | This patch makes the visitor convert registers to the HW_REG file at the very end, after register allocation, post-RA scheduling, and dependency control flagging. After that, everything is in fixed brw_regs. This simplifies the code generator, as it can just use the hardware registers rather than having to interpret our abstract files. In particular, interpreting the UNIFORM file meant reading prog_data to figure out where push constants are supposed to start. Having the part of the code that performs register allocation also translate everything to hardware registers seems sensible. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Implement ARB_fragment_layer_viewport.Kenneth Graunke2015-10-284-1/+46
| | | | | | | | | | | | | | Normally, we could read gl_Layer from bits 26:16 of R0.0. However, the specification requires that bogus out-of-range 32-bit values written by previous stages need to appear in the fragment shader as-written. Instead, we pass in the full 32-bit value from the VUE header as an extra flat-shaded varying. We have the SF override the value to 0 when the previous stage didn't actually write a value (it's actually defined to return 0). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Make calculate_attr_overrides return the URB read offset.Kenneth Graunke2015-10-284-10/+17
| | | | | | | | | | | | Traditionally, we've hardcoded "URB Entry Read Offset" to 1 (which represents 2 vec4 varying slots) to skip over the 8 DWord VUE header. In order to support ARB_fragment_layer_viewport, we'll need to read from that header. This patch adds the basic plumbing necessary to calculate a value dynamically and hook it up in the SBE packets. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965/fs: Properly check for PAD in fragment shaders with > 16 varyings.Kenneth Graunke2015-10-281-4/+1
| | | | | | | | | | | | | | Commit 268008f98c3810b9f276df985dc93efc0c49f33e changed unused VUE map slots to be initialized with BRW_VARYING_SLOT_PAD, not COUNT. I missed updating this. It also means that commit message was wrong, as some code *did* rely slots being initialized to COUNT. This may fix a bug with SSO programs with > 16 FS input varyings. I think we probably just emitted extra pointless code, but probably didn't break anything. We might also just have no tests for that. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Update stale comment about unused VUE map slots.Kenneth Graunke2015-10-281-3/+1
| | | | | | | I changed this from COUNT to PAD in commit 268008f98c3810b9f276df985dc93ef. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Fix missing BRW_NEW_*_PROG_DATA flagging caused by cache reuse.Kenneth Graunke2015-10-282-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the case of two nearly identical GLSL fragment shaders: out vec4 color; void main() { color = vec4(1); } and layout(early_fragment_tests) in; out vec4 color; void main() { color = vec4(1); } These shaders compile to the exact same assembly, but have distinct values for brw_wm_prog_data::early_fragment_tests. Since these are two independent GLSL shaders, they have different program keys - notably, brw_wm_prog_key::program_string_id differs. When uploading the second, brw_upload_cache will find an existing copy of the assembly in the cache BO, which means matching_data will be non-NULL. Although we create a second cache item (with the new key and prog_data), we set item->offset to the existing copy and avoid re-uploading duplicate assembly. However, brw_search_cache() would only flag BRW_NEW_*_PROG_DATA if item->offset differed from the supplied offset. With reuse, both programs have the same offset, but prog_data changed. We have to flag it, but failed to. To fix this, we simply need to check if the aux (prog_data) pointer changed. If either the assembly or the prog_data differs, flag it. This fixes a regression since 1bba29ed403e735ba0bf04ed8aa2e571884f, where Topi fixed brw_upload_cache() to actually reuse identical assembly. Prior to that, reuse basically never happened due to bugs. Unfortunately, this code apparently wasn't prepared to handle reuse! Fixes GPU hangs in Dolphin on Broadwell. Huge thanks to Pierre Bourdon and Ilia Mirkin for debugging this and helping track down the real issue. Cc: "11.0" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92623 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Tested-by: Pierre Bourdon <[email protected]>
* i965: remove unneeded src_reg copy in emit_shader_time_writeEmil Velikov2015-10-281-1/+1
| | | | | | | | The variable is already of type src_reg. creating a new instance only to destroy it seems unnecessary. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: remove cache_aux_free_func arrayEmil Velikov2015-10-282-12/+5
| | | | | | | | | | | | There is only one function that can be called, which is well known at compilation time. The abstraction used here seems unnecessary, so let's use a direct call to brw_stage_prog_data_free() when appropriate, cut down the size of struct brw_cache. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add missing close-parenthesis in error messagesIan Romanick2015-10-261-2/+2
| | | | | | Trivial. Signed-off-by: Ian Romanick <[email protected]>
* i965: Fix is-renderable check in intel_image_target_renderbuffer_storageIan Romanick2015-10-261-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | Previously we could create a renderbuffer with format MESA_FORMAT_R8G8B8A8_UNORM, convert that renderbuffer to an EGLImage, then FAIL to convert the EGLImage back to a renderbuffer because reasons. Just use the same check in intel_image_target_renderbuffer_storage that brw_render_target_supported uses. There are more checks in brw_render_target_supported, but I don't think they are necessary here. A different approach would be to refactor brw_render_target_supported to take rb->Format and rb->NumSamples as parameters (instead of a gl_renderbuffer) and use the new function here. Fixes: ES2-CTS.gtf.GL2ExtensionTests.egl_image.egl_image Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Tested-by: Tapani Pälli <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92476 Cc: "10.3 10.4 10.5 10.6 11.0" <[email protected]>
* glsl: keep track of intra-stage indices for atomicsTimothy Arceri2015-10-276-27/+30
| | | | | | | | | | | | | | | This is more optimal as it means we no longer have to upload the same set of ABO surfaces to all stages in the program. This also fixes a bug where since commit c0cd5b var->data.binding was being used as a replacement for atomic buffer index, but they don't have to be the same value they just happened to end up the same when binding is 0. Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]> Cc: Ilia Mirkin <[email protected]> Cc: Alejandro Piñeiro <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90175
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-05 00:46:18 +0000