summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* Remove useless checks for NULL before freeingMatt Turner2014-12-082-7/+3
| | | | | | | See commits 5067506e and b6109de3 for the Coccinelle script. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/skl: Add Skylake PCI IDsKristian Høgsberg2014-12-081-0/+29
| | | | Signed-off-by: Kristian Høgsberg <[email protected]>
* i965/skl: Emit depth stall workaround for gen9 as wellDamien Lespiau2014-12-081-1/+1
| | | | | | | | | | The docs say that we shouldn't need this workaround for gen8+, but just removing it, causes gpu hangs. We'll revisit this, but for now, just extend the workaround to gen9. Signed-off-by: Damien Lespiau <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* i965/skl: Fix GS thread count locationBen Widawsky2014-12-081-11/+18
| | | | | | | | | | SKL moves the GS threadcount to dw8 from dw7, and no longer does the divide by 2 thing. Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Tested-by: Kristian Høgsberg <[email protected]>
* i965: Fix union usage for G++ <= 4.6.Vinson Lee2014-12-081-1/+2
| | | | | | | | | | | | This patch fixes this build error with G++ <= 4.6. CXX test_vf_float_conversions.o test_vf_float_conversions.cpp: In function ‘unsigned int f2u(float)’: test_vf_float_conversions.cpp:63:20: error: expected primary-expression before ‘.’ token Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86939 Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* st/mesa: For vertex shaders, don't emit saturate when SM 3.0 is unsupportedAbdiel Janulgue2014-12-082-4/+3
| | | | | | | | | | | There is a bug in the current lowering pass implementation where we lower saturate to clamp only for vertex shaders on drivers supporting SM 3.0. The correct behavior is to actually lower to clamp only when we don't support saturate which happens on drivers that don't support SM 3.0 Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Abdiel Janulgue <[email protected]>
* glsl: Don't optimize min/max into saturate when EmitNoSat is setAbdiel Janulgue2014-12-081-0/+1
| | | | | | | v3: Fix multi-line comment format (Ian) Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Abdiel Janulgue <[email protected]>
* ir_to_mesa: Remove sat to clamp lowering passAbdiel Janulgue2014-12-081-3/+1
| | | | | | | | | | | | | | | Fixes an infinite loop in swrast where the lowering pass unpacks saturate into clamp but the opt_algebraic pass tries to do the opposite. v3 (Ian): This is a revert of commit cfa8c1cb "ir_to_mesa: lower ir_unop_saturate" on the ir_to_mesa.cpp portion. prog_execute.c can handle saturates in vertex shaders, so classic swrast shouldn't need this lowering pass. Cc: "10.4" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83463 Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Abdiel Janulgue <[email protected]>
* i965: Remove default from brw_instruction_name switch to catch missing names.Matt Turner2014-12-081-12/+5
| | | | | | | The case-range extension is available in clang and gcc at least back to 3.4.0. Signed-off-by: Chris Forbes <[email protected]>
* i965: Add missing opcode names.Matt Turner2014-12-081-0/+9
| | | | Signed-off-by: Chris Forbes <[email protected]>
* i965: Add opcode names for set_omask and set_sample_id.Matt Turner2014-12-081-0/+4
| | | | Reviewed-by: Chris Forbes <[email protected]>
* i965/Gen6-7: Fix point sprites with PolygonMode(GL_POINT)Chris Forbes2014-12-071-0/+6
| | | | | | | | | | | | | | | | | This was an oversight in the original patch. When PolygonMode is used, then front faces, back faces, or both may be rendered as points and are affected by point sprite state. Note that SNB/IVB can't actually be fully conformant here, for a legacy context -- we don't have separate sets of pointsprite enables for front and back faces. Haswell ignores pointsprite state correctly in hardware for non-point rasterization, so can do this correctly, but it doesn't seem worth it. Signed-off-by: Chris Forbes <[email protected]> Cc: "10.4" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86764 Reviewed-by: Matt Turner <[email protected]>
* i965: Fix regs read for FS_OPCODE_INTERP_PER_SLOT_OFFSETChris Forbes2014-12-071-0/+2
| | | | | | | | | | Dead code elimination was eating the Y offset. Fixes the piglit test: spec/ARB_gpu_shader5/arb_gpu_shader5-interpolateAtOffset-nonconst Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Add opcode names for FS interpolation opcodesChris Forbes2014-12-071-0/+9
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* mesa/st: don't use CMP / I2F for conditional assignments with native integersRoland Scheidegger2014-12-061-17/+45
| | | | | | | | | | | | | | | | | | | The original idea was to optimize away the condition by integrating it directly into the CMP instruction. However, with native integers this requires an extra I2F instruction. It is also fishy because the negation used didn't really honor ieee754 float comparison rules, not to mention the CMP instruction itself (being pretty much a legacy instruction) doesn't really have defined special float value behavior in any case. So, use UCMP and adjust the code trying to optimize the condition away accordingly (I have absolutely no idea if such conditions are actually hit or would be translated away somewhere else already). v2: cosmetic changes No piglit regressions on llvmpipe. Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965/fs: Perform CSE on MOV ..., VF instructions.Matt Turner2014-12-051-5/+11
| | | | | | | | | | | Safe from causing optimization loops, since we don't constant propagate VF arguments. (for this and the previous patch): total instructions in shared programs: 4289075 -> 4271932 (-0.40%) instructions in affected programs: 1616779 -> 1599636 (-1.06%) Reviewed-by: Ian Romanick <[email protected]>
* i965/fs: Try to emit LINE instructions on Gen <= 5.Matt Turner2014-12-052-0/+56
| | | | | | | | | | | | | The LINE instruction performs a multiply-add instruction (a * b + c) where b and c are scalar arguments. It reads b and c from offsets in src0 such that you can load them (it they're representable) as a vector-float immediate with a single instruction. Hurts some programs, but that'll all get better once we CSE the vector-float MOVs in the next patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77544 Reviewed-by: Ian Romanick <[email protected]>
* i965/fs: Add support for generating the LINE instruction.Matt Turner2014-12-051-0/+4
| | | | Reviewed-by: Ian Romanick <[email protected]>
* i965: Set the region of LINE's src0 to <0,1,0>.Matt Turner2014-12-051-1/+10
| | | | | | | | | | | | | The PRMs say that <src0> region must be a replicated scalar (with HorzStride = VertStride = 0). but apparently that doesn't actually apply to all generations. I did notice when implementing the optimization later in this series that G45 and ILK needed this regioning. Reviewed-by: Ian Romanick <[email protected]>
* i965: Give compile stats through KHR_debug.Matt Turner2014-12-052-0/+20
| | | | Reviewed-by: Ian Romanick <[email protected]>
* mesa: Add a source parameter to _mesa_gl_debug.Matt Turner2014-12-057-2/+12
| | | | | Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/gs: Avoid DW * DW mulBen Widawsky2014-12-051-2/+6
| | | | | | | | | | | | | | | | | | | | | | | The GS has an interesting use for mul. Because the GS can emit multiple vertices per input vertex, and it also has a unique count at the top of the URB payload, the GS unit needs to be able to dynamically specify URB write offsets (relative to the global offset). The documentation in the function has a very good explanation from Paul on the mechanics. This fixes around 2000 piglit tests on BSW. v2: Reworded commit message (Ben) no mention of CHV (Matt) Change SHRT_MAX to USHRT_MAX (Ken, and Matt) Update comment in code to reflect the use of UW (Ben) Add Gen7+ assertion for the relevant GS code, since it won't work on Gen6- (Ken) Drop the bogus hunk in emit_control_data_bits() (Ken) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84777 (with many dupes) Cc: "10.4 10.3 10.2" <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/fs: Move brw_file_from_reg() higher in the file.Matt Turner2014-12-051-14/+14
| | | | This was supposed to be part of the previous commit.
* i965/fs: Make brw_reg_from_fs_reg static and remove prototype.Matt Turner2014-12-052-72/+70
| | | | | | And move it above its first use in brw_fs_generator.cpp. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Use ~0 to represent true on all generations.Matt Turner2014-12-055-102/+120
| | | | | | | | | | | | | | Jason realized that we could fix the result of the CMP instruction on Gen <= 5 by doing -(result & 1). Also do the resolves in the vec4 backend before use, rather than when the bool was created. The FS does this and it saves some unnecessary resolves. On Ironlake: total instructions in shared programs: 4289762 -> 4287277 (-0.06%) instructions in affected programs: 619430 -> 616945 (-0.40%) Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Change the type of booleans to D.Matt Turner2014-12-053-25/+25
| | | | | | | | | | This is a revert of commit 4656c14e ("i965/fs: Change the type of booleans to UD and emit correct immediates") plus some small additional fixes, like casting ctx->Const.UniformBooleanTrue to int and changing UD to D in the ir_unop_b2f cases. Note that it's safe to leave 0x3f800000 as UD and as a literal it's more recognizable than 1065353216. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Add a negate() function.Matt Turner2014-12-051-0/+8
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* i965/vec4: Don't DCE flag-writing insts because dest was unused.Matt Turner2014-12-051-1/+1
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* i965/vec4: Allow CSE on uniform-vec4 expansion MOVs.Matt Turner2014-12-056-1/+13
| | | | | | | | | | | | | | | | | | | | | | Three source instructions cannot directly source a packed vec4 (<0,4,1> regioning) like vec4 uniforms, so we emit a MOV that expands the vec4 to both halves of a register. If these uniform values are used by multiple three-source instructions, we'll emit multiple expansion moves, which we cannot combine in CSE (because CSE emits moves itself). So emit a virtual instruction that we can CSE. Sometimes we demote a uniform to to a pull constant after emitting an expansion move for it. In that case, recognize in opt_algebraic that if the .file of the new instruction is GRF then it's just a real move that we can copy propagate and such. total instructions in shared programs: 5822418 -> 5812335 (-0.17%) instructions in affected programs: 351841 -> 341758 (-2.87%) Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Ensure stack is realigned on x86.José Fonseca2014-12-051-0/+3
| | | | | | | | | | | | | | | | | | | | Nowadays GCC assumes stack pointer is 16-byte aligned even on 32-bits, but that is an assumption OpenGL drivers (or any dynamic library for that matter) can't afford to make as there are many closed- and open- source application binaries out there that only assume 4-byte stack alignment. This fix uses force_align_arg_pointer GCC attribute, and is only a stop-gap measure. The right fix would be to pass -mstackrealign or -mincoming-stack-boundary=2 to all source fails that use any -msse* option, as there is no way to guarantee if/when GCC will decide to spill SSE registers to the stack. https://bugs.freedesktop.org/show_bug.cgi?id=86788 Reviewed-by: Brian Paul <[email protected]>
* i965: Compute VS attribute WA bits earlier and check if they changed.Kenneth Graunke2014-12-044-37/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BRW_NEW_VERTICES is flagged every time we draw a primitive. Having the brw_vs_prog atom depend on BRW_NEW_VERTICES meant that we had to compute the VS program key and do a program cache lookup for every single primitive. This is painfully expensive. The workaround bit computation is almost entirely based on the vertex attribute arrays (brw->vb.inputs[i]), which are set by brw_merge_inputs. The only thing it uses the VS program for is to see which VS inputs are actually read. brw_merge_inputs() happens once per primitive, and can safely look at the currently bound vertex program, as it doesn't change in the middle of a draw. This patch moves the workaround bit computation to brw_merge_inputs(), right after assigning brw->vb.inputs[i], and stores the previous WA bit values in the context. If they've actually changed from the last draw (which is uncommon), we signal that we need a new vertex program, causing brw_vs_prog to compute a new key. Improves performance in Gl32Batch7 by 13.6123% +/- 0.739652% (n=166) on Haswell GT3e. I'm told Baytrail shows similar gains. v2: Introduce a new BRW_NEW_VS_ATTRIB_WORKAROUNDS dirty bit, rather than reusing BRW_NEW_VERTEX_PROGRAM (suggested by Chris Forbes). This prevents unnecessary re-emission of surface/sampler related atoms (and an SOL atom on Sandybridge). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Drop BRW_NEW_VERTEX_PROGRAM and _NEW_TRANSFORM from Gen4 VS state.Kenneth Graunke2014-12-041-3/+2
| | | | | | | | | | These stopped being necessary in commit ab973403e445cd8211dba4e87e0. v2: Update commit message with a better explanation (thanks to Eric Anholt for doing the git archaeology). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Drop BRW_NEW_VERTEX_PROGRAM from Gen7+ 3DSTATE_VS atoms.Kenneth Graunke2014-12-042-2/+0
| | | | | | | | | | | We don't access brw->vertex_program or ctx->_Shader since the previous commit, so we don't need this dirty bit. I think it's still necessary on Gen6 because it still conflates constant uploading with unit state uploading. We can fix that later. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Store floating point mode choice in brw_stage_prog_data.Kenneth Graunke2014-12-0411-43/+18
| | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Make Gen4-5 and Gen8+ ALT checks use ctx->_Shader too.Kenneth Graunke2014-12-044-4/+4
| | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Move PSCDEPTH calculations from draw time to compile time.Kenneth Graunke2014-12-046-52/+40
| | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Add var->location != -1 assertions.Kenneth Graunke2014-12-032-0/+3
| | | | | | | | | | We shouldn't receive variables with invalid locations set - adding these assertions should help catch problems before they cause crashes later. Inspired by similar code in st_glsl_to_tgsi. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/fs: Don't offset uniform registers in half().Matt Turner2014-12-031-0/+4
| | | | | | | Half gives you the second half of a SIMD16 register, but if the register is a uniform it would incorrectly give you the next register. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/skl: Fix SBE state upload code.Ben Widawsky2014-12-021-1/+3
| | | | | | | | | | | | | | | | | | | | | | | The state upload code was incorrectly shifting the attribute swizzles. The effect of this is we're likely to get the default swizzle values, which disables the component. This doesn't technically fix any bugs since Skylake support is still disabled by default (no PCI IDs). While here, since VARYING_SLOT_MAX can be greater than the number of attributes we have available, add a warning to the code to make sure we never do the wrong thing (and hopefully prevent further static analysis from finding this). Admittedly I am a bit confused. It seems to me like the moment a user has greater than 8 varyings we will hit this condition. CC Ken to clarify. v2: Forgot to git add the warning message in v1 v3: Change the > 31 varyings to an assertion (Ken) Reported-by: Ilia Mirkin <[email protected]> (via Coverity) Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Avoid union literal, for old gcc compatibility.Matt Turner2014-12-021-1/+2
| | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86939 Reviewed-by: Ian Romanick <[email protected]>
* i965: Remove tabs from instruction scheduler.Matt Turner2014-12-021-98/+98
| | | | Reviewed-by: Ben Widawsky <[email protected]>
* i965/vs: Set brw_vs_prog_key::clamp_vertex_color to 0 when irrelevant.Kenneth Graunke2014-12-021-3/+8
| | | | | | | | | | | | | | | | Vertex color clamping is only relevant if the shader writes to the built-in gl_[Secondary]{Front,Back}Color varyings. Otherwise, brw_vs_prog_key::clamp_vertex_color is never used, so we can simply leave it set to 0. This enables us to correctly predict the clamp_vertex_color key value in the precompile for shaders which don't use those varyings. Eliminates virtually all VS recompiles in Serious Sam 3's intro. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Make vertex color clamp handling code VS specific.Kenneth Graunke2014-12-025-12/+12
| | | | | | | | | | | | | Vertex color clamping only applies to gl_[Secondary]{Front,Back}Color, which are compatibility-only built-in varyings. We only support GS in core profile, so they can't exist in geometry shaders. We can drop several dirty bits from the GS program key - they're unnecessary for a core profile implementation. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965/vs: Handle vertex color clamping in emit_urb_slot().Kenneth Graunke2014-12-022-11/+13
| | | | | | | | | | | | | Vertex color clamping only applies to a few specific built-ins: COL0/1 and BFC0/1 (aka gl_[Secondary]{Front,Back}Color). It seems weird to handle special cases in a function called emit_generic_urb_slot(). emit_urb_slot() is all about handling special cases, so it makes more sense to handle this there. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Use the enum type for gen6_gather_wa sampler key field.Kenneth Graunke2014-12-021-7/+7
| | | | | | | Requested by Matt Turner. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Drop use of GL types in program keys.Kenneth Graunke2014-12-021-23/+23
| | | | | | | | This is really far removed from the API; we should just use C types. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Move program key structures to brw_program.h.Kenneth Graunke2014-12-025-82/+103
| | | | | | | | | | | | | | With fs_visitor/fs_generator being reused for SIMD8 VS/GS programs, we're running into weird #include patterns, where scalar code #includes brw_vec4.h and such. Program keys aren't really related to SIMD4X2/SIMD8 execution - they mostly capture NOS for a particular shader stage. Consolidating them all in one place that's vec4/scalar neutral should help avoid problems. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Delete brw_state_flags::cache and related code.Kenneth Graunke2014-12-0234-82/+4
| | | | | | | | | It's been merged into brw_state_flags::brw for simplicity and efficiency. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Move BRW_NEW_*_PROG_DATA flags to .brw (not .cache).Kenneth Graunke2014-12-0234-115/+137
| | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Rename CACHE_NEW_*_PROG to BRW_NEW_*_PROG_DATA.Kenneth Graunke2014-12-0233-124/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Acked-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-18 23:14:13 +0000