summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* meta: Add an accelerated glCopyTexSubImage using glBlitFramebuffer.Eric Anholt2014-04-154-12/+94
| | | | | | | | | | | | | | | You'll note from the previous commits that there's something of a loop here: You call CTSI, which calls BlitFB, then if things go wrong that falls back to CTSI. As a result, meta CTSI reaches over into blitfb to tell it "no, don't try that fallback". v2: Drop the _mesa_update_state(), which was only necessary due to use of _mesa_clip_blit() in _mesa_meta_BlitFramebuffer() in another patch series. v3: Drop an _EXT suffix I copy-and-pasted. Reviewed-by: Ian Romanick <[email protected]> (v2) Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Add support for CUBE_MAP_ARRAY to generatemipmap.Eric Anholt2014-04-152-1/+5
| | | | | | | | | | I added support to bind_fbo_image in the process of building meta CopyTexSubImage, and found that it broke generatemipmap because previously we would just throw a GL error there and then end up with an incomplete FBO and fallback. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Infer bind_fbo_image parameters from an incoming image.Eric Anholt2014-04-153-6/+13
| | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Move bind_fbo_image() code back to meta.c, to reuse it elsewhere.Eric Anholt2014-04-153-34/+36
| | | | | | | | | I need to do the same code again for CopyTexSubImage(). v2: Drop incorrect, not-terribly-useful comment (review by Ken) Reviewed-by: Ian Romanick <[email protected]> (v1) Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Refactor the BlitFramebuffer depth CopyTexImage fallback.Eric Anholt2014-04-152-138/+2
| | | | | | | | | This avoids a ReadPixels() if there's accelerated CopyTexImage present. It now requires GLSL as opposed to just fragment programs, but we don't have any drivers that do ARB_fp but not GLSL. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Refactor the BlitFramebuffer color CopyTexImage fallback.Eric Anholt2014-04-151-52/+41
| | | | | | | | | | | | | | | | | | | There shouldn't be anything special about copying out a subset of the src rb to a temp before texturing from it, so just do it when we're figuring out our src texture binding. This drops Anuj's change to copy an extra border of 1 pixel around the src area. I can't see how that change could be valid, and presumably if there's some filtering problem at edges we just need to set the right wrap mode. v2: Don't fall back to swrast on non-2D/RECT/2D_MS textures when we can still CopyTexSubImage. Fixes a segfault regression on i965 with gl-3.2-layered-rendering-blit. Reviewed-by: Ian Romanick <[email protected]> (v1) Reviewed-by: Kenneth Graunke <[email protected]> (v1) Tested-by: Anuj Phogat <[email protected]>
* meta: Drop blit src size fallback.Eric Anholt2014-04-151-10/+0
| | | | | | | | | | | | | I think we can assert that renderbuffer size is <= maximum 2D texture size. Our source coordinates should have already been clipped to the src renderbuffer size, but haven't actually (so we could potentially have trouble if there's scaling, and we're in the CopyTexImage path that tries to use src size). However, this texture size dependency was blocking the next refactors, so I'm not sure if we want to go ahead with this series before we get the clipping sorted out or not. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Avoid dependency hints on math opcodesMike Stroyan2014-04-151-0/+8
| | | | | | | | | | | Putting NoDDClr and NoDDChk dependency control on instruction sequences that include math opcodes can cause corruption of channels. Treat math opcodes like send opcodes and suppress dependency hinting. Signed-off-by: Mike Stroyan <[email protected]> Tested-by: Tony Bertapelli <[email protected]> Cc: [email protected] Reviewed-by: Matt Turner <[email protected]>
* i965: Expand INTEL_DEBUG to uint64_t.Matt Turner2014-04-152-2/+2
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Expand driParseDebugString return value to uint64_t.Matt Turner2014-04-152-6/+5
| | | | | | Users will downcast if they don't have >32 debug flags. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Remove dead_code_eliminate_local().Matt Turner2014-04-152-159/+0
| | | | | | | Subsumed by the new dead_code_eliminate() function. No shader-db changes. Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Clear variable from live-set if it's completely overwritten.Matt Turner2014-04-151-0/+9
| | | | | | | | One program affected: instructions in affected programs: 246 -> 244 (-0.81%) Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Reimplement dead_code_elimination().Matt Turner2014-04-153-56/+117
| | | | | | | | | | | | | | | | | total instructions in shared programs: 1653399 -> 1651790 (-0.10%) instructions in affected programs: 92157 -> 90548 (-1.75%) GAINED: 2 LOST: 2 Also significantly reduces the number of optimization loop iterations: total loop iterations in shared programs: 39724 -> 31651 (-20.32%) loop iterations in affected programs: 21617 -> 13544 (-37.35%) Including some great pathological cases, like 29 -> 3 in Strike Suit Zero and 24 -> 3 in Dota2. Reviewed-by: Eric Anholt <[email protected]>
* i965/vec4: Let DCE eliminate dead writes in other basic blocks.Matt Turner2014-04-151-4/+4
| | | | | | | | We previously stopped searching for unread writes after encountering control flow, but we can instead just search backwards until we hit control flow. instructions in affected programs: 22854 -> 22194 (-2.89%)
* i965/gs: Add dummy source to prepare_channel_masks instruction.Matt Turner2014-04-151-1/+2
| | | | | | The generator uses its destination as a source implicitly, which breaks some assumptions in dead code elimination. Giving the instruction a source allows us to reason about it better.
* glsl: Use M_PI_* macros.Matt Turner2014-04-151-7/+13
| | | | | Notice our multiple values for M_PI_2, which rounded ...32 up to ...4 and ...5.
* i965: Disable Z16 in all APIs.Kenneth Graunke2014-04-151-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We originally thought that GL 3.0 required GL_DEPTH_COMPONENT16 to map exactly to Z16. However, we misread the specification, thanks in part to LaTeX reordering the tables in the PDF. Page 180 of the GL 3.0 specification (glspec30.20080923.pdf) says: "[...] memory allocation per texture component is assigned by the GL to match the allocations listed in tables 3.16-3.18 as closely as possible. [...] Required Texture Formats [...] In addition, implementations are required to support the following sized internal formats. Requesting one of these internal formats for any texture type will allocate exactly the internal component sizes and types shown for that format in tables 3.16-3.17:" Notably, however, GL_DEPTH_COMPONENT16 does /not/ appear in table 3.16 or table 3.17. It appears in table 3.18, where the "exact" rule doesn't apply, and it falls back to the "closely as possible" rule. The confusing part is that the ordering of the tables in the PDF is: Table 3.16 (pages 182-184) Table 3.18 (bottom of page 184 to top of 185) Table 3.17 (page 185) Presumably, people saw table 3.16, then saw the table immediately following with DEPTH_COMPONENT* formats, and assumed it was 3.17. Based on a patch by Chia-I Wu, but without the driconf option to force Z16 to be used. It's not required, and there's apparently no benefit to actually using it. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chia-I Wu <[email protected]>
* i965: Update comments about Z16 being slow.Kenneth Graunke2014-04-151-7/+10
| | | | | | | | | | | | | | | We've learned a few things since we originally disabled Z16; this attempts to summarize the issue. I am no expert on this subject, though, so the comment may not be totally accurate. I did some benchmarking on GM45 and Ironlake, and discovered that for GLBenchmark 2.7 EgyptHD, using Z16 was 3% slower on GM45 (n=15), and 4.5% slower on Ironlake (n=95). So, we can drop the "on Ivybridge" aspect of the comment - it's always slower. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chia-I Wu <[email protected]>
* r600g/radeonsi: Use caching buffer manager for textures as wellMichel Dänzer2014-04-151-1/+1
| | | | | | | Significantly reduces BO allocation / destruction overhead for transfers, e.g. measurable via x11perf -shm{ge,pu}t* with glamor. Reviewed-by: Marek Olšák <[email protected]>
* i965/gen8: add debug code to show FS disasm with jump locationsJordan Justen2014-04-141-0/+9
| | | | | | | Copied from similar code in gen8_vec4_generator.cpp. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* ilo: remove GPE state size estimationChia-I Wu2014-04-147-326/+97
| | | | Use size defines from genhw.
* ilo: remove GPE command size estimationChia-I Wu2014-04-146-403/+87
| | | | Use size defines from genhw.
* ilo: remove unused headersChia-I Wu2014-04-143-566/+0
| | | | | Remove intel_*.h. brw_*.h is still needed by the state dumper and disassembler.
* ilo: use only defines from genhw headersChia-I Wu2014-04-147-106/+87
| | | | Stop including classic driver headers in genhw.h, with some formatting fixes.
* ilo: scripted conversion to genhw headersChia-I Wu2014-04-1425-1626/+1626
| | | | Hopefully my four hundred line sed script is correct.
* ilo: add genhw headersChia-I Wu2014-04-1422-131/+3504
| | | | | All except genhw.h are generated by https://github.com/olvaffe/envytools/. intel_chipset.h is deprecated.
* ilo: avoid brw_wm_barycentric_interp_mode in compilerChia-I Wu2014-04-141-17/+46
| | | | In preparation for genhw.
* ilo: add TOY_OPCODE_DOChia-I Wu2014-04-146-7/+10
| | | | | We used to give BRW_OPCODE_DO a special meaning, while we should have used TOY_OPCODE_DO.
* gtest: Update to 1.7.0.Vinson Lee2014-04-1431-1508/+2509
| | | | | | | | | This patch fixes gtest build errors on Mac OS X 10.9. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73106 Signed-off-by: Vinson Lee <[email protected]> Tested-by: Ian Romanick <[email protected]> Acked-by: Ian Romanick <[email protected]>
* mesa: Consider gl_VertexID and gl_InstanceID active attribsChris Forbes2014-04-131-0/+9
| | | | | | | Fixes piglit's spec/gl-3.2/get-active-attrib-returns-all-inputs. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Extract is_active_attrib() in shaderapiChris Forbes2014-04-131-8/+19
| | | | | | | | | | The rules are about to get a bit more complex to account for gl_InstanceID and gl_VertexID, which are system values. Extracting this first avoids introducing duplication. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Fix typo in interface block commentChris Forbes2014-04-131-1/+1
| | | | Signed-off-by: Chris Forbes <[email protected]>
* egl-static: fix build after recent radeon winsys changesSimone Scanzoni2014-04-131-0/+4
| | | | Signed-off-by: Marek Olšák <[email protected]>
* mesa: Fix typo in error messageChris Forbes2014-04-131-1/+1
| | | | Signed-off-by: Chris Forbes <[email protected]>
* i965: glClearBuffer() should only clear a single buffer.Iago Toral Quiroga2014-04-133-3/+7
| | | | | | | | | | | | | | | | glClearBuffer() is currently clearing all active draw color buffers (all buffers that have not been set to GL_NONE when calling glDrawBuffers) instead of only clearing the one it receives as parameter. Altough brw_clear() receives a bit mask indicating the color buffers that should be cleared, this mask is ignored when calling brw_blorp_clear_color(). This was breaking the 'fbo-drawbuffers-none glClearBuffer' piglit test. The patch provides the bit mask to brw_blorp_clear_color() so it can limit clearing to the color buffers present in the mask. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76832 Reviewed-by: Eric Anholt <[email protected]>
* i965: Add comment to explain the weird-looking shadow compares.Chris Forbes2014-04-131-5/+16
| | | | | | | | | | | This always looks crazy when I stumble across it, until I remember what the hardware is doing. Describing it ought to short-circuit that process next time :) V2: Fix indents to 6 spaces, not 7. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Ignore loop-too-large heuristic if there's bad variable indexing.Kenneth Graunke2014-04-111-3/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many shaders use a pattern such as: for (int i = 0; i < NUM_LIGHTS; i++) { ...access a uniform array, or shader input/output array... } where NUM_LIGHTS is a small constant (such as 2, 4, or 8). The expectation is that the compiler will unroll those loops, turning the array access into constant indexing, which is more efficient, and which may enable array splitting and other optimizations. In many cases, our heuristic fails - either there's another tiny nested loop inside, or the estimated number of instructions is just barely beyond the threshold. So, we fail to unroll the loop, leaving the variable indexing in place. Drivers which don't support the particular flavor of variable indexing will call lower_variable_index_to_cond_assign(), which generates piles and piles of immensely inefficient code. We'd like to avoid generating that. This patch detects unsupported forms of variable-indexing in loops, where the array index is a loop induction variable. In that case, it bypasses the loop-too-large heuristic and forces unrolling. Improves performance in various microbenchmarks: Gl32PSBump8 by 47%, Gl32ShMapVsm by 80%, and Gl32ShMapPcf by 27%. No changes in shader-db. v2: Check ir->array for being an array or matrix, rather than the ir_dereference_array itself. v3: Fix and expand statistics in commit message. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Rename loop_unroll_count::fail to "nested_loop."Kenneth Graunke2014-04-111-4/+5
| | | | | | | | | | | The "fail" flag is set if loop_unroll_count encounters a nested loop; calling the flag "nested_loop" is a bit clearer. The original reasoning was that count is inaccurate (too small) if there are nested loops, as we don't do any sort of analysis on the inner loop. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Pass gl_shader_compiler_optimizations to unroll_loops().Kenneth Graunke2014-04-113-9/+16
| | | | | | | Loop unrolling will need to know a few more options in the future. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Drop do_common_optimization's max_unroll_iterations parameter.Kenneth Graunke2014-04-118-16/+8
| | | | | | | | | | | | Now that we pass in gl_shader_compiler_options, it makes sense to just use options->MaxUnrollIterations, rather than passing a separate parameter. Half of the invocations already passed options->MaxUnrollIterations, while the other half passed in a hardcoded value of 32. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Use EmitNoIndirect flags in lower_variable_index_to_cond_assign.Kenneth Graunke2014-04-111-8/+7
| | | | | | | This will prevent the two from getting out of sync again. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Correct EmitNoIndirect shader compiler option flags.Kenneth Graunke2014-04-111-3/+2
| | | | | | | | These were out of sync with the flags used to control lower_variable_index_to_cond_assign in brw_shader.cpp. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Reset reg_from when we can't coalesce.Matt Turner2014-04-111-0/+1
| | | | | | | | | | | | Not setting this would prevented coalescing after a failed attempt if the sources for both MOVs were the same. total instructions in shared programs: 1654531 -> 1650224 (-0.26%) instructions in affected programs: 423167 -> 418860 (-1.02%) GAINED: 2 LOST: 0 Reviewed-by: Eric Anholt <[email protected]>
* i965: Fill in a bunch of gen7/hsw data cache-related disasm.Eric Anholt2014-04-111-7/+103
| | | | | | | | This gets us disasm of atomic ops. v2: Fix fallthrough on pre-gen7. (bug caught by Ilia Mirkin). Reviewed-by: Matt Turner <[email protected]>
* i965: Stop setting up a 1:1 "attrib" member in our vertex inputs.Eric Anholt2014-04-114-5/+2
| | | | | | | | | It's just the array index, so we can just go look at the array and see which element we are. No significant performance difference (n=140) Reviewed-by: Ian Romanick <[email protected]>
* i965: Skip a bunch of IB BO refcount twiddling.Eric Anholt2014-04-111-13/+13
| | | | | | Improves cairo performance on glamor by 1.64828% +/- 1.04742% (n=65). Reviewed-by: Ian Romanick <[email protected]>
* i965/gen7: Skip repeated NULL depth/stencil state emits.Eric Anholt2014-04-114-0/+20
| | | | | | Improves cairo performance on glamor by 2.87752% +/- 0.966977 (n=57). Reviewed-by: Ian Romanick <[email protected]>
* docs: Fix ubo indexing descriptionChris Forbes2014-04-121-1/+1
| | | | | | | Ian points out that this being unrestricted was an oversight in the spec, and is corrected in GLSL4.40. Signed-off-by: Chris Forbes <[email protected]>
* draw: remove unused 'start' variable in draw_stats_clipper_primitives()Brian Paul2014-04-111-5/+2
| | | | | | It was computed, but never actually used. Reviewed-by: Ian Romanick <[email protected]>
* glsl: Try vectorizing when seeing a repeated assignment to a channel.Kenneth Graunke2014-04-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | When considering assignment expressions like: v.x += u.x; v.x += u.x; the vectorizer would incorrectly keep going, attempting to find more instructions to vectorize. It would overwrite the saved assignment to point at the second one, and increment channels a second time, resulting in try_vectorize thinking the expression was a vec2 instead of a float. Instead, if we see a repeated assignment to a channel, just try to vectorize everything we've found so far. This clears the saved state so it will start over. Fixes Piglit's repeated-channel-assignments.vert. Cc: "10.1" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-20 20:33:04 +0000