summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/radeon/r600_texture.c
Commit message (Collapse)AuthorAgeFilesLines
* gallium/radeon: make sure the address of separate CMASK is aligned properlyMarek Olšák2016-10-271-2/+3
| | | | | | | | | This should fix random GPU hangs on Hawaii and Fiji. Cc: 11.2 12.0 13.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit dce05b342355eac9296ee7110385b16d6edb059d)
* gallium/radeon: fix incorrect bpe use in si_set_optimal_micro_tile_modeMarek Olšák2016-10-271-7/+7
| | | | | | | | | Oh my god, I wonder what catastrophic issues this was causing on SI. Cc: 13.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (cherry picked from commit 8a21f52d73936e23a314a288a36782a698c7c1b9)
* radeonsi: implement TC-compatible HTILEMarek Olšák2016-10-131-10/+57
| | | | | | | | | | | | | | | | | | | | | so that decompress blits aren't needed and depth texturing needs less memory bandwidth. Z16 and Z24 are promoted to Z32_FLOAT by the driver, because TC-compatible HTILE only supports Z32_FLOAT. This doubles memory footprint for Z16. The format promotion is not visible to state trackers. This is part of TC-compatible renderbuffer compression, which has 3 parts: DCC, HTILE, FMASK. Only TC-compatible FMASK compression is missing now. I don't see a measurable increase in performance though. (I tested Talos Principle and DiRT: Showdown, the latter is improved by 0.5%, which is almost noise, and it originally used layered Z16, so at least we know that Z16 promoted to Z32F isn't slower now) Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium: add missing zero-init for resource templatesRob Clark2016-10-071-0/+1
| | | | | | | Mostly test code, plus one spot I noticed in r600. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: Initialize pipe_resource::next to NULLMichel Dänzer2016-09-281-0/+1
| | | | | | | Fixes lots of piglit tests crashing due to using uninitialized memory. Fixes: ecd6fce2611e ("mesa/st: support lowering multi-planar YUV") Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: add RADEON_FLAG_HANDLENicolai Hähnle2016-09-271-0/+2
| | | | | | | | | | | | | | | | When passed to winsys->buffer_create, this flag will indicate that we require a buffer that maps 1:1 with a kernel buffer handle. This is currently set for all textures, since textures can potentially be exported to other processes. This is not a huge loss, since the main purpose of this patch series is to deal with applications that allocate many small buffers. A hypothetical application with tons of tiny textures might still benefit from not setting this flag, but that's not a use case I'm worried about just now. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: set new r600_resource fields correctly in other places tooMarek Olšák2016-09-131-0/+11
| | | | | | | | | | | | | This was missed in: commit 0d2e43fcb1198a6e67c85feadb1ca8c360ddc284 Author: Marek Olšák <marek.olsak@amd.com> Date: Thu Aug 18 16:30:00 2016 +0200 gallium/radeon: derive buffer placement and flags only at initialization Tested-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* radeon: Don't check DCC on pipe buffersJan Vesely2016-09-131-3/+4
| | | | | | | | | Fixes segfaults in EG compute since: commit 21de3be8e62b2b093569a99550e6356ed2f106b4 radeonsi: fix texture format reinterpretation with DCC Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* radeonsi: unify si_set_optimal_micro_tile_mode call sitesMarek Olšák2016-09-081-8/+4
| | | | | | | There is nothing special happening in those code blocks. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* radeonsi: fix texture reinterpretation after DCC fast clearMarek Olšák2016-09-081-12/+20
| | | | | | | | | | The problem is that TC-compatible DCC clear codes translate into different clear values when you change the format. I have a new piglit reproducing the issue. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* radeonsi: enable DCC fast clear for 128-bit formatsMarek Olšák2016-09-081-13/+32
| | | | | Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* radeonsi: clamp integer clear color values for DCC fast clearMarek Olšák2016-09-081-4/+12
| | | | | | | It should be possible to get TC-compatible fast clear more often now. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* radeonsi: fix texture format reinterpretation with DCCMarek Olšák2016-09-051-0/+96
| | | | | | | | | | | | DCC is limited in how texture formats can be reinterpreted using texture views. If we get a view format that is incompatible with the initial texture format with respect to DCC, disable DCC. There is a new piglit which tests all format combinations. What works and what doesn't was deduced by looking at the piglit failures. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: also eliminate DCC fast clear in resource_get_handleMarek Olšák2016-09-051-2/+3
| | | | | | | just do what the comment says Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: use the current ctx for CMASK elimination in resource_get_handleMarek Olšák2016-09-051-6/+11
| | | | | | | For coherency with the current context. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: use the current ctx for DCC decompression in resource_get_handleMarek Olšák2016-09-051-3/+3
| | | | | | | For coherency with the current context. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: derive buffer placement and flags only at initializationMarek Olšák2016-09-051-4/+5
| | | | | | | | | | Invalidated buffers don't have to go through it. Split r600_init_resource into r600_init_resource_fields and r600_alloc_resource. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: clear dirty_level_mask when discarding CMASKMarek Olšák2016-08-291-0/+1
| | | | | | This fixes: GL45-CTS.texture_barrier.* Tested-by: Michel Dänzer <michel.daenzer@amd.com>
* gallium: add a pipe_context parameter to resource_get_handleMarek Olšák2016-08-251-0/+1
| | | | | | | | radeonsi needs to do some operations (DCC decompression) for OpenGL-OpenCL interop and this is the only way to make it coherent with the current context. It can optionally be set to NULL. Reviewed-by: Brian Paul <brianp@vmware.com>
* radeonsi: use current context for DCC feedback-loop decompress, fixes ElementalMarek Olšák2016-08-171-6/+32
| | | | | | | | | | This is just a workaround. The problem is described in the code. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96541 v2: say that it's only between the current context and aux_context Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
* gallium/radeon: implement ARB_clear_texture (v3)Marek Olšák2016-08-101-0/+67
| | | | | | | | | | Some ideas copied from Jakob Sinclair's implementation, but the color clearing is completely different. v2: remove leftover code, disable conditional rendering disable render condition cleanly Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium: split transfer_inline_write into buffer and texture callbacksMarek Olšák2016-07-231-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | to reduce the call indirections with u_resource_vtbl. The worst call tree you could get was: - u_transfer_inline_write_vtbl - u_default_transfer_inline_write - u_transfer_map_vtbl - driver_transfer_map - u_transfer_unmap_vtbl - driver_transfer_unmap That's 6 indirect calls. Some drivers only had 5. The goal is to have 1 indirect call for drivers that care. The resource type can be determined statically at most call sites. The new interface is: pipe_context::buffer_subdata(ctx, resource, usage, offset, size, data) pipe_context::texture_subdata(ctx, resource, level, usage, box, data, stride, layer_stride) v2: fix whitespace, correct ilo's behavior Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Acked-by: Roland Scheidegger <sroland@vmware.com>
* gallium/radeon: add depth/stencil_adjusted output to surface computationNicolai Hähnle2016-07-061-2/+2
| | | | | | | | | | | This fixes a rare bug with stencil texturing -- seen on Polaris and Tonga, though it's basically a function of the memory configuration so could affect other parts as well. Fixes piglit "unaligned-blit * stencil downsample" and various "fbo-depth-array *stencil*" tests. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: allocate only the required plane for flushed depthNicolai Hähnle2016-07-061-3/+34
| | | | Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: replace is_flushing_texture with db_compatibleNicolai Hähnle2016-07-061-1/+2
| | | | | | | | | | | This is a left-over of when I considered generalizing the separate stencil support. I do prefer the new name since it emphasizes what flushing vs. non-flushing means from a functional point-of-view, namely special handling of the texture format. v2: adjust r600_init_color_surface as well Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: add can_sample_z/s flags for texturesNicolai Hähnle2016-07-061-4/+15
| | | | | | v2: adjust r600_init_color_surface as well Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: remove redundant null-pointer checkNicolai Hähnle2016-07-061-2/+1
| | | | | | v2: keep using r600_texture_reference Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: print StencilLayout only onceNicolai Hähnle2016-07-061-2/+2
| | | | | | It is the same for all levels. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: flush stdout after printing texture informationNicolai Hähnle2016-07-061-0/+1
| | | | Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* gallium/radeon: remove zombie textures kept alive by DCC stat gatheringMarek Olšák2016-06-291-12/+27
| | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: don't re-create queries for DCC stat gatheringMarek Olšák2016-06-291-3/+6
| | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: separate DCC starts as disabled (ps_draw_ratio = 0)Marek Olšák2016-06-291-9/+10
| | | | | | | | | | | | | | DRI3: - Only slows clears can enable it for the first frame. - A good PS/draw ratio can enable it for other frames. DRI2: - Only slows clears can enable it for a frame. - Page-flipped color buffers are unref'd at the end of each frame, so it can't be enabled in any other way. - Relying on slow clears is sufficient for our synthetic benchmarks. Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: R600_DEBUG=nodccfb disables separate DCCMarek Olšák2016-06-291-1/+2
| | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: add and use r600_texture_referenceMarek Olšák2016-06-291-6/+4
| | | | | | Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Vedran Miletić <vedran@miletic.net> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: add a HUD query for PS draw ratio stats from separate DCCMarek Olšák2016-06-291-0/+1
| | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: add a heuristic enabling DCC for scanout surfaces (v2)Marek Olšák2016-06-291-0/+247
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DCC for displayable surfaces is allocated in a separate buffer and is enabled or disabled based on PS invocations from 2 frames ago (to let queries go idle) and the number of slow clears from the current frame. At least an equivalent of 5 fullscreen draws or slow clears must be done to enable DCC. (PS invocations / (width * height) + num_slow_clears >= 5) Pipeline statistic queries are always active if a color buffer that can have separate DCC is bound, even if separate DCC is disabled. That means the window color buffer is always monitored and DCC is enabled only when the situation is right. The tracking of per-texture queries in r600_common_context is quite ugly, but I don't see a better way. The first fast clear always enables DCC. DCC decompression can disable it. A later fast clear can enable it again. Enable/disable typically happens only once per frame. The impact is expected to be negligible because games usually don't have a high level of overdraw. DCC usually activates when too much blending is happening (smoke rendering) or when testing glClear performance and CMASK isn't supported (Stoney). v2: rename stuff, add assertions Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: add state setup for a separate DCC bufferMarek Olšák2016-06-291-3/+15
| | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* radeonsi: always calculate DCC info even if it's not used immediatelyMarek Olšák2016-06-291-1/+2
| | | | | | for a later use Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: boolean -> bool, TRUE -> true, FALSE -> falseMarek Olšák2016-06-251-2/+2
| | | | | | Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Vedran Miletić <vedran@miletic.net> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: use r600_resource_referenceMarek Olšák2016-06-251-7/+7
| | | | | | Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Vedran Miletić <vedran@miletic.net> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* radeonsi: try to hit direct hw MSAA resolve by changing micro mode in clearMarek Olšák2016-06-141-0/+87
| | | | | | | | | We could also do MSAA resolve in a compute shader like Vulkan and remove these workarounds. v2: comment the magic numbers Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* gallium/radeon: move DCC clearing into a separate functionMarek Olšák2016-06-081-5/+16
| | | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* radeonsi: don't allocate DCC for the temporary MSAA resolve surfaceMarek Olšák2016-06-081-1/+2
| | | | | | | Allocating it has no effect, but it adds overhead (useless DCC clear). Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* winsys/amdgpu: enable DCC for mipmapped texturesMarek Olšák2016-06-081-3/+7
| | | | | | | | Also add dcc_fast_clear_size for clearing only the necessary subset of DCC. For no AA, it's equal to the size of the whole DCC level. Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* gallium/radeon: don't disable DCC because of SDMAMarek Olšák2016-06-081-20/+3
| | | | | | | | We want to keep DCC enabled to save bandwidth. It was a bad idea to disable it here. Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* radeonsi: add per-level dcc_enabled flagsMarek Olšák2016-06-081-3/+3
| | | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* radeonsi: compute DCC register parameters in si_emit_framebuffer_stateMarek Olšák2016-06-081-2/+0
| | | | | | | | This will get more complicated with mipmapped DCC or when DCC is enabled after allocation. Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* gallium/radeon: add an assertion checking the validity of PIPE_BIND_SCANOUTMarek Olšák2016-06-081-3/+10
| | | | | Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* gallium/radeon: don't allocate DCC for non-renderable texture formatsMarek Olšák2016-06-081-0/+5
| | | | | | | | | | | R9G9B9E5 is the only uncompressed one hopefully. This fixes incorrect rendering not discovered (due to a lack of tests) until DCC mipmapping was enabled. Cc: 11.1 11.2 12.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* gallium/radeon: add support for sharing textures with DCC between processesMarek Olšák2016-06-071-3/+13
| | | | | | v2: use a function for calculating WORD1 of bo metadata Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
generated by cgit v1.1 at 2024-05-20 10:41:46 +0000