aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* i965: Pass number of components explicitly to brw_untyped_atomic and ↵Francisco Jerez2015-03-204-16/+32
| | | | | | | | | | | | _surface_read. And calculate the message response size based on the number of components rather than the other way around. This simplifies their interface somewhat and allows the caller to request a writeback message with more than one vector component in SIMD4x2 mode. Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965: Don't disable exec masking for sampler message sends.Francisco Jerez2015-03-202-8/+8
| | | | | | | | | | This was telling the sampler to do texture fetches for *all* channels in the non-constant surface index case, what could have reduced throughput unnecessarily when some of the channels were disabled by control flow. Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965: Factor out logic to build a send message instruction with indirect ↵Francisco Jerez2015-03-204-96/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | descriptor. This is going to be useful because the Gen7+ uniform and varying pull constant, texturing, typed and untyped surface read, write, and atomic generation code on the vec4 and fs back-end all require the same logic to handle conditionally indirect surface indices. In pseudocode: | if (surface.file == BRW_IMMEDIATE_VALUE) { | inst = brw_SEND(p, dst, payload); | set_descriptor_control_bits(inst, surface, ...); | } else { | inst = brw_OR(p, addr, surface, 0); | set_descriptor_control_bits(inst, ...); | inst = brw_SEND(p, dst, payload); | set_indirect_send_descriptor(inst, addr); | } This patch abstracts out this frequently recurring pattern so we can now write: | inst = brw_send_indirect_message(p, sfid, dst, payload, surface) | set_descriptor_control_bits(inst, ...); without worrying about handling the immediate and indirect surface index cases explicitly. v2: Rebase. Improve documentatation and commit message. (Topi) Preserve UW destination type cargo-cult. (Topi, Ken, Matt) Reviewed-by: Topi Pohjolainen <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965: Set nr_params to the number of uniform components in the VS/GS path.Francisco Jerez2015-03-203-15/+4
| | | | | | | | | | | | | | | | | | Both do_vs_prog and do_gs_prog initialize brw_stage_prog_data::nr_params to the number of uniform *vectors* required by the shader rather than the number of uniform components, contradicting the comment. This is inconsistent with what the state upload code and scalar path expect but it happens to work until Gen8 because vec4_visitor interprets it as a number of vectors on construction and later on overwrites its original value with the number of uniform components referenced by the shader. Also there's no need to add the number of samplers, they're not actually passed in as uniforms. Fixes a memory corruption issue on BDW with SIMD8 VS. Cc: "10.5" <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/skl: Break down SIMD16 3-source instructions when required.Kenneth Graunke2015-03-201-0/+6
| | | | | | | | | | | | | Several steppings of Skylake fail when using SIMD16 with 3-source instructions (such as MAD). This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit tests. Based on a patch by Neil Roberts. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Neil Roberts <[email protected]>
* i965: Refactor SIMD16-to-2xSIMD8 checks.Neil Roberts2015-03-201-4/+14
| | | | | | | | | | | The places that were checking whether 3-source instructions are supported have now been combined into a small helper function. This will be used in the next patch to add an additonal restriction. Based on a patch by Kenneth Graunke. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Store the GPU revision number in brw_contextNeil Roberts2015-03-202-0/+23
| | | | | | | | | | | brwContextInit now queries the GPU revision number via a new parameter for DRM_I915_GETPARAM. This new parameter requires a kernel patch and a patch to libdrm. If the kernel doesn't support it then it will continue but set the revision number to -1. The intention is to use this to implement workarounds that are only needed on certain steppings of the GPU. Reviewed-by: Kristian Høgsberg <[email protected]>
* i965/fp: Emit discard jumps.Kenneth Graunke2015-03-191-0/+3
| | | | | | | | | | | | This should improve the performance of any shaders using the KIL instruction. I'm a bit surprised we missed this. Unfortunately, I have not been able to measure any performance improvements from this patch. It does make ARB_fragment_program behave similarly to GLSL code. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/fs: Make an emit_discard_jump() function to reduce duplication.Kenneth Graunke2015-03-194-21/+18
| | | | | | | | | This is already copied in two places, and I want to copy it to a third place. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Carl Worth <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/nir: Sort uniforms direct-first and use two different uniform registersJason Ekstrand2015-03-192-7/+24
| | | | | | | | | | | | | | | | | | | | | Previously, we put all the uniforms into one big array. The problem with this approach is that, as soon as there was one indirect array acces, the backend would decide that the entire large array should be pull constants. This commit splits the array in half: first direct-only uniforms and then potentially-indirect uniforms. This may not be optimal, but it does let the backend promote things to push constants. Shader-db results on HSW: total instructions in shared programs: 4114840 -> 4112172 (-0.06%) instructions in affected programs: 43316 -> 40648 (-6.16%) helped: 116 HURT: 0 v2: Set param_size[num_direct_uniforms] only if we have indirect uniforms. This caused a bug that, strangely enough, only showed up on Broadwell vertex shaders. Reviewed-by: Connor Abbott <[email protected]>
* nir/lower_io: Make variable location assignment a manual operationJason Ekstrand2015-03-191-0/+4
| | | | | | | | | | Previously, we just assigned variable locations in nir_lower_io. Now, we force the user to assign variable locations for us. This gives the backend a bit more control over where variables are placed. v2: Rename from _packed to _scalar Reviewed-by: Connor Abbott <[email protected]>
* nir: Use a list instead of a hash_table for inputs, outputs, and uniformsJason Ekstrand2015-03-191-10/+3
| | | | | | | | | | | | We never did a single hash table lookup in the entire NIR code base that I found so there was no real benifit to doing it that way. I suppose that for linking, we'll probably want to be able to lookup by name but we can leave building that hash table to the linker. In the mean time this was causing problems with GLSL IR -> NIR because GLSL IR doesn't guarantee us unique names of uniforms, etc. This was causing massive rendering isues in the unreal4 Sun Temple demo. Reviewed-by: Connor Abbott <[email protected]>
* i965/fs: Print spills:fills and number of promoted constants.Matt Turner2015-03-197-13/+25
| | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965/fs: Emit better b2f of an expression on GEN4 and GEN5Ian Romanick2015-03-192-4/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On platforms that do not natively generate 0u and ~0u for Boolean results, b2f expressions that look like f = b2f(expr cmp 0) will generate better code by pretending the expression is f = ir_triop_sel(0.0, 1.0, expr cmp 0) This is because the last instruction of "expr" can generate the condition code for the "cmp 0". This avoids having to do the "-(b & 1)" trick to generate 0u or ~0u for the Boolean result. This means code like mov(16) g16<1>F 1F mul.ge.f0(16) null g6<8,8,1>F g14<8,8,1>F (+f0) sel(16) m6<1>F g16<8,8,1>F 0F will be generated instead of mul(16) g2<1>F g12<8,8,1>F g4<8,8,1>F cmp.ge.f0(16) g2<1>D g4<8,8,1>F 0F and(16) g4<1>D g2<8,8,1>D 1D and(16) m6<1>D -g4<8,8,1>D 0x3f800000UD v2: When the comparison is either == 0.0 or != 0.0 use the knowledge that the true (or false) case already results in zero would allow better code generation by possibly avoiding a load-immediate instruction. v3: Apply the optimization even when neither comparitor is zero. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3551002 -> 3550829 (-0.00%) instructions in affected programs: 33269 -> 33096 (-0.52%) helped: 121 Iron Lake (0x0046): total instructions in shared programs: 4993327 -> 4993146 (-0.00%) instructions in affected programs: 34199 -> 34018 (-0.53%) helped: 129 No change on other platforms. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Tapani Palli <[email protected]>
* i965/fs: Ignore type in cmod prop if scan_inst is CMP.Matt Turner2015-03-181-12/+13
| | | | | | | | | | total instructions in shared programs: 6263270 -> 6203091 (-0.96%) instructions in affected programs: 2606529 -> 2546350 (-2.31%) helped: 14301 GAINED: 5 LOST: 3 Revewed-by: Jason Ekstrand <[email protected]>
* i965/nir: Make our environment variable checking smarterJason Ekstrand2015-03-181-2/+22
| | | | | | | | | Before, we enabled NIR if you set INTEL_USE_NIR to anything which mean that INTEL_USE_NIR=false would actually turn on NIR. In preparation for turning NIR on by default, this commit makes it smarter by allowing the INTEL_USE_NIR variable to work as either a force-enable or a force-disable. Reviewed-by: Mark Janes <[email protected]>
* dri: add _glapi_set_nop_handler(), _glapi_new_nop_table() to dri_test.cBrian Paul2015-03-181-0/+11
| | | | | | | | I wasn't aware of these _glapi_ stub functions when I committed 4bdbb588a9d385509f9168e38bfdb76952ba469c. Fixes "make check" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89662 Reviewed-by: Mark Janes <[email protected]>
* i965: Defer the throttle until we submit new commandsChris Wilson2015-03-182-34/+44
| | | | | | | | | | | | | | | | | | | | | | Currently, we throttle before the user begins preparing commands for the next frame when we acquire the draw/read buffers. However, construction of the command buffer can itself take significant time relative to the frame time. If we move the throttle from the buffer acquire to the command submit phase we can allow the user to improve concurrency between the CPU and GPU (i.e. reduce the amount of time we waste inside the throttle). v2: Whitespace + delay throttling until after the next submission for greater parallelism Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Kenneth Graunke <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: Kristian Høgsberg <[email protected]> Cc: Chad Versace <[email protected]> Cc: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> [v1]
* i965: Throttle to the previous frameChris Wilson2015-03-183-11/+17
| | | | | | | | | | | | | | | | | | | | | | | | | In order to facilitate the concurrency offered by triple buffering and to offset the latency induced by swapping via an external process, which may incur extra rendering itself, only throttle to the previous frame and not the last. The second issue that mostly affects swap benchmarks, but also can incur jitter in the throttling, is that the throttle bo is closer to the next SwapBuffers rather than immediately after the previous SwapBuffers. Throttling to the previous frame doubles the maximum possible latency at the benefit of improving throughput and reducing jitter. v2: Rename "first_post_swapbuffer" batches array to a plain throttle_batch[] as the pluralisation was contorting the name and not making it clear as to whether it was the first batch or first_post_swap batch. Not least of which was that not all throttle points are SwapBuffers. Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Kenneth Graunke <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: Kristian Høgsberg <[email protected]> Cc: Chad Versace <[email protected]> Cc: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Throttle rendering to an fboChris Wilson2015-03-183-9/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When rendering to an fbo, even though it may be acting as a winsys frontbuffer or just generally, we never throttle. However, when rendering to an fbo, there is no natural frame boundary. Conventionally we use SwapBuffers and glFinish, but potential callers avoid often glFinish for being too heavy handed (waiting on all outstanding rendering to complete). The kernel provides a soft-throttling option for this case that waits for rendering older than 20ms to be complete (that's a little too lax to be used for swapbuffers, but is here a useful safety net). The remaining choice is then either never to throttle, throttle after every draw call, or at after intermediate user defined point such as glFlush and thus all the implied flushes. This patch opts for the latter as that is the current method used for flushing to front buffers. v2: Defer the throttling from inside the flush to the next intel_prepare_render() and switch non-fbo frontbuffer throttling over to use the same lax method. The issuing being that glFlush()/intel_prepare_read() is just as likely to be called inside a tight loop and not at "frame" boundaries. v3: Rename from need_front_throttle to need_flush_throttle to avoid any ambiguity between front buffer rendering and fbo rendering. (Chad) v4: Whitespace Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Kenneth Graunke <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: Kristian Høgsberg <[email protected]> Cc: Chad Versace <[email protected]> Cc: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/fs: Apply gl_FrontFacing ? -1 : 1 optimization only for floatsIan Romanick2015-03-171-0/+3
| | | | | | | | | | | | | | | | At the very least, unreal4/sun-temple/102.shader_test uses this pattern for a signed integer result. However, that shader did not hit the optimization in the first place because it uses !gl_FrontFacing. I changed the shader to use remove the logical-not and reverse the other operands. I verified that incorrect code is generated before this change and correct code is generated after. Fixes fs-frontfacing-ternary-1-neg-1.shader_test. No shader-db changes. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/fs: Change try_opt_frontfacing_ternary to eliminate assertsIan Romanick2015-03-171-5/+2
| | | | | | | | If we check for the case that is actually necessary, the asserts become superfluous. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagationIan Romanick2015-03-172-1/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Espically on platforms that do not natively generate 0u and ~0u for Boolean results, we generate a lot of sequences where a CMP is followed by an AND with 1. emit_bool_to_cond_code does this, for example. On ILK, this results in a sequence like: add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F and.nz.f0(8) null g3<8,8,1>D 1D (+f0) iff(8) Jump: 6 The AND.nz is obviously redundant. By propagating the cmod, we can instead generate add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F (+f0) iff(8) Jump: 6 Existing code already handles the propagation from the CMP to the ADD. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3550829 -> 3550788 (-0.00%) instructions in affected programs: 10028 -> 9987 (-0.41%) helped: 24 Iron Lake (0x0046): total instructions in shared programs: 4993146 -> 4993105 (-0.00%) instructions in affected programs: 9675 -> 9634 (-0.42%) helped: 24 Ivy Bridge (0x0166): total instructions in shared programs: 6291870 -> 6291794 (-0.00%) instructions in affected programs: 17914 -> 17838 (-0.42%) helped: 48 Haswell (0x0426): total instructions in shared programs: 5779256 -> 5779180 (-0.00%) instructions in affected programs: 16694 -> 16618 (-0.46%) helped: 48 Broadwell (0x162E): total instructions in shared programs: 6823088 -> 6823014 (-0.00%) instructions in affected programs: 15824 -> 15750 (-0.47%) helped: 46 No chage on Sandy Bridge or on any platform when NIR is used. v2: Add unit tests suggested by Matt. Remove spurious writes_flag() check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also suggested by Matt). v3: Fix some comments and remove some explicit int() casts in fs_reg constructors in the unit tests. Both suggested by Matt. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Mark paths in linear <-> tiled functions as unreachable().Matt Turner2015-03-171-0/+16
| | | | | | | | | text data bss dec hex filename 9663 0 0 9663 25bf intel_tiled_memcpy.o before 8215 0 0 8215 2017 intel_tiled_memcpy.o after Reviewed-by: Carl Worth <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/skl: Send a message header when doing constant loads SIMD4x2Neil Roberts2015-03-173-6/+53
| | | | | | | | | | | | | | Commit 0ac4c272755c7 made it add a header for the send message when using SIMD4x2 on Skylake because without this it will end up using SIMD8D. However the patch missed the case when a sampler is being used to implement constant loads from a buffer surface in a SIMD4x2 vertex shader. This fixes 29 Piglit tests, mostly related to the ARL instruction in vertex programs. Reviewed-by: Kristian Høgsberg <[email protected]> Tested-by: Anuj Phogat <[email protected]>
* i965/fs: in MAD optimizations, switch last argument to be immediateTapani Pälli2015-03-171-1/+10
| | | | | | | | | | | | | | | | | Commit bb33a31 introduced optimizations that transform cases of MAD in to simpler forms but it did not take in to account that src[0] can not be immediate and did not report progress. Patch switches src[0] and src[1] if src[0] is immediate and adds progress reporting. If both sources are immediates, this is taken care of by the same opt_algebraic pass on later run. v2: Fix for all cases, use temporary fs_reg (Matt, Kenneth) Signed-off-by: Tapani Pälli <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89569 Reviewed-by: Francisco Jerez <[email protected]> (v1) Reviewed-by: Kenneth Graunke <[email protected]> Cc: "10.5" <[email protected]>
* i965: Emit IF/ELSE/ENDIF/WHILE JIP with type W on Gen7Antia Puentes2015-03-161-4/+4
| | | | | | | | | | IvyBridge and Haswell PRM say that the JIP should be emitted with type W but we were using UD. The previous implementation did not show adverse effects, but IMHO it is safer to follow the specification thoroughly. Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Antia Puentes <[email protected]>
* i965: De-duplicate is_expression_commutative() functions.Kenneth Graunke2015-03-154-46/+25
| | | | | | | | Create a backend_inst::is_commutative() method to replace two static functions that did the exact same thing. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/gen4-5: Cope with immutable-format texture revalidationChris Forbes2015-03-141-3/+10
| | | | | | | | | | This is unfortunately sometimes necessary due to rebasing levels when rendering into them. 16 piglits crash -> pass, when building mesa with debug enabled. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: Add missing resolve_bool_comparison calls on GEN4 and GEN5Ian Romanick2015-03-131-0/+13
| | | | | | | | | | | | | | | | | | | | | The ir_unop_any problem was discovered by some later optimization passes that generate ir_triop_csel. I was also able to reproduce it by modifying the gl-2.0-vertexattribpointer vertex shader to generate its result using color = mix(vec4(0, 1, 0, 0), vec4(1, 0, 0, 0), bvec4(any(greaterThan(diff, vec4(tolerance))))); instead of an if-statement. This also required using #version 130 and MESA_GLSL_VERSION_OVERRIDE=130. I have not nominated this for stable releases because I don't think there's any way to trigger the problem without GLSL 1.30 or optimizations that don't exist in stable. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Abdiel Janulgue <[email protected]>
* i965/disasm: Fix format stringsChris Forbes2015-03-141-24/+24
| | | | | | | | Most of the brw_inst_* api returns 64bit values. This fixes disassembly of sampler messages, etc. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/disasm: Mark format() as being printf-style.Chris Forbes2015-03-141-0/+3
| | | | | | | | This allows us to get warnings from GCC when we mess up the format strings. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* meta: Remove error checks for texture <-> pixel-buffer transfers that don't ↵Eduardo Lima Mitev2015-03-131-32/+0
| | | | | | | | | | | | | | | | | belong in driver code The implementation of texture <-> pixel-buffer transfers in drivers common layer includes certain error checks and argument validation that don't belong there, considering how the Mesa codebase is laid out. These are higher level validations that, if necessary, should be performed earlier (i.e, in GL API entry points). This patch simply removes these error checks from driver code. For more information, see discussion at http://lists.freedesktop.org/archives/mesa-dev/2015-February/077417.html. Reviewed-by: Laura Ekstrand <[email protected]>
* i965: Use NIR for scalar VS when INTEL_USE_NIR is set.Kenneth Graunke2015-03-121-5/+10
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Add VS output support to nir_setup_outputs().Kenneth Graunke2015-03-121-5/+11
| | | | | | | Adapted from fs_visitor::visit(ir_variable *). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Handle VS inputs in the NIR backend.Kenneth Graunke2015-03-121-1/+22
| | | | | | | | | | (Jason noted that this is not a good long term solution, and we should instead improve nir_lower_io so that this extra set of MOVs is unnecessary. I tend to agree, but decided we could do that as a follow-up improvement.) Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Refactor fs_visitor::nir_setup_inputs().Kenneth Graunke2015-03-121-10/+19
| | | | | | | | | | | No functional change. In preparation for supporting vertex shaders, this adds a switch statement on shader stage (since vertex attributes and fragment shader varyings will need different handling). It also renames "varying" to "input", to be more general. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Implement NIR intrinsics for loading VS system values.Kenneth Graunke2015-03-121-0/+51
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/nir: Lower to registers a bit later.Kenneth Graunke2015-03-121-3/+3
| | | | | | | | | | | We can't safely call nir_optimize() with register present, since several passes called in the loop can't handle registers, and will fail asserts. Notably, nir_lower_vec_alus() and nir_opt_algebraic() really don't want registers. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/nir: Optimize after nir_lower_var_copies().Kenneth Graunke2015-03-121-0/+3
| | | | | | | | Array variable copy splitting generates a bunch of stuff we want to clean up before proceeding. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Store a pointer to brw_sampler_prog_key_data in the visitor.Kenneth Graunke2015-03-123-35/+33
| | | | | | | | | | | | | | | | | | | The NIR backend hardcodes brw_wm_prog_key at the moment, which won't work when we support scalar VS. We could use get_tex(), but it's a static method. I was going to promote it to fs_visitor, but then realized that both parameters (stage and key) are already members. It then occured to me that we could just set up a pointer in the constructor, and skip having a function altogether. This patch also converts all existing users to use key_tex. v2: Make key_tex a "const brw_sampler_prog_key_data *" instead of non-const; word-wrap some lines. (Review comments from Topi.) Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* xlib: use strdup() instead of _mesa_strdup()Brian Paul2015-03-111-1/+2
| | | | | Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915: add parens to silence operator precedence warningBrian Paul2015-03-111-1/+1
| | | | Signed-off-by: Brian Paul <[email protected]>
* i965: Fix out-of-bounds accesses into pull_constant_loc arrayIago Toral Quiroga2015-03-111-2/+7
| | | | | | | | | | | | | | The piglit test glsl-fs-uniform-array-loop-unroll.shader_test was designed to do an out of bounds access into an uniform array to make sure that we handle that situation gracefully inside the driver, however, as Ken describes in bug 79202, Valgrind reports that this is leading to an out-of-bounds access in fs_visitor::demote_pull_constants(). Before accessing the pull_constant_loc array we should make sure that the uniform we are trying to access is valid. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79202 Reviewed-by: Matt Turner <[email protected]>
* i965/gen6 gs: Convert brw_imm_ud/brw_imm_d to src_regJordan Justen2015-03-101-7/+7
| | | | | | | | | | | | | | Same idea as this patch, only for gen6_gs_visitor: commit 49a938a265f5959c9b558995cc658f80acb6eb18 Author: Jordan Justen <[email protected]> Date: Fri Feb 20 12:12:25 2015 -0800 i965/fs: Use fs_reg for CS/VS atomics pixel mask immediate data Suggested-by: Matt Turner <[email protected]> Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/fs: Use unsigned for CS/VS atomics pixel mask immediate dataJordan Justen2015-03-101-2/+2
| | | | | | | | | | | | | brw_imm_ud(0xffff) should have been converted to fs_reg(0xffffu) to make sure the uint32_t fs_reg constructor was matched. commit 49a938a265f5959c9b558995cc658f80acb6eb18 Author: Jordan Justen <[email protected]> Date: Fri Feb 20 12:12:25 2015 -0800 i965/fs: Use fs_reg for CS/VS atomics pixel mask immediate data Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gen8: Don't allocate hiz miptree structureJordan Justen2015-03-091-0/+105
| | | | | | | | | | | | | | | | | | | We now skip allocating a hiz miptree for gen8. Instead, we calculate the required hiz buffer parameters and allocate a bo directly. v2: * Update hz_height calculation as suggested by Topi v3: * Bail if we failed to create the bo (Ben) v4: * CEILING => DIV_ROUND_UP * Make sure mt->logical_depth0 being 0 would not cause trouble * Fail if Y tiling is not returned Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67564 Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965/gen7: Don't allocate hiz miptree structureJordan Justen2015-03-091-2/+104
| | | | | | | | | | | | | | | | | | | We now skip allocating a hiz miptree for gen7. Instead, we calculate the required hiz buffer parameters and allocate a bo directly. v2: * Update hz_height calculation as suggested by Topi v3: * Bail if we failed to create the bo (Ben) v4: * CEILING => DIV_ROUND_UP * Make sure mt->logical_depth0 being 0 would not cause trouble * Fail if Y tiling is not returned Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67564 Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965/gen8: Don't rely directly on the hiz miptree structureJordan Justen2015-03-091-3/+3
| | | | | | | | | | | We are still allocating a miptree for hiz, but we only use fields from intel_miptree_aux_buffer. This will allow us to switch over to not allocating a miptree. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965/gen7: Don't rely directly on the hiz miptree structureJordan Justen2015-03-092-6/+7
| | | | | | | | | | | We are still allocating a miptree for hiz, but we only use fields from intel_miptree_aux_buffer. This will allow us to switch over to not allocating a miptree. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 00:48:47 +0000