summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* st/clover: provide a path for drivers to call through to pfn_notifyIlia Mirkin2015-11-054-4/+36
| | | | | | | Signed-off-by: Ilia Mirkin <[email protected]> [ Francisco Jerez: Clean up clover::context interface by passing around a function object. ]
* st/mesa: set debug callback for debug contextsIlia Mirkin2015-11-051-0/+57
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* gallium: expose a debug message callback settable by context ownerIlia Mirkin2015-11-056-0/+82
| | | | | | | This will allow gallium drivers to send messages to KHR_debug endpoints Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: account for texture views when doing CopyImageSubDataIlia Mirkin2015-11-051-0/+8
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i965/fs: Do not mark used surfaces in FS_OPCODE_GET_BUFFER_SIZEIago Toral Quiroga2015-11-052-4/+4
| | | | | | | | Do it in the visitor, like we do for other opcodes. v2: use const, get rid of useless surf_index temporary (Curro) Reviewed-by: Francisco Jerez <[email protected]>
* i965/vec4: Do not mark used surfaces in VS_OPCODE_GET_BUFFER_SIZEIago Toral Quiroga2015-11-052-5/+5
| | | | | | | | Do it in the visitor, like we do for other opcodes. v2: use const, get rid of useless surf_index temporary (Curro) Reviewed-by: Francisco Jerez <[email protected]>
* i965/vec4: Do not mark used direct surfaces in VS_OPCODE_PULL_CONSTANT_LOADIago Toral Quiroga2015-11-053-13/+8
| | | | | | | | | | Right now the generator marks direct surfaces as used but leaves marking of indirect surfaces to the caller. Just make the callers handle marking in both cases for consistency. v2: Use const, do not add unnecessary temporary (Curro) Reviewed-by: Francisco Jerez <[email protected]>
* i965/fs: Do not mark used direct surfaces in UNIFORM_PULL_CONSTANT_LOADIago Toral Quiroga2015-11-052-11/+1
| | | | | | | | Right now the generator marks direct surfaces as used but leaves marking of indirect surfaces to the caller. Just make the callers handle marking in both cases for consistency. Reviewed-by: Francisco Jerez <[email protected]>
* i965/fs: Do not mark direct used surfaces in VARYING_PULL_CONSTANT_LOADIago Toral Quiroga2015-11-053-13/+8
| | | | | | | | | | Right now the generator marks direct surfaces as used but leaves marking of indirect surfaces to the caller. Just make the callers handle marking in both cases for consistency. v2: Use const and remove useless surf_index temporary (Curro) Reviewed-by: Francisco Jerez <[email protected]>
* i965/skl+: Enable support for 16x multisamplingNeil Roberts2015-11-052-1/+10
| | | | Reviewed-by: Ben Widawsky <[email protected]>
* mesa/meta: Use interpolateAtOffset for 16x MSAA copy blitNeil Roberts2015-11-051-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | Previously there was a problem in i965 where if 16x MSAA is used then some of the sample positions are exactly on the 0 x or y axis. When the MSAA copy blit shader interpolates the texture coordinates at these sample positions it was possible that it would jump to a neighboring texel due to rounding errors. It is likely that these positions would be used on 16x MSAA because that is where they are defined to be in D3D. To fix that this patch makes it use interpolateAtOffset in the blit shader whenever 16x MSAA is used and the GL_ARB_gpu_shader5 extension is available. This forces it to interpolate the texture coordinates at the pixel center to avoid these problematic positions. This fixes ext_framebuffer_multisample-unaligned-blit and ext_framebuffer_multisample-clip-and-scissor-blit with 16x MSAA on SKL+. v2: Use interpolateAtOffset instead of interpolateAtSample v3: Always try to enable GL_ARB_gpu_shader5 in the shader [Ian Romanick] Reviewed-by: Anuj Phogat <[email protected]>
* meta/blit: Always try to enable GL_ARB_sample_shadingNeil Roberts2015-11-051-14/+2
| | | | | | | | | | | Previously this extension was only enabled when blitting between two multisampled buffers. However I don't think it does any harm to just enable it all the time. The ‘enable’ option is used instead of ‘require’ so that the shader will still compile if the extension isn't available in the cases where it isn't used. This will make the next patch simpler because it wants to add another optional extension. Reviewed-by: Anuj Phogat <[email protected]>
* meta: Support 16x MSAA in the multisample scaled blit shaderNeil Roberts2015-11-054-11/+49
| | | | | | v2: Fix the x_scale in the shader. Remove the doubts in the commit message. Reviewed-by: Anuj Phogat <[email protected]>
* i965/meta: Support 16x MSAA in the meta stencil blitNeil Roberts2015-11-051-5/+17
| | | | | | | The destination rectangle is now drawn at 4x4 the size and the shader code to calculate the sample number is adjusted accordingly. Acked-by: Ben Widawsky <[email protected]>
* i965/fs/skl+: Fix calculating gl_SampleID for 16x MSAANeil Roberts2015-11-051-1/+7
| | | | | | | | In order to accomodate 16x MSAA, the starting sample pair index is now 3 bits rather than 2 on SKL+. Reviewed-by: Ben Widawsky <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965: Support allocating the MCS buffer for 16x MSAANeil Roberts2015-11-051-0/+6
| | | | | | When 16 samples are used the MCS buffer needs 64 bits per pixel. Reviewed-by: Ben Widawsky <[email protected]>
* i965: Support calculating the bits needed to set up 16x MSAANeil Roberts2015-11-051-1/+1
| | | | | | | The gen7_surface_msaa_bits function already returns the right values for 16 samples but it just needs its assert to be relaxed. Reviewed-by: Ben Widawsky <[email protected]>
* i965/fs: Add a sampler program key for whether the texture is 16x MSAANeil Roberts2015-11-053-1/+16
| | | | | | | | | | | | | | | | When 16x MSAA is used for sampling with texelFetch the compiler needs to use a different instruction which passes more arguments for the MCS data. Previously on skl+ it was unconditionally using this new instruction. However since 16x MSAA is probably going to be pretty rare, it is probably worthwhile to avoid using this instruction for the other sample counts. In order to do that this patch adds a new member to brw_sampler_prog_key_data to track when a sampler refers to a buffer with 16 samples. Note that this isn't done for the vec4 backend because it wouldn't change how many registers it uses. Acked-by: Ben Widawsky <[email protected]>
* i965/vec4/skl+: Use ld2dms_w instead of ld2dmsNeil Roberts2015-11-053-2/+18
| | | | | | | | | In order to support 16x MSAA, skl+ has a wider version of ld2dms that takes two parameters for the MCS data. The MCS data in the response still fits in a single register so we just need to ensure we copy both values rather than just the lower one. Acked-by: Ben Widawsky <[email protected]>
* i965/fs/skl+: Use ld2dms_w instead of ld2dmsNeil Roberts2015-11-056-5/+60
| | | | | | | | | | | | In order to support 16x MSAA, skl+ has a wider version of ld2dms that takes two parameters for the MCS data. The MCS data retrieved from the ld_mcs instruction already returns 4 or 8 registers and is documented to return zeroes for the mcsh value when the sample count is less than 16. v2: Use get_lowered_simd_width to fall back to SIMD8 instructions when the message length would be too long in SIMD16. Reviewed-by: Ben Widawsky <[email protected]>
* i965: Program 16x MSAA sample positions.Neil Roberts2015-11-053-7/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the standard pattern used by the other 3D graphics API. BDW has slots for these values, but they aren't actually used until SKL. Even though the documentation for BDW says they must be zero, it doesn't seem to cause any harm to program them anyway. The comment above for the 8x sample positions says that the hardware implements centroid interpolation by picking the centre-most sample that is inside the primitive. That implies that it might be worthwhile to pick a pattern that includes 0.5,0.5. However by experimentation this doesn't seem to actually be the case. With the sample positions in this patch, if I modify the piglit test below so that it instead reports the centroid position, it reports 0.492188,0.421875 which doesn't match any of the positions. If I modify the sample positions so that they include one at exactly 0.5,0.5 it doesn't help and it reports another position which is even further from the center for some reason. arb_gpu_shader5-interpolateAtSample-different Kenneth Graunke experimented with some other patterns that have a higher standard deviation but I think after some discussion it was decided that it would be better to pick the same pattern as the other graphics API in case there are games that rely on this pattern. (Based on a patch by Kenneth Graunke) Cc: Kenneth Graunke <[email protected]> Reviewed-by: Ben Widawsky <ben at bwidawsk.net>
* i965: Handle 16x MSAA in IMS dimension munging code.Kenneth Graunke2015-11-051-2/+6
| | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Neil Roberts <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* nir: Rename nir_live_variables.c to nir_liveness.c.Kenneth Graunke2015-11-052-1/+1
| | | | | | It doesn't actually operate on variables. Reviewed-by: Jason Ekstrand <[email protected]>
* nir: Rename live_variables to live_ssa_defs.Kenneth Graunke2015-11-057-14/+14
| | | | | | | This computes liveness of SSA values, not nir_variables. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/vec4: select predicate based on writemask for sel emissionsAlejandro Piñeiro2015-11-051-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Equivalent to commit 8ac3b525c but with sel operations. In this case we select the PredCtrl based on the writemask. This patch helps on cases like this: 1: cmp.l.f0.0 vgrf40.0.x:F, vgrf0.zzzz:F, vgrf7.xxxx:F 2: cmp.nz.f0.0 null:D, vgrf40.xxxx:D, 0D 3: (+f0.0) sel vgrf41.0.x:UD, vgrf6.xxxx:UD, vgrf5.xxxx:UD In this case, cmod propagation can't optimize instruction #2, because instructions #1 and #2 have different writemasks, and we can't update directly instruction #2 writemask because our code thinks that sel at instruction #3 reads all four channels of the flag, when it actually only reads .x. So, with this patch, the previous case becames this: 1: cmp.l.f0.0 vgrf40.0.x:F, vgrf0.zzzz:F, vgrf7.xxxx:F 2: cmp.nz.f0.0 null:D, vgrf40.xxxx:D, 0D 3: (+f0.0.x) sel vgrf41.0.x:UD, vgrf6.xxxx:UD, vgrf5.xxxx:UD Now only the x channel of the flag is used, allowing dead code eliminate to update the writemask at the second instruction: 1: cmp.l.f0.0 vgrf40.0.x:F, vgrf0.zzzz:F, vgrf7.xxxx:F 2: cmp.nz.f0.0 null.x:D, vgrf40.xxxx:D, 0D 3: (+f0.0.x) sel vgrf41.0.x:UD, vgrf6.xxxx:UD, vgrf5.xxxx:UD So now cmod propagation can simplify out #2: 1: cmp.l.f0.0 vgrf40.0.x:F, attr18.wwww:F, vgrf7.xxxx:F 2: (+f0.0.x) sel vgrf41.0.x:UD, vgrf6.xxxx:UD, vgrf5.xxxx:UD Shader-db numbers: total instructions in shared programs: 6235835 -> 6228008 (-0.13%) instructions in affected programs: 219850 -> 212023 (-3.56%) total loops in shared programs: 1979 -> 1979 (0.00%) helped: 1192 HURT: 0
* nouveau: relax fence emit space assertIlia Mirkin2015-11-043-3/+3
| | | | | | | | | We also have the "reserved for kick" space available. Some of my earlier changes can probably be removed, but this is a quick fix for some of the rarer fallout. Signed-off-by: Ilia Mirkin <[email protected]> Cc: <[email protected]>
* vc4: When the create ioctl fails, free our cache and try again.Eric Anholt2015-11-041-5/+24
| | | | | | | | | This greatly increases the pressure you can put on the driver before create fails. Ultimately we need to let the kernel take control of our cached BOs and just take them from us (and other clients) directly, but this is a very easy patch for the moment. Cc: "11.0" <[email protected]>
* vc4: Print the rounded shader size in debug output.Eric Anholt2015-11-041-1/+1
| | | | | It's surprising to see "0kb" printed for debug on short shaders, while 4kb alignment won't be suprising.
* vc4: Fix dumping the size of BOs allocated/cached.Eric Anholt2015-11-041-2/+2
| | | | 60MB of cached BOs are a lot less scary than 600MB.
* mesa/tests: add glBufferStorageEXT to ES 3.1 dispatch listIlia Mirkin2015-11-041-0/+3
| | | | | | | | | | I thought that aliased functions didn't need to be added, but that might only be if the function aliases something in the same {desktop,ES} space. Resolves the dispatch sanity test failure. Fixes: 13b19aa81 (mesa: expose support for GL_EXT_buffer_storage) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92824 Signed-off-by: Ilia Mirkin <[email protected]>
* vbo: fix another GL_LINE_LOOP bugBrian Paul2015-11-042-2/+10
| | | | | | | | | | | | | | | | | Very long line loops which spanned 3 or more vertex buffers were not handled correctly and could result in stray lines. The piglit lineloop test draws 10000 vertices by default, and is not long enough to trigger this. Even 'lineloop -count 100000' doesn't trigger the bug. For future reference, the issue can be reproduced by changing Mesa's VBO_VERT_BUFFER_SIZE to 4096 and changing the piglit lineloop test to use glVertex2f(), draw 3 loops instead of 1, and specifying -count 1023. Acked-by: Sinclair Yeh <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* svga: implement 'white_fragments' option for VGPU10 fragment shadersBrian Paul2015-11-041-5/+30
| | | | | | | | | | When we emulate XOR logicop mode with blend-subtract, we need to ensure that the fragment shader always emits white. We had this implemented for VGPU9, but not VGPU10. VMware bug 1545492. Reviewed-by: Charmaine Lee <[email protected]>
* u_vbuf: minor code reformatting / line wrappingBrian Paul2015-11-041-4/+8
| | | | Trivial.
* u_vbuf: add some const qualifiersBrian Paul2015-11-041-2/+2
| | | | Trivial.
* svga: use new enum indices_mode typeBrian Paul2015-11-042-2/+4
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* util/indices: replace #define tokens with enum typeBrian Paul2015-11-043-86/+91
| | | | | | To ease debugging in gdb. Reviewed-by: Charmaine Lee <[email protected]>
* i965: check inst->predicate when clearing flag_live at dead code eliminateAlejandro Piñeiro2015-11-042-2/+2
| | | | | | | Detected by Matt Turner while reviewing commit a59359ecd22154cc2b3f88bb8c599f21af8a3934 Reviewed-by: Matt Turner <[email protected]>
* gallivm: fix sampling for s3tc srgb formats when using texture cacheRoland Scheidegger2015-11-041-1/+3
| | | | | | | | | This actually stored the values as 8bit linear values in the cache, then did another srgb->linear conversion... We don't want to do the former (decoding 8bit srgb values to 8bit linear completely defeats the purpose of srgb in the first place), so just decode to 8bit srgb. Fixes piglit.spec.ext_texture_srgb.texwrap formats-s3tc tests.
* i965/meta: Assert fast clears and rep clears never overlapBen Widawsky2015-11-031-0/+2
| | | | | | | | | | | There is nothing wrong with the code today, but as one modifies the code it turns out to be not too difficult to mess up the code, and this easy assertion should catch such driver implementation failures quickly. Cc: Kristian Høgsberg <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Neil Roberts <[email protected]>
* mesa: expose support for GL_EXT_buffer_storageRyan Houdek2015-11-043-0/+11
| | | | | | | | | This extension requires ES 3.1 since it relies on glMemoryBarrier. For testing purposes I temporarily moved glMemoryBarrier to be an ES 3.0 function. This has been tested with the piglit in the ML and the Dolphin emulator. Reviewed-by: Ilia Mirkin <[email protected]>
* glsl: make sure to only add subroutines to resource listTimothy Arceri2015-11-041-1/+2
| | | | | | Over looked in 763cd8c080353. Reviewed-by: Tapani Pälli <[email protected]>
* glsl: remove old TODOTimothy Arceri2015-11-041-5/+0
| | | | | | | SSBO support now exists as of commits f24e5e and f408a13dd30. Reviewed-by: Tapani Pälli <[email protected]> Acked-by: Matt Turner <[email protected]>
* docs: Mark AoA as done for i965Timothy Arceri2015-11-042-2/+3
| | | | Reviewed-by: Ian Romanick <[email protected]>
* i965: enable ARB_arrays_of_arraysTimothy Arceri2015-11-041-0/+1
| | | | Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* i965: add support for image AoATimothy Arceri2015-11-042-14/+18
| | | | | | | | | | | | | V3: clamp array index to the correct size (the size of the current array rather than the inner array) Francisco Jerez. V2: avoid useless zero-initialization and addition for the first AoA level, avoid redundant temporary, make use of type_size_scalar(), rename aoa_size to element_size, assign the indirect indexing temporary directly to image.reladdr, and replace while loop with a for loop. All suggested by Francisco Jerez. Reviewed-by: Francisco Jerez <[email protected]>
* llvmpipe: add cache for compressed texturesRoland Scheidegger2015-11-0419-18/+730
| | | | | | | | | | | | | | | | | | | | | | compressed textures are very slow because decoding is rather complex (and because there's no jit code code to decode them too for non-technical reasons). Thus, add some texture cache which holds a couple of decoded blocks. Right now this handles only s3tc format albeit it could be extended to work with other formats rather trivially as long as the result of decode fits into 32bit per texel (ideally, rgtc actually would decode to more than 8 bits per channel, but even then making it work for it shouldn't be too difficult). This can improve performance noticeably but don't expect wonders (uncompressed is unsurprisingly still faster). It's also possible it might be slower in some cases (using nearest filtering for example or if there's otherwise not many cache hits, the cache is only direct mapped which isn't great). Also, actual decode of a block relies on util code, thus even though always full blocks are decoded it is done texel by texel - this could obviously benefit greatly from simd-optimized code decoding full blocks at once... Note the cache is per (raster) thread, and currently only used for fragment shaders. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: use simple coeffs calc for 128bit vectorsOded Gabbay2015-11-041-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are currently two methods in llvmpipe code to calculate coeffs to be used as inputs for the fragment shader. The two methods use slightly different ways to do the floating point calculations and thus produce slightly different results. The decision which method to use is determined by the size of the vector that is used by the platform. For vectors with size of more than 128bit, a single-step method is used, in which coeffs_init_simple() + attribs_update_simple() are called. For vectors with size of 128bit or less, a two-step method is used, in which coeffs_init() + attribs_update() are called. This causes some piglit tests (clip-distance-bulk-copy, interface-vs-unnamed-to-fs-unnamed) to fail when using platforms with 128bit vectors (such as ppc64le or x86-64 without AVX). This patch makes platforms with 128bit vectors use the single-step method (aka "simple" method) instead of the two-step method. This would make the resulting coeffs identical between more platforms, make sure the piglit tests passes, and make debugging and maintainability a bit easier as the generated LLVM IR will be the same for more platforms. The performance impact is negligible for x86-64 without AVX, and basically non-existent for ppc64le, as it can be seen from the following benchmarking results: - glxspheres, on ppc64le: - original code: 4.892745317 frames/sec 5.460303857 Mpixels/sec - with the patch: 4.932083873 frames/sec 5.504205571 Mpixels/sec - Additional 0.8% performance boost - glxspheres, on x86-64 without AVX: - original code: 20.16418809 frames/sec 22.50323395 Mpixels/sec - with the patch: 20.31328989 frames/sec 22.66963152 Mpixels/sec - Additional 0.74% performance boost - glmark2, on ppc64le: - original code: score of 58 - with my change: score of 57 - glmark2, on x86-64 without AVX: - original code: score of 175 - with the patch: score of 167 - Impact of of -4.5% on performance - OpenArena, on ppc64le: - original code: 3398 frames 1719.0 seconds 2.0 fps 255.0/505.9/2773.0/0.0 ms - with the patch: 3398 frames 1690.4 seconds 2.0 fps 241.0/497.5/2563.0/0.2 ms - 29 seconds faster with the patch, which is about 2% - OpenArena, on x86-64 without AVX: - original code: 3398 frames 239.6 seconds 14.2 fps 38.0/70.5/719.0/14.6 ms - with the patch: 3398 frames 244.4 seconds 13.9 fps 38.0/71.9/697.0/14.3 ms - 0.3 fps slower with the patch (about 2%) Additional details can be found at: http://lists.freedesktop.org/archives/mesa-dev/2015-October/098635.html Signed-off-by: Oded Gabbay <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* nir: Properly invalidate metadata in nir_opt_remove_phis().Kenneth Graunke2015-11-031-0/+5
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]> Cc: [email protected]
* nir: Properly invalidate metadata in nir_lower_vec_to_movs().Kenneth Graunke2015-11-031-0/+5
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]> Cc: [email protected]
* nir: Properly invalidate metadata in nir_opt_copy_prop().Kenneth Graunke2015-11-031-0/+6
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]> Cc: [email protected]
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 09:02:52 +0000