aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* anv: rework queries writes to ensure ordering memory writesLionel Landwerlin2019-05-081-17/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We use a mix of MI & PIPE_CONTROL commands to write our queries' data (results & availability). Those commands' memory write order is not guaranteed with regard to their order in the command stream, unless CS stalls are inserted between them. This is problematic for 2 reasons : 1. We copy results from the device using MI commands even though the values are generated from PIPE_CONTROL, meaning we could copy unlanded values into the results and then copy the availability that is inconsistent with the values. 2. We allow the user to poll on the availability values of the query pool from the CPU. If the availability lands in memory before the values then we could return invalid values. This change does 2 things to address this problem : - We use either PIPE_CONTROL or MI commands to write both queries values and availability, so that the ordering of the memory writes guarantees that if availability is visible, results are also visible. - For the occlusion & timestamp queries we apply a CS stall before copying the results on the device, to ensure copying with MI commands see the correct values of previous PIPE_CONTROL writes of availability (required by the Vulkan spec). Signed-off-by: Lionel Landwerlin <[email protected]> Reported-by: Iago Toral Quiroga <[email protected]> Cc: [email protected] Reviewed-by: Jason Ekstrand <[email protected]>
* radv: call constant folding before opt algebraicTimothy Arceri2019-05-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The pattern of calling opt algebraic first seems to have originated in i965. The order in OpenGL drivers generally doesn't matter because the GLSL IR optimisations do constant folding before opt algebraic. However in Vulkan drivers calling opt algebraic first can result in missed constant folding opportunities. vkpipeline-db results (VEGA64): Totals from affected shaders: SGPRS: 3160 -> 3176 (0.51 %) VGPRS: 3588 -> 3580 (-0.22 %) Spilled SGPRs: 52 -> 44 (-15.38 %) Spilled VGPRs: 0 -> 0 (0.00 %) Private memory VGPRs: 0 -> 0 (0.00 %) Scratch size: 12 -> 12 (0.00 %) dwords per thread Code Size: 261812 -> 261036 (-0.30 %) bytes LDS: 7 -> 7 (0.00 %) blocks Max Waves: 346 -> 348 (0.58 %) Wait states: 0 -> 0 (0.00 %) Reviewed-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* docs: drop h1 in headerErik Faye-Lund2019-05-08274-279/+274
| | | | | | | | | | | It's generally frowned upon to have more than one H1 per document in HTML4. So let's put the text directly inside the header. This means we can drop the flex-based centering, which makes things a bit easier. We also need to change the padding to rem instead of em, because the em has now changed. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* docs: harmonize headings and titlesErik Faye-Lund2019-05-0812-23/+23
| | | | | | | | | | | | | We're pretty insonsistent in what the headings and titles are, especially compared to what the articles are listed as in the sidebar. Let's harmonize this. There's a notable exception for meson.html, where the sidebar uses a short-hand form that makes sense in the sidebar, but not in the article due to the visible context being different. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* docs: renumber headingsErik Faye-Lund2019-05-0810-83/+87
| | | | | | | | | | | | It's generally frowned upon to have multiple H1 headings in HTML4. So let's make sure each article has a primary heading for the article, and that that heading is the title that is used in the sidebar. While we're at it, let's update the title in the articles to match the title from the sidebar as well. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* docs: give download-article a primary headingErik Faye-Lund2019-05-081-5/+7
| | | | | | | | | | | | It's generally frowned upon to have multiple H1 headings in HTML4. So let's add a primary heading for the article, and source that from the title used in the sidebar. While we're at it, let's update the title in the article to match the title from the sidebar as well. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* docs: use title-casing for all headings in sidebarErik Faye-Lund2019-05-081-10/+10
| | | | | | | | | We generally use title-casing for headings in the sidebar. But not all headings was constently cased like that. Let's make sure this is consistent. Signed-off-by: Erik Faye-Lund <[email protected]> Acked-by: Eric Engestrom <[email protected]>
* docs: spell out "and" in sidebarErik Faye-Lund2019-05-081-3/+3
| | | | | | | | | There's no need to keep this short, we can just spell out "and" here. Besides, a slash kind of implies "or", but these articles are about both of these, not either. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* docs: remove pointless list-entryErik Faye-Lund2019-05-081-1/+0
| | | | | | | | It's quite visible that there's more docs below, we don't need to spell it out for the reader. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* docs: spell out faq in sidebarErik Faye-Lund2019-05-081-1/+1
| | | | | | | | We're not short on space here, so there's little point in abbreviating this. This also matches the heading in the article. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* docs: spell out "and" in sidebarErik Faye-Lund2019-05-081-1/+1
| | | | | | | | | We're not short on space here, so let's just spell out "and" instead of using the ampersand. This is more consistent with the entry above in the sidebar. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* glsl_to_nir: remove unused type_is_int()Timothy Arceri2019-05-081-9/+0
| | | | | | This was missed in e00fa99b08b3. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* Revert "glx: Fix synthetic error generation in __glXSendError"Timothy Arceri2019-05-081-2/+2
| | | | | | | | | | | This reverts commit e91ee763c378d03883eb88cf0eadd8aa916f7878. This seems to have broken a number of wine games. Lets revert everything for now and try again later. Acked-by: Adam Jackson <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110632 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110590
* radeonsi: add an AMD_TEX_ANISO environment variableTimothy Arceri2019-05-081-0/+4
| | | | | | | This brings it inline with the recently added AMD_DEBUG. Reviewed-by: Marek Olšák <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109619
* i965: leave the top 4Gb of the high heap VMA unusedKenneth Graunke2019-05-071-1/+5
| | | | | | | | This ports commit 9e7b0988d6e98690eb8902e477b51713a6ef9cae from anv to i965. Thanks to Lionel for noticing that it was missing! Fixes: 01058a55229 i965: Add virtual memory allocator infrastructure to brw_bufmgr. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Force VMA alignment to be a multiple of the page size.Kenneth Graunke2019-05-071-0/+2
| | | | | | | This should happen regardless, but let's be paranoid. Fixes: 01058a55229 i965: Add virtual memory allocator infrastructure to brw_bufmgr. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Fix BRW_MEMZONE_LOW_4G heap size.Kenneth Graunke2019-05-071-1/+4
| | | | | | | | | | The STATE_BASE_ADDRESS "Size" fields can only hold 0xfffff in pages, and 0xfffff * 4096 = 4294963200, which is 1 page shy of 4GB. So we can't use the top page. Fixes: 01058a55229 i965: Add virtual memory allocator infrastructure to brw_bufmgr. Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: Unset flag reg when FB write is not predicatedMatt Turner2019-05-071-0/+1
| | | | | | | | | | | In the FS IR we pretend that the instruction is predicated with (+f0.1) just for flag dependency tracking purposes. Since the instruction doesn't support predication before Haswell, we unset the predicate so we should also unset the flag register so that we can round-trip the disassembly. Reviewed-by: Sagar Ghuge <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/disasm: Disassemble immediate value properly for dimSagar Ghuge2019-05-071-3/+12
| | | | | | | | | | On haswell, for dim instruction we encode immediate float value operand into double float, v2: Fix comment (Matt Turner) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/disasm: Disassemble JIP offset for whileSagar Ghuge2019-05-071-1/+2
| | | | | | Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/compiler: Replicate 16 bit immediate value correctlySagar Ghuge2019-05-072-0/+6
| | | | | | | | | | | | For the W or UW (signed or unsigned word) source types, the 16-bit value must be replicated in both the low and high words of the 32-bit immediate value. v2: Fix replication in other places as well V3: fix a few nits (Matt Turner) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/compiler: Print quad value in hex formatSagar Ghuge2019-05-071-1/+1
| | | | | | | | | | Print quad value same as unsigned quad so that we can distinguish in between quater control disassembled values for e.g 1/2/3[Q] and immediate quad value for e.g 1Q. This allows round-tripping through the assembler/disassembler. Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/tools: Add unit tests for assemblerSagar Ghuge2019-05-07595-0/+28757
| | | | | | | | | v1: Pass executable object from meson to test(Dylan Baker) v2: Ignore generated output files from git status(Matt Turner) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* intel/tools: Initialize offset correctly for i965_asmMika Kuoppala2019-05-071-10/+7
| | | | | | | | | | If we leave offset uninitialized, access to store will be random depending on stack value and can segfault. Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Sagar Ghuge <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/tools: Add meson pthread dependancy for i965_asmMika Kuoppala2019-05-071-0/+1
| | | | | | Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Sagar Ghuge <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel/tools: New i965 instruction assembler toolSagar Ghuge2019-05-075-0/+3040
| | | | | | | | | | | | | | Tool is inspired from igt's assembler tool. Thanks to Matt Turner, who mentored me through out this project. v2: Fix memory leaks and naming convention (Caio) v3: Fix meson changes (Dylan Baker) v4: Fix usage options (Matt Turner) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Dylan Baker <[email protected]> Reviewed-by: Matt Turner <[email protected]> Closes: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/141
* iris: Also handle res->offset for buffer sampler/image viewsKenneth Graunke2019-05-071-8/+9
|
* iris: support dmabuf imports with offsetsMike Blumenkrantz2019-05-074-12/+12
| | | | | | | | | this adds support for imports where the image data begins at an offset from the start of the buffer, as used in h/x264 fixes kwg/mesa#47 Reviewed-by: Kenneth Graunke <[email protected]>
* gallivm: fix broken 8-wide s3tc decodingRoland Scheidegger2019-05-071-17/+15
| | | | | | | | | | | | | | | | | | Brian noticed there was an uninitialized var for the 8-wide case and 128 bit blocks, which made it always crash. Likewise, the 64bit block case had another crash bug due to type mismatch. Color decode (used for all s3tc formats) also had a bogus shuffle for this case, leading to decode artifacts. Fix these all up, which makes the code actually work 8-wide. Note that it's still not used - I've verified it works, and the generated assembly does look quite a bit simpler actually (20-30% less instructions for the s3tc decode part with avx2), however in practice it still seems to be sligthly slower for some unknown reason (tested with openarena) on my haswell box, so for now continue to split things into 4-wide vectors before decoding. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* docs: Add relnotes stub for 19.2Juan A. Suarez Romero2019-05-071-0/+59
| | | | Signed-off-by: Juan A. Suarez Romero <[email protected]>
* Bump version for 19.1 branchJuan A. Suarez Romero2019-05-071-1/+1
| | | | Signed-off-by: Juan A. Suarez Romero <[email protected]>
* lima: enable sin and cos lowering for GPVasily Khoruzhick2019-05-071-0/+1
| | | | | | | | GP doesn't support sin/cos natively, so we have to lower them. Reviewed-by: Qiang Yu <[email protected]> Tested-by: Qiang Yu <[email protected]> Signed-off-by: Vasily Khoruzhick <[email protected]>
* nir: implement lowering for fsin and fcosVasily Khoruzhick2019-05-074-0/+142
| | | | | | | | | | | | | Lower sin and cos using Nick's fast sin/cos approximation from https://web.archive.org/web/20180105155939/http://forum.devmaster.net/t/fast-and-accurate-sine-cosine/9648 It's suitable for GLES2, but it throws warnings in dEQP GLES3 precision tests. Reviewed-by: Connor Abbott <[email protected]> Reviewed-by: Qiang Yu <[email protected]> Tested-by: Qiang Yu <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Signed-off-by: Vasily Khoruzhick <[email protected]>
* freedreno/ir3: move const_state to ir3_shaderRob Clark2019-05-0710-30/+33
| | | | | | | | | | | | | | | | | | | For a6xx, we construct/emit a single VS const state used for both binning pass and draw pass. So far we were mostly getting lucky that there were not (obvious) mismatches between the const_state (like different lowered immediates) between the binning and draw pass VS ir3_shader_variant. And I guess this situation will come up more as GS and tess is added into the equation. Since really everything about the const state is not specific to the variant, move this. The main exception is lowered immediates, but these are the last to appear in the layout, and it doesn't hurt for each new shader variant to just append any immed's it lowers to the end of the immediate state. Signed-off-by: Rob Clark <[email protected]>
* freedreno/ir3: split out const_state setupRob Clark2019-05-073-52/+61
| | | | | | | Next patch moves const_state to ir3_shader, before the compile context is created. So move the code around in prep to call it earlier. Signed-off-by: Rob Clark <[email protected]>
* freedreno/ir3: move immediates to const_stateRob Clark2019-05-075-30/+29
| | | | | | | They are really part of the constant state, and it will moving things from ir3_shader_variant to ir3_shader if we combine them. Signed-off-by: Rob Clark <[email protected]>
* freedreno/ir3: consolidate const stateRob Clark2019-05-079-90/+113
| | | | | | | | Combine the offsets of differenet parts of the constant space with (what was formerly known as) ir3_driver_const_layout. Bunch of churn, but no functional change. Signed-off-by: Rob Clark <[email protected]>
* freedreno/ir3: move ir3_pointer_size()Rob Clark2019-05-074-9/+9
| | | | | | | | Move to ir3_compiler so it doesn't depend on the compile context. Prep work for moving constant state from variant (where we have compile context) to shader (where we do not). Signed-off-by: Rob Clark <[email protected]>
* vulkan/overlay-layer: fix cast errorsLionel Landwerlin2019-05-071-7/+7
| | | | | | | | | | | Not quite sure what version of GCC/Clang produces errors (8.3.0 locally was fine). v2: also fix an integer literal issue (Karol) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> (v1) Reviewed-by: Eric Engestrom <[email protected]>
* anv: fix alphaToCoverage when there is no color attachmentSamuel Iglesias Gonsálvez2019-05-071-10/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are tests in CTS for alpha to coverage without a color attachment that are failing. This happens because we remove the shader color outputs when we don't have a valid color attachment for them, but when alpha to coverage is enabled we still want to preserve the the output at location 0 since we need the alpha component. In that case we will also need to create a null render target for RT 0. v2: - We already create a null rt when we don't have any, so reuse that for this case (Jason) - Simplify the code a bit (Iago) v3: - Take alpha to coverage from the key and don't tie this to depth-only rendering only, we want the same behavior if we have multiple render targets but the one at location 0 is not used. (Jason). - Rewrite commit message (Iago) v4: - Make sure we take into account the array length of the shader outputs, which we were no handling correctly either and make sure we also create null render targets for any invalid array entries too. v5: - Simplify removal of unused outputs by using rt_used[] so we don't have to special case alpha to coverage there too. Fixes the following CTS tests: dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.* Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Signed-off-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: Don't always require precise lowering of flrpIan Romanick2019-05-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No changes on any other Intel platforms. Iron Lake and GM45 had similar results. (Iron Lake shown) total instructions in shared programs: 8164367 -> 8135551 (-0.35%) instructions in affected programs: 3271235 -> 3242419 (-0.88%) helped: 13636 HURT: 90 helped stats (abs) min: 1 max: 30 x̄: 2.13 x̃: 1 helped stats (rel) min: 0.04% max: 10.77% x̄: 1.16% x̃: 0.97% HURT stats (abs) min: 1 max: 4 x̄: 1.80 x̃: 2 HURT stats (rel) min: 0.26% max: 11.11% x̄: 1.76% x̃: 0.78% 95% mean confidence interval for instructions value: -2.13 -2.07 95% mean confidence interval for instructions %-change: -1.16% -1.13% Instructions are helped. total cycles in shared programs: 188719974 -> 188586222 (-0.07%) cycles in affected programs: 70415766 -> 70282014 (-0.19%) helped: 12563 HURT: 515 helped stats (abs) min: 2 max: 600 x̄: 10.90 x̃: 6 helped stats (rel) min: <.01% max: 5.48% x̄: 0.48% x̃: 0.27% HURT stats (abs) min: 2 max: 54 x̄: 6.07 x̃: 4 HURT stats (rel) min: 0.01% max: 4.48% x̄: 0.24% x̃: 0.08% 95% mean confidence interval for cycles value: -10.56 -9.90 95% mean confidence interval for cycles %-change: -0.47% -0.45% Cycles are helped. LOST: 0 GAINED: 13 Reviewed-by: Matt Turner <[email protected]>
* nir/algebraic: Reassociate open-coded flrp(1, b, c)Ian Romanick2019-05-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a previous verion of this patch, Jason commented, "Re-associating based on whether or not something has a constant value of 1.0 seems a bit sneaky. I think it's well within the rules but it seems like something that could bite you." That is possibly true. The reassociation will generate different results if fabs(b) >= 2**24 and fabs(c) < 0.5. The delta increases as fabs(c) approaches 0. However, i965 has done this same reassociation indirectly for years. We would previously allow nir_op_flrp on all pre-Gen11 hardware even though Gen4 and Gen5 do not have a LRP instruction. Optimizations in nir_opt_algebraic would convert expressions like a+c(b-a) into flrp(a, b, c). On Gen7+, the hardware performs the same arithmetic as a(1-c)+bc. Gen6 seems to implement LRP as a+c(b-a). On Gen4 and Gen5, we would lower LRP to a sequence of instructions that implement a(1-c)+bc. The lowering happens after all constant folding, so we would litterally generate a 1+(-1) instruction sequence in this scenario: one instruction to load either 1 or -1 in a register, and another instruction to add either -1 or 1 to it. This patch just cuts out the middle man. Do the reassociation that we've always done, but do it explicitly at a time when we can benefit from other optimizations. A few cases that were hurt by "nir: Lower flrp(±1, b, c) and flrp(a, ±1, c) differently" are restored by this patch. This includes a few shaders in ET:QW. I tried a similar thing for open-coded flrp(-1, b, c), and it hurt instructions on 35 shaders for ILK without helping any. The helped / hurt cycles was about even. No changes on any other Intel platforms. Iron Lake and GM45 had similar results. (Iron Lake shown) total instructions in shared programs: 8172020 -> 8164367 (-0.09%) instructions in affected programs: 1089851 -> 1082198 (-0.70%) helped: 3285 HURT: 64 helped stats (abs) min: 1 max: 6 x̄: 2.35 x̃: 2 helped stats (rel) min: 0.13% max: 12.00% x̄: 1.15% x̃: 0.83% HURT stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 HURT stats (rel) min: 0.24% max: 0.64% x̄: 0.39% x̃: 0.38% 95% mean confidence interval for instructions value: -2.32 -2.25 95% mean confidence interval for instructions %-change: -1.16% -1.09% Instructions are helped. total cycles in shared programs: 188758338 -> 188719974 (-0.02%) cycles in affected programs: 20004922 -> 19966558 (-0.19%) helped: 3012 HURT: 477 helped stats (abs) min: 2 max: 142 x̄: 13.41 x̃: 12 helped stats (rel) min: 0.01% max: 6.37% x̄: 0.52% x̃: 0.24% HURT stats (abs) min: 2 max: 328 x̄: 4.27 x̃: 4 HURT stats (rel) min: <.01% max: 1.55% x̄: 0.14% x̃: 0.11% 95% mean confidence interval for cycles value: -11.38 -10.62 95% mean confidence interval for cycles %-change: -0.46% -0.41% Cycles are helped. Reviewed-by: Matt Turner <[email protected]>
* nir/flrp: Lower flrp(a, b, #c) differentlyIan Romanick2019-05-061-0/+17
| | | | | | | | | This doesn't help on Intel GPUs now because we always take the "always_precise" path first. It may help on other GPUs, and it does prevent a bunch of regressions in "intel/compiler: Don't always require precise lowering of flrp". Reviewed-by: Matt Turner <[email protected]>
* nir/flrp: Lower flrp(a, b, c) differently if another flrp(_, b, c) existsIan Romanick2019-05-061-1/+56
| | | | | | | | | | | | | | | | | | | | | | There is little effect on Intel GPUs now because we almost always take the "always_precise" path first. It may help on other GPUs, and it does prevent a bunch of regressions in "intel/compiler: Don't always require precise lowering of flrp". No changes on any other Intel platforms. GM45 and Iron Lake had similar results. (Iron Lake shown) total cycles in shared programs: 188852500 -> 188852484 (<.01%) cycles in affected programs: 14612 -> 14596 (-0.11%) helped: 4 HURT: 0 helped stats (abs) min: 4 max: 4 x̄: 4.00 x̃: 4 helped stats (rel) min: 0.09% max: 0.13% x̄: 0.11% x̃: 0.11% 95% mean confidence interval for cycles value: -4.00 -4.00 95% mean confidence interval for cycles %-change: -0.13% -0.09% Cycles are helped. Reviewed-by: Matt Turner <[email protected]>
* nir/flrp: Lower flrp(a, b, c) differently if another flrp(a, _, c) existsIan Romanick2019-05-061-0/+89
| | | | | | | | | | | | This doesn't help on Intel GPUs now because we always take the "always_precise" path first. It may help on other GPUs, and it does prevent a bunch of regressions in "intel/compiler: Don't always require precise lowering of flrp". No changes on any Intel platform. Before a number of large rebases this helped cycles in a couple shaders on Iron Lake and GM45. Reviewed-by: Matt Turner <[email protected]>
* nir/flrp: Lower flrp(±1, b, c) and flrp(a, ±1, c) differentlyIan Romanick2019-05-061-0/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No changes on any other Intel platforms. v2: Rebase on 424372e5dd5 ("nir: Use the flrp lowering pass instead of nir_opt_algebraic") Iron Lake and GM45 had similar results. (Iron Lake shown) total instructions in shared programs: 8189888 -> 8153912 (-0.44%) instructions in affected programs: 1199037 -> 1163061 (-3.00%) helped: 4124 HURT: 10 helped stats (abs) min: 1 max: 40 x̄: 8.73 x̃: 9 helped stats (rel) min: 0.20% max: 86.96% x̄: 4.96% x̃: 3.02% HURT stats (abs) min: 1 max: 2 x̄: 1.20 x̃: 1 HURT stats (rel) min: 1.06% max: 3.92% x̄: 1.62% x̃: 1.06% 95% mean confidence interval for instructions value: -8.84 -8.56 95% mean confidence interval for instructions %-change: -5.12% -4.77% Instructions are helped. total cycles in shared programs: 188606710 -> 188426964 (-0.10%) cycles in affected programs: 27505596 -> 27325850 (-0.65%) helped: 4026 HURT: 77 helped stats (abs) min: 2 max: 646 x̄: 44.99 x̃: 46 helped stats (rel) min: <.01% max: 94.58% x̄: 2.35% x̃: 0.85% HURT stats (abs) min: 2 max: 376 x̄: 17.79 x̃: 6 HURT stats (rel) min: <.01% max: 2.60% x̄: 0.22% x̃: 0.04% 95% mean confidence interval for cycles value: -44.75 -42.87 95% mean confidence interval for cycles %-change: -2.44% -2.17% Cycles are helped. LOST: 3 GAINED: 35 Reviewed-by: Matt Turner <[email protected]>
* nir/flrp: Lower flrp(#a, #b, c) differentlyIan Romanick2019-05-061-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the magnitudes of #a and #b are such that (b-a) won't lose too much precision, lower as a+c(b-a). No changes on any other Intel platforms. v2: Rebase on 424372e5dd5 ("nir: Use the flrp lowering pass instead of nir_opt_algebraic") Iron Lake and GM45 had similar results. (Iron Lake shown) total instructions in shared programs: 8192503 -> 8192383 (<.01%) instructions in affected programs: 18417 -> 18297 (-0.65%) helped: 68 HURT: 0 helped stats (abs) min: 1 max: 18 x̄: 1.76 x̃: 1 helped stats (rel) min: 0.19% max: 7.89% x̄: 1.10% x̃: 0.43% 95% mean confidence interval for instructions value: -2.48 -1.05 95% mean confidence interval for instructions %-change: -1.56% -0.63% Instructions are helped. total cycles in shared programs: 188662536 -> 188661956 (<.01%) cycles in affected programs: 744476 -> 743896 (-0.08%) helped: 62 HURT: 0 helped stats (abs) min: 4 max: 60 x̄: 9.35 x̃: 6 helped stats (rel) min: 0.02% max: 4.84% x̄: 0.27% x̃: 0.06% 95% mean confidence interval for cycles value: -12.37 -6.34 95% mean confidence interval for cycles %-change: -0.48% -0.06% Cycles are helped. Reviewed-by: Matt Turner <[email protected]>
* intel/compiler: Use the flrp lowering pass for all stages on Gen4 and Gen5Ian Romanick2019-05-062-16/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously lower_flrp32 was only set for vertex shaders. Fragment shaders performed a(1-c)+bc lowering during code generation. The shaders with loops hurt are SIMD8 and SIMD16 shaders for a text-identical fragment shader. v2: Rebase on 26391cceaa1 ("intel/compiler: Lower ffma on Gen4 and Gen5"). v3: Rebase on a004e95dd73 ("radeonsi/nir: create si_nir_opts() helper") Iron Lake total instructions in shared programs: 8211385 -> 8185974 (-0.31%) instructions in affected programs: 2503898 -> 2478487 (-1.01%) helped: 9936 HURT: 921 helped stats (abs) min: 1 max: 155 x̄: 2.86 x̃: 2 helped stats (rel) min: 0.10% max: 35.48% x̄: 1.67% x̃: 1.11% HURT stats (abs) min: 1 max: 12 x̄: 3.24 x̃: 2 HURT stats (rel) min: 0.21% max: 13.64% x̄: 1.86% x̃: 0.89% 95% mean confidence interval for instructions value: -2.43 -2.25 95% mean confidence interval for instructions %-change: -1.41% -1.33% Instructions are helped. total cycles in shared programs: 188523186 -> 188401198 (-0.06%) cycles in affected programs: 71541604 -> 71419616 (-0.17%) helped: 11649 HURT: 1871 helped stats (abs) min: 2 max: 930 x̄: 12.62 x̃: 6 helped stats (rel) min: <.01% max: 44.61% x̄: 0.68% x̃: 0.25% HURT stats (abs) min: 2 max: 138 x̄: 13.38 x̃: 8 HURT stats (rel) min: <.01% max: 10.99% x̄: 0.49% x̃: 0.17% 95% mean confidence interval for cycles value: -9.42 -8.63 95% mean confidence interval for cycles %-change: -0.54% -0.50% Cycles are helped. total loops in shared programs: 852 -> 856 (0.47%) loops in affected programs: 0 -> 4 helped: 0 HURT: 4 HURT stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1 HURT stats (rel) min: 0.00% max: 0.00% x̄: 0.00% x̃: 0.00% 95% mean confidence interval for loops value: 1.00 1.00 95% mean confidence interval for loops %-change: 0.00% 0.00% Loops are HURT. LOST: 3 GAINED: 12 GM45 total instructions in shared programs: 5046407 -> 5033694 (-0.25%) instructions in affected programs: 1303584 -> 1290871 (-0.98%) helped: 5010 HURT: 464 helped stats (abs) min: 1 max: 155 x̄: 2.85 x̃: 2 helped stats (rel) min: 0.10% max: 34.38% x̄: 1.63% x̃: 1.08% HURT stats (abs) min: 1 max: 75 x̄: 3.39 x̃: 2 HURT stats (rel) min: 0.20% max: 13.04% x̄: 1.84% x̃: 0.87% 95% mean confidence interval for instructions value: -2.45 -2.20 95% mean confidence interval for instructions %-change: -1.40% -1.28% Instructions are helped. total cycles in shared programs: 128889476 -> 128812366 (-0.06%) cycles in affected programs: 44845402 -> 44768292 (-0.17%) helped: 6079 HURT: 940 helped stats (abs) min: 2 max: 930 x̄: 15.16 x̃: 8 helped stats (rel) min: <.01% max: 41.03% x̄: 0.71% x̃: 0.25% HURT stats (abs) min: 2 max: 138 x̄: 16.01 x̃: 8 HURT stats (rel) min: <.01% max: 10.99% x̄: 0.50% x̃: 0.17% 95% mean confidence interval for cycles value: -11.63 -10.34 95% mean confidence interval for cycles %-change: -0.58% -0.52% Cycles are helped. total loops in shared programs: 633 -> 635 (0.32%) loops in affected programs: 0 -> 2 helped: 0 HURT: 2 total spills in shared programs: 60 -> 69 (15.00%) spills in affected programs: 54 -> 63 (16.67%) helped: 0 HURT: 1 total fills in shared programs: 92 -> 105 (14.13%) fills in affected programs: 80 -> 93 (16.25%) helped: 0 HURT: 1 LOST: 15 GAINED: 15 Reviewed-by: Jason Ekstrand <[email protected]> [v2] Reviewed-by: Matt Turner <[email protected]> [v2]
* nir: Use the flrp lowering pass instead of nir_opt_algebraicIan Romanick2019-05-069-3/+187
| | | | | | | | | | | | | | | | | | | | | | | | | | I tried to be very careful while updating all the various drivers, but I don't have any of that hardware for testing. :( i965 is the only platform that sets always_precise = true, and it is only set true for fragment shaders. Gen4 and Gen5 both set lower_flrp32 only for vertex shaders. For fragment shaders, nir_op_flrp is lowered during code generation as a(1-c)+bc. On all other platforms 64-bit nir_op_flrp and on Gen11 32-bit nir_op_flrp are lowered using the old nir_opt_algebraic method. No changes on any other Intel platforms. v2: Add panfrost changes. Iron Lake and GM45 had similar results. (Iron Lake shown) total cycles in shared programs: 188647754 -> 188647748 (<.01%) cycles in affected programs: 5096 -> 5090 (-0.12%) helped: 3 HURT: 0 helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2 helped stats (rel) min: 0.12% max: 0.12% x̄: 0.12% x̃: 0.12% Reviewed-by: Matt Turner <[email protected]>
* nir/flrp: Add new lowering pass for flrp instructionsIan Romanick2019-05-064-0/+293
| | | | | | | | | | | | This pass will soon grow to include some optimizations that are difficult or impossible to implement correctly within nir_opt_algebraic. It also include the ability to generate strictly correct code which the current nir_opt_algebraic lowering lacks (though that could be changed). v2: Document the parameters to nir_lower_flrp. Rebase on top of 3766334923e ("compiler/nir: add lowering for 16-bit flrp") Reviewed-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 20:27:25 +0000