summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/gen8_ps_state.c
Commit message (Collapse)AuthorAgeFilesLines
* i965: Eliminate brw->wm.prog_data pointer.Kenneth Graunke2016-10-051-8/+10
| | | | | | | | | | | | Just say no to: - brw->wm.base.prog_data = &brw->wm.prog_data->base.base; We'll just use the brw_stage_prog_data pointer in brw_stage_state and downcast it to brw_wm_prog_data as needed. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Timothy Arceri <timothy.arcero@collabora.com>
* i965: Move BRW_NEW_FRAGMENT_PROGRAM from 3DSTATE_PS to PS_EXTRA.Kenneth Graunke2016-10-041-1/+1
| | | | | | | | | 3DSTATE_PS doesn't need this. 3DSTATE_PS_EXTRA however does, for brw_color_buffer_write_enabled(). Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* i965: Fix cross-primitive scratch corruption when changing the per-thread ↵Francisco Jerez2016-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | allocation. I haven't found any mention of this in the hardware docs, but experimentally what seems to be going on is that when the per-thread scratch slot size is changed between two pipelined draw calls, shader invocations using the old and new scratch size setting may end up being executed in parallel, causing their scratch offset calculations to be based in a different partitioning of the scratch space, which can cause their thread-local scratch space to overlap leading to cross-thread scratch corruption. I've been experimenting with alternative workarounds, like emitting a PIPE_CONTROL with DC flush and CS stall between draw (or dispatch compute) calls using different per-thread scratch allocation settings, or avoiding reuse of the scratch BO if the per-thread scratch allocation doesn't exactly match the original. Both seem to be as effective as this workaround, but they have potential performance implications, while this should be basically for free. Fixes over 40 failures in our CI system with spilling forced on (including CTS, dEQP and Piglit failures) on a number of different platforms from Gen4 to Gen9. The 'glsl-max-varyings' piglit test seems to be able to reproduce this bug consistently in the vertex shader on at least Gen4, Gen8 and Gen9 with spilling forced on. Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/ps_state: Use wm_prog_data.has_side_effectsJason Ekstrand2016-06-031-4/+3
| | | | | Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/fs: Organize prog_data by ksp number rather than SIMD widthJason Ekstrand2016-05-141-26/+11
| | | | | | | | | | The hardware packets organize kernel pointers and GRF start by slots that don't map directly to dispatch width. This means that all of the state setup code has to re-arrange the data from prog_data into these slots. This logic has been duplicated 4 times in the GL driver and one more time in the Vulkan driver. Let's just put it all in brw_fs.cpp. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/state: Clean up WM/PS state to pull more things out of prog_dataJason Ekstrand2016-05-141-15/+4
| | | | | | | | | Now that we have a persample_shading bit in prog_data we can reduce the amount the state setup code needs to be looking at the GL state. In particular, it no longer pulls anything directly out of the gl_fragment_program and no longer depends on NEW_FRAGMENT_PROGRAM. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/fs: Rework the persample shading key/prog_data bitsJason Ekstrand2016-05-141-14/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This commit reworks and simplifies the way we handle persample shading in the shader key and prog_data. The previous approach had three different key bits that had slightly different and hard-to-decern meanings while the new bits are far more clear. This commit changes it to two easily understood bits that communicate everything we need: 1) key->persample_interp: means that the user has requested persample interpolation through the API. This is equivalent to having SAMPLE_SHADING enabled and having MIN_SAMPLE_SHADING_VALUE set high enough that you actually get multiple per-sample invocations. 2) key->multisample_fbo: means that the shader will be running on an actual multi-sampled framebuffer. This commit also adds a new "persample_dispatch" bit to prog_data which indicates that the shader should be run in persample mode. This way the state setup code doesn't have to look at the fragment program or GL state and can just pull that data out of the prog_data. In theory, this shuffle could mean more recompiles. However, in practice, we were shoving enough state into the key before that we were probably hitting a recompile on every per-sample shader anyway. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Make all atoms to track BRW_NEW_BLORP by defaultKenneth Graunke2016-04-231-2/+5
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com
* i965: Whack UAV bit when FS discards and there are no color writes.Kenneth Graunke2016-03-281-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dEQP-GLES31.functional.fbo.no_attachments.* draws a quad with no framebuffer attachments, using a shader that discards based on gl_FragCoord. It uses occlusion queries to inspect whether pixels are rendered or not. Unfortunately, the hardware is not dispatching any pixel shaders, so discards never happen, and the full quad of pixels increments PS_DEPTH_COUNT, making the occlusion query results bogus. To understand why, we have to delve into the WM_INT internal signalling mechanism's formulas. The "WM_INT::Pixel Shader Kill Pixel" signal is defined as: 3DSTATE_WM::ForceKillPixel == ON || (3DSTATE_WM::ForceKillPixel != Off && !WM_INT::WM_HZ_OP && 3DSTATE_WM::EDSC_Mode != PREPS && (WM_INT::Depth Write Enable || WM_INT::Stencil Write Enable) && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (3DSTATE_PS_EXTRA::PixelShaderKillsPixels || 3DSTATE_PS_EXTRA:: oMask Present to RenderTarget || 3DSTATE_PS_BLEND::AlphaToCoverageEnable || 3DSTATE_PS_BLEND::AlphaTestEnable || 3DSTATE_WM_CHROMAKEY::ChromaKeyKillEnable)) Because there is no depth or stencil buffer, writes to those buffers are disabled. So the highlighted condition is false, making the whole "Kill Pixel" condition false. This then feeds into the following "WM_INT::ThreadDispatchEnable" condition: 3DSTATE_WM::ForceThreadDispatch != OFF && !WM_INT::WM_HZ_OP && 3DSTATE_PS_EXTRA::PixelShaderValid && (3DSTATE_PS_EXTRA::PixelShaderHasUAV || WM_INT::Pixel Shader Kill Pixel || WM_INT::RTIndependentRasterizationEnable || (!3DSTATE_PS_EXTRA::PixelShaderDoesNotWriteRT && 3DSTATE_PS_BLEND::HasWriteableRT) || (WM_INT::Pixel Shader Computed Depth Mode != PSCDEPTH_OFF && (WM_INT::Depth Test Enable || WM_INT::Depth Write Enable)) || (3DSTATE_PS_EXTRA::Computed Stencil && WM_INT::Stencil Test Enable) || (3DSTATE_WM::EDSC_Mode == 1 && (WM_INT::Depth Test Enable || WM_INT::Depth Write Enable || WM_INT::Stencil Test Enable))) Given that there's no depth/stencil testing, no writeable render target, and the hardware thinks kill pixel doesn't happen, all of these conditions are false. We have to whack some bit to make PS invocations happen. There are many options. Curro suggested using the UAV bit. There's some precedence in doing that - we set it for fragment shaders that do SSBO/image/atomic writes when no color buffer writes are enabled. We can simply include discard here too. Fixes 64 dEQP-GLES31.functional.fbo.no_attachments.* tests. v2: Add a comment suggested and written by Jason Ekstrand. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* i965/fs: Pass usage of depth, W, and sample mask through prog_dataJason Ekstrand2016-02-111-3/+6
| | | | | | | | | | We really need to stop pulling information directly out of shaders for state setup. For one thing, if we want any sort of an on-disk shader cache, having all of this metadata in one place is going to be crucial. Also, passing it all through prog_data cleans up the compiler <-> state setup API substantially. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Ensure FS execution in presence of atomic buffersIago Toral Quiroga2015-12-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | On Haswell we need to set the UAV_ONLY WM state bit when there are no colour or depth buffer writes and on all hardware we should set the early depth/stencil control field to PSEXEC unless early fragment tests are enabled to make sure that the fragment shader is executed regardless of whether per-fragment tests pass or not as the spec requires. So far we have been doing this for images only, but we should apply the same treatment to all side effectful scenarios. Suggested by Curro. This is not strictly required for compliance with the original ARB_shader_atomic_counters extension, it's only necessary to get the execution semantics specified in GL4.2+ right. v2: - Mark active_fs_has_side_effects as constant. (Curro) - Mention that this is only only necessary to get the execution semantics specified in GL4.2+ right. (Curro) Reviewed-by: Francisco Jerez <currojerez@riseup.net>
* mesa: Add a _mesa_active_fragment_shader_has_side_effects helperIago Toral Quiroga2015-12-221-2/+1
| | | | | | | | | | | | | | | Some drivers can disable the FS unit if there is nothing in the shader code that writes to an output (i.e. color, depth, etc). Right now, mesa has a function to check for atomic buffers and the i965 driver also checks for images. Refactor this logic into a generic function that we can use for any source of side effects in a fragment shader. Suggested by Jason. v2: - Use '_Shader', as suggested by Tapani, to fix the following CTS test: ES31-CTS.shader_atomic_counters.advanced-usage-many-draw-calls2 Reviewed-by: Francisco Jerez <currojerez@riseup.net>
* i965: remove trailing spaces in various filesIago Toral Quiroga2015-11-251-1/+1
| | | | Acked-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Implement ARB_shader_stencil_export (gen9+)Ben Widawsky2015-10-211-0/+5
| | | | | | | | | | | | | v2: remove useless source_stencil_to_render_target (Ken) Squash in the actual packing function, which also got to v2: Move the definition of the OPCODE outside of FB_WRITE opcodes (Matt) Reorder the regioning to be in VWH order (Matt) Don't retype src in the backend, just assert instead (Matt) Rename the debug prints to something better (Matt) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Don't tell the hardware about our UAV access.Francisco Jerez2015-10-091-3/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hardware documentation relating to the UAV HW-assisted coherency mechanism and UAV access enable bits is scarce and sometimes contradictory, and there's quite some guesswork behind this commit, so let me summarize the background first: HSW and later hardware have infrastructure to support a stricter form of data coherency between shader invocations from separate primitives. The mechanism is controlled by the "Accesses UAV" bits on 3DSTATE_VS, _HS, _DS, _GS and _PS (or _PS_EXTRA on BDW+), and the "UAV Coherency Required" bit on the 3DPRIMITIVE command. Regardless of whether "UAV Coherency Required" is set, the hardware fixed-function units will increment a per-stage semaphore for each request received if "Accesses UAV" is set for the same or any lower stage. An implicit DC flush is emitted by the lowermost stage with "Accesses UAV" set once it's done processing the request, this also happens regardless of the value of "UAV Coherency Required". The completion of the DC flush will cause the same stage and all previous ones to decrement the semaphore, marking the UAV accesses for the primitive as coherent with L3. The "UAV Coherency Required" 3DPRIMITIVE bit will cause a pipeline stall before any threads are dispatched for the first FF stage with "Accesses UAV" set until the semaphore is cleared for the same stage. Effectively this guarantees that UAV memory accesses performed by previous primitives from any stage will be strictly ordered (and thanks to the implicit DC flush visible in memory) with UAV accesses from the following primitives. None of this is required by the usual image, atomic counter and SSBO GL APIs which have very relaxed cross-primitive coherency and ordering requirements, so we don't actually ever set the "UAV Coherency Required" bit -- Ordering with respect to shader invocations from previous stages on the same primitive where there is a data dependency is of course already guaranteed as the spec requires, regardless of this mechanism being enabled. We do set the "Accesses UAV" bits though since my commit ac7664e493655e290783c23a0412b9c70936da50 (which this patch partially reverts), mainly because of comments like the following from the BDW PRM: > 3DSTATE_GS >[...] > 12 Accesses UAV > Format: Enable > This field must be set when GS has a UAV access. There are similar comments in the documentation for the other 3DSTATE_*S commands. The "must" part is misleading and unjustified AFAIK. Most of the "Accesses UAV" bits don't seem to have any side effects other than the implicit DC flushes and the related book-keeping in anticipation for a subsequent primitive with "UAV Coherency Required" set, so in most cases they are unnecessary and may incur a performance penalty. There is an exception though. On Gen8+ the PS_EXTRA UAV access bit influences the calculation of the PS UAV-only and ThreadDispatchEnable signals which on previous generations were set explicitly by the driver, so we cannot always avoid enabling it on the PS stage. The primary motivation for this change is that in fact the hardware coherency mechanism is buggy and will cause a rather non-deterministic hang on Gen8 when VS is the only stage with "Accesses UAV" set and the processing of a request terminates immediately after the implicit DC flush is sent for a previous primitive with no additional vertices being emitted for the second primitive, what will cause the hardware to skip sending a second DC flush and cause the VS to stall indefinitely waiting for a response from the DC (BDWGFX HSD 1912017). This hardware bug can be reproduced on current master with the spec@arb_shader_image_load_store@host-mem-barrier@Indirect/RaW piglit subtest (if you have the patience to run it a few dozen times). The proposed workaround is to insert CS STALLs speculatively between 3DPRIMITIVE commands when "Accesses UAV" is enabled for the VS stage only. Because this would affect one of the hottest paths in the driver and likely decrease performance even further due to the unnecessary serialization, and because we don't actually need the implicit DC flushes, it seems better to just disable them. Cc: 11.0 <mesa-stable@lists.freedesktop.org>
* i965/gen9: Annotate input coverage mask changeBen Widawsky2015-09-031-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | As far as I can tell, the behavior is preserved from the previous generations. Before we set a single bit to tell the FS whether or not we'll be using an input coverage mask. Now we have some options which are implementing various extensions. These bits are used for the various conservative rasterization mechanisms (for collision detection, binning, and whatever else). I believe that the behavior is preserved because the problem which conservative rasterization is attempting to fix would go away with the "NORMAL" mode (at the cost of performance, I believe). This patch serves as documentation of the change by creating the enums, as well as giving some of the history with the links here so that the next person who comes along and looks at it doesn't spend as long as I had to in order to determine if there is an issue or not. Previously, this algorithm had been done in software, and this can still be used as long as we don't export an extension stating otherwise. References: https://www.opengl.org/registry/specs/NV/conservative_raster.txt References: https://http.developer.nvidia.com/GPUGems2/gpugems2_chapter42.html Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/gen7-8: Set up early depth/stencil control appropriately for image ↵Francisco Jerez2015-08-111-0/+6
| | | | | | | | | load/store. v2: Store early fragment test mode in brw_wm_prog_data instead of getting it from core mesa data structures (Ken). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/gen7-8: Poke the 3DSTATE UAV access enable bits.Francisco Jerez2015-08-111-1/+2
| | | | | | v2: Set the PS UAV-only bit on HSW (Ken). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/skl: Set the pulls bary bit in 3DSTATE_PS_EXTRANeil Roberts2015-07-061-0/+3
| | | | | | | | | | | On Gen9+ there is a new bit in 3DSTATE_PS_EXTRA that must be set if the shader sends a message to the pixel interpolator. This fixes the interpolateAt* tests on SKL, apart from interpolateatsample-nonconst but that is not implemented anywhere so it's not a regression. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "10.6 10.5" <mesa-stable@lists.freedesktop.org>
* i965: execution of frag-shader when it has atomic bufferKevin Rogovin2015-06-171-0/+3
| | | | | | | | Ensure that the GPU spawns the fragment shader thread for those fragment shaders with atomic buffer access. Reviewed-by: Tapani Pälli <tapani.palli@intel.com> Signed-off-by: Kevin Rogovin <kevin.rogovin@intel.com>
* i965: Remove _NEW_MULTISAMPLE dirty bit from 3DSTATE_PS_EXTRA.Kenneth Graunke2015-05-271-2/+2
| | | | | | | BRW_NEW_NUM_SAMPLES is sufficient. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
* i965/ps/gen8: Refactor state uploadingTopi Pohjolainen2015-04-301-26/+46
| | | | | | | | | v2: Use SET_FIELD() for sampler count, and for that reason added GEN7_PS_SAMPLER_COUNT_MASK. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/ps: Use SET_FIELD() for sampler countTopi Pohjolainen2015-04-301-2/+3
| | | | | | | | The value is actually clamped to 0-16 as sample state pointer can be used to support more than 16 samplers. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/skl: Fix the maximum thread count format for the PSNeil Roberts2015-03-021-1/+6
| | | | | | | According to the bspec for some reason the format of the maximum number of threads field has changed from U8-2 to U8-1 for the PS. Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Store floating point mode choice in brw_stage_prog_data.Kenneth Graunke2014-12-041-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | We use IEEE mode for GLSL programs, but need to use ALT mode for ARB programs so that 0^0 == 1. The choice is based entirely on the shader source language. Previously, our code to determine which mode we wanted was duplicated in 8 different places (VS and FS for Gen4-5, Gen6, Gen7, and Gen8). The ctx->_Shader->CurrentProgram[stage] == NULL check was confusing as well - we use CurrentProgram (non-derived state), but _Shader (derived state). It also relies on knowing that ARB programs don't use gl_shader_program structures today. The compiler already makes this assumption in a few places, but I'd rather keep that assumption out of the state upload code. With this patch, we select the mode at compile time, and store that choice in prog_data. The state upload code simply uses that decision. This eliminates a BRW_NEW_*_PROGRAM dependency in the state upload code. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965: Make Gen4-5 and Gen8+ ALT checks use ctx->_Shader too.Kenneth Graunke2014-12-041-1/+1
| | | | | | | | | | | | | Commit c0347705 changed the Gen6-7 code to use ctx->_Shader rather than ctx->Shader, but neglected to change the Gen4-5 or Gen8+ code. This might fix SSO related bugs, but ALT mode is only used for ARB programs, so if there's an actual problem, it's likely no one would run into it. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965: Move PSCDEPTH calculations from draw time to compile time.Kenneth Graunke2014-12-041-17/+1
| | | | | | | | | | | | | | | The "Pixel Shader Computed Depth Mode" value is entirely based on the shader program, so we can easily do it at compile time. This avoids the if+switch on every 3DSTATE_WM (Gen7)/3DSTATE_PS_EXTRA (Gen8+) upload, and shares a bit more code. This also simplifies the PMA stall code, making it match the formula more closely, and drops a BRW_NEW_FRAGMENT_PROGRAM dependency. (Note that the previous comment was wrong - the code and the documentation have != PSCDEPTH_OFF, not ==.) Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965: Move BRW_NEW_*_PROG_DATA flags to .brw (not .cache).Kenneth Graunke2014-12-021-5/+5
| | | | | | | | | | | | | | | | | | | | | | I put the BRW_NEW_*_PROG_DATA flags at the beginning so that brw_state_cache.c can still continue using 1 << brw_cache_id. I also added a comment explaining the difference between BRW_NEW_*_PROG_DATA and BRW_NEW_*_PROGRAM, as it took me a long time to remember it. Non-mechanical changes: - brw_state_cache.c and brw_ff_gs.c now signal .brw, not .cache. - brw_state_upload.c - INTEL_DEBUG=state changes. - brw_context.h - bit definition merging. v2: Correct the explanation of BRW_NEW_*_PROG_DATA to mention state-based recompiles, and nix the "proper subset" claim, as it's false. (Caught by Kristian Høgsberg). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965: Rename CACHE_NEW_*_PROG to BRW_NEW_*_PROG_DATA.Kenneth Graunke2014-12-021-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we've moved a bunch of CACHE_NEW_* bits to BRW_NEW_*, the only ones that are left are legitimately related to the program cache. Yet, it seems a bit wasteful to have an entire bitfield for only 7 bits. State upload is one of the hottest paths in the driver. For each atom in the list, we call check_state() to see if it needs to be emitted. Currently, this involves comparing three separate bitfields (mesa, brw, and cache). Consolidating the brw and cache bitfields would save a small amount of CPU overhead per atom. Broadwell, for example, has 57 state atoms, so this small savings can add up. CACHE_NEW_*_PROG covers the brw_*_prog_data structures, as well as the offset into the program cache BO (prog_offset). Since most uses refer to brw_*_prog_data, I decided to use BRW_NEW_*_PROG_DATA as the name. Removing "cache" completely is a bit painful, so I decided to do it in several patches for easier review, and to separate mechanical changes from manual ones. This one simply renames things, and was made via: $ for file in *.[ch]; do sed -i -e 's/CACHE_NEW_\([A-Z_\*]*\)_PROG/BRW_NEW_\1_PROG_DATA/g' \ -e 's/BRW_NEW_WM_PROG_DATA/BRW_NEW_FS_PROG_DATA/g' $file done Note that BRW_NEW_*_PROG_DATA is still in .cache, not .brw! The next patch will remedy this flaw. It will also fix the alphabetization issues. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> Acked-by: Matt Turner <mattst88@gmail.com>
* i965: Alphabetize brw_tracked_state flags and use a consistent style.Kenneth Graunke2014-11-291-4/+7
| | | | | | | | | | | | | | | | Most of the dirty flags were listed in some arbitrary order. Some used bonus parenthesis. Some put multiple flags on one line, others put one per line. Some used tabs instead of spaces...but only on some lines. This patch settles on one flag per line, in alphabetical order, using spaces instead of tabs, and sheds the unnecessary parentheses. Sorting was mostly done with vim's visual block feature and !sort, although I alphabetized short lists by hand; it was pretty manual. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965: Use brw_wm_prog_data::uses_kill, not gl_fragment_program::UsesKillKenneth Graunke2014-11-271-1/+1
| | | | | | Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965: Create prog_data temporary variables in PS state upload code.Kenneth Graunke2014-11-271-16/+19
| | | | | | | | | prog_data->foo is a bit more readable than brw->wm.prog_data->foo. The local variable definition is also a great location to put the obligatory /* CACHE_NEW_WM_PROG */ comment. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* i965: Fix missing CACHE_NEW_WM_PROG in 3DSTATE_PS_EXTRA.Kenneth Graunke2014-11-271-2/+2
| | | | | | | | | | | | brw->wm.prog_data is covered by CACHE_NEW_WM_PROG, not BRW_NEW_FRAGMENT_PROGRAM. So, we should listen to it. However, I believe that BRW_NEW_FRAGMENT_PROGRAM is sufficient to cover all the necessary cases - CACHE_NEW_WM_PROG happens in a subset of cases. So, the code being wrong shouldn't have triggered bugs. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* i965: Move curb_read_length/total_scratch to brw_stage_prog_data.Kenneth Graunke2014-09-031-2/+2
| | | | | | | | All shader stages have these fields, so it makes sense to store them in the common base structure, rather than duplicating them in each. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* i965: Provide a context flag to let us enable fast clearKristian Høgsberg2014-08-151-0/+2
| | | | | | | | | GEN7+ has the fast clear functionality, which lets us clear the color buffers using the MCS and a scaled down rectangle. To enable this we have to set the appropriate bits in the 3DSTATE_PS package. Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Add an option to not generate the SIMD8 fragment shaderKristian Høgsberg2014-08-151-2/+2
| | | | | | | | | For now, this can only be triggered with a new 'no8' INTEL_DEBUG option and a new context flag. We'll use the context flag later, but introducing it now lets us bisect to this commit if it breaks something. Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Assign PS kernel start pointers when we decide which kernels to useKristian Høgsberg2014-08-141-6/+8
| | | | | | | | | | | Right now we decide which kernels to use and the GRF start offsets in one place and emit the kernel pointers later. The logic of how to map 8, 16 and 32 kernels to kernel start pointers follows the same logic as which GRF start offsets to use, so lets figure out these two things in one place. Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
* i965: Move dispatch_grf_start_reg and first_curbe_grf into stage_prog_data.Eric Anholt2014-07-021-4/+4
| | | | | | | I wanted to access this value from stage-generic code, so stop storing it under two different names. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Move push constant state packets to push constant update time.Eric Anholt2014-05-021-6/+2
| | | | | | | -0.553779% +/- 0.423394% effect on cairo-perf-trace runtime on glamor (n=612) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Merge gen8_upload_constant_state into gen7_upload_constant_state.Eric Anholt2014-05-021-1/+1
| | | | | | | The two paths are really similar, and the extra conditionals will be dwarfed by the cost of the actual upload. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Drop unnecessary state flag for units on NEW_BINDING_TABLE.Eric Anholt2014-05-021-1/+0
| | | | | | | | | | | Commit 30259856a8a82a55c030df1ad052e505c61144bc moved the state packets to table generation time, but forgot to make this change. Apparently the performance win there was about not reemitting the table pointers on unrelated state changes. No performance difference on cairo on glamor (n=118). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/gen7+: Move sampler state packets to the stage sampler state table update.Eric Anholt2014-05-021-7/+1
| | | | | | | | | | | | Now that we have the stage state coming into our setup of sampler states, it's easy to drop an identifier into it of which stage the stage_state is, and then look up which packet to emit in a little table. No performance difference on cairo on glamor (n=492). v2: Don't forget to do the workaround flush on IVB. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Drop a NEW_SAMPLER annotation for use of sampler_count.Eric Anholt2014-05-021-1/+0
| | | | | | | The sampler count is set up from the gl_program at draw time, not at sampler change time. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Track the number of samples in the drawbuffer.Eric Anholt2014-04-301-4/+4
| | | | | | | | | This keeps us from having to emit the nonpipelined state packet on every FBO binding. -4.42003% +/- 1.09961% effect on cairo-perf-trace runtime on glamor (n=110). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Move binding table update packets to binding table setup time.Eric Anholt2014-03-101-6/+0
| | | | | | | | | | | | | | | | | | | This keeps us from needing to reemit all the other stage state just because a surface changed. Improves unoptimized glamor x11perf -f8text by 1.10201% +/- 0.489869% (n=296). [v1] v2: - Drop binding table packets from Gen8 unit state as well. - Pass _3DSTATE_BINDING_TABLE_POINTERS_XS to brw_upload_binding_table, cutting even more code. v3: Don't forget to drop them from 3DSTATE_GS (botched refactor in v2). Signed-off-by: Eric Anholt <eric@anholt.net> [v1] Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1] Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> [v2, v3] Reviewed-by: Eric Anholt <eric@anholt.net> [v3]
* i965: Store absolute thread count in max_wm_threads on Broadwell.Kenneth Graunke2014-02-201-1/+4
| | | | | | | | | | | | | | | | | | In the past, 3DSTATE_PS took an absolute number of threads. Conversely, on Broadwell you always program 64, and it implicitly scales based on the GT-level with no special programming. So, I stored 64 in brw_device_info::max_wm_threads. However, I didn't realize that we also use max_wm_threads to compute the size of the scratch space buffer. In that case, we really need the absolute number of threads. This patch hardcodes 3DSTATE_PS to use the value it expects, and changes max_wm_threads back to a (completely fake) absolute thread count (once again copied from Haswell). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
* i965: Only use the SIMD16 program for per-sample shading on Broadwell.Kenneth Graunke2014-02-191-9/+32
| | | | | | | | | | | | This restriction carries forward from earlier platforms. The code is ported straight from gen7_wm_state.c. v2: Actually do it right. v3: Add missing _NEW_MULTISAMPLE bit (caught by Eric). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Set "Position XY Offset Select" bits in 3DSTATE_PS on Broadwell.Kenneth Graunke2014-02-191-0/+18
| | | | | | Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Add missing sample shading bits to Gen8's 3DSTATE_PS_EXTRA.Kenneth Graunke2014-02-191-1/+15
| | | | | | | | | | | | v2: Also set the "oMask Present to Render Target" bit, which is required for shaders that write oMask. Otherwise the hardware won't expect the extra data. v3: Add missing _NEW_MULTISAMPLE (caught by Eric). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Move up duplicated fields from stage-specific prog_data to ↵Francisco Jerez2014-02-191-1/+1
| | | | | | | | | | | | | brw_stage_prog_data. There doesn't seem to be any reason for nr_params, nr_pull_params, param, and pull_param to be duplicated in the stage-specific subclasses of brw_stage_prog_data. Moving their definition to the common base class will allow some code sharing in a future commit, the removal of brw_vec4_prog_data_compare and brw_*_prog_data_free, and the simplification of the stage-specific brw_*_prog_data_compare. Reviewed-by: Paul Berry <stereotype441@gmail.com>
generated by cgit v1.1 at 2024-06-03 09:10:31 +0000