summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* anv: Remove some asserts.Rafael Antognolli2019-01-171-3/+0
| | | | | | | They won't be true anymore once we add support for multiple BOs with non-userptr. Reviewed-by: Jason Ekstrand <[email protected]>
* anv: Validate the list of BOs from the block pool.Rafael Antognolli2019-01-171-5/+49
| | | | | | | | | | | | | | | | | | | We now have multiple BOs in the block pool, but sometimes we still reference only the first one in some instructions, and use relative offsets in others. So we must be sure to add all the BOs from the block pool to the validation list when submitting commands. v2: - Don't add block pool BOs to the dependency list right before execbuf (Jason) - Call anv_execbuf_add_bo() to each BO in the block pools (Jason) - Use anv_execbuf_add_bo_set() to add surface state dependencies to execbuf. v3: - Add comment to the non-softpin case (Jason). Reviewed-by: Jason Ekstrand <[email protected]>
* anv: Split code to add BO dependencies to execbuf.Rafael Antognolli2019-01-171-23/+39
| | | | | | | | | This part of the anv_execbuf_add_bo() code is totally independent of the BO being added. Let's split it out, so we can reuse it later. v3: rename to anv_execbuf_add_bo_set (Jason). Reviewed-by: Jason Ekstrand <[email protected]>
* anv/allocator: Add support for a list of BOs in block pool.Rafael Antognolli2019-01-172-11/+59
| | | | | | | | | | | | | | | | | | | So far we use only one BO (the last one created) in the block pool. When we switch to not use the userptr API, we will need multiple BOs. So add code now to store multiple BOs in the block pool. This has several implications, the main one being that we can't use pool->map as before. For that reason we update the getter to find which BO a given offset is part of, and return the respective map. v3: - Simplify anv_block_pool_map (Jason). - Use fixed size array for anv_bo's (Jason) v4: - Respect the order (item, container) in anv_block_pool_foreach_bo (Jason). Reviewed-by: Jason Ekstrand <[email protected]>
* anv: Update usage of block_pool->bo.Rafael Antognolli2019-01-177-31/+36
| | | | | | | | | | | Change block_pool->bo to be a pointer, and update its usage everywhere. This makes it simpler to switch it later to a list of BOs. v3: - Use a static "bos" field in the struct, instead of malloc'ing it. This will be later changed to a fixed length array of BOs. Reviewed-by: Jason Ekstrand <[email protected]>
* anv/allocator: Remove pool->map.Rafael Antognolli2019-01-173-19/+7
| | | | | | | | After switching to using anv_state_table, there are very few places left still using pool->map directly. We want to avoid that because it won't be always the right map once we split it into multiple BOs. Reviewed-by: Jason Ekstrand <[email protected]>
* anv/allocator: Rename anv_free_list2 to anv_free_list.Rafael Antognolli2019-01-172-31/+30
| | | | | | Now that we removed the original anv_free_list, we can now use its name. Reviewed-by: Jason Ekstrand <[email protected]>
* anv/allocator: Remove anv_free_list.Rafael Antognolli2019-01-172-66/+0
| | | | | | | The next commit already renames anv_free_list2 -> anv_free_list since the old one is gone. Reviewed-by: Jason Ekstrand <[email protected]>
* anv/allocator: Use anv_state_table on back_alloc too.Rafael Antognolli2019-01-172-15/+22
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* anv/allocator: Use anv_state_table on anv_state_pool_alloc.Rafael Antognolli2019-01-172-35/+48
| | | | | | | | | | Use anv_state_pool_return_blocks() to return blocks to the pool, instead of manually pushing them. v3: - return blocks from the end of the chunk (Jason). Reviewed-by: Jason Ekstrand <[email protected]>
* anv/allocator: Add helper to push states back to the state table.Rafael Antognolli2019-01-172-0/+35
| | | | | | | | | | | | | | The use of anv_state_table_add() combined with anv_state_table_push(), specially when adding a bunch of states to the table, is very verbose. So we add this helper that makes things easier to digest. We also already add the anv_state_table member in this commit, so things can compile properly, even though it's not used. v2: assert that the states are always aligned to their size (Jason) v3: Add "table" member to anv_state_pool in this commit. Reviewed-by: Jason Ekstrand <[email protected]>
* anv/allocator: Add getter for anv_block_pool.Rafael Antognolli2019-01-174-5/+18
| | | | | | | | | | We will need the anv_block_pool_map to find the map relative to some BO that is not at the start of the block pool. v2: just return a pointer instead of a struct (Jason) v4: Update comment (Jason) Reviewed-by: Jason Ekstrand <[email protected]>
* anv/allocator: Add anv_state_table.Rafael Antognolli2019-01-172-2/+283
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a structure to hold anv_states. This table will initially be used to recycle anv_states, instead of relying on a linked list implemented in GPU memory. Later it could be used so that all anv_states just point to the content of this struct, instead of making copies of anv_states everywhere. One has to call anv_state_table_add(), which returns an index for the state in the table, and then get a pointer to such index, and finally fill in the rest of the struct. TODO: 1) There's a lot of common code between this table backing store memory and the anv_block_pool buffer, due to how we grow it. I think it's possible to refactory this and reuse code on both places. 2) Add unit tests. v3: - Rename state table memfd (Jason) - Return VK_ERROR_OUT_OF_HOST_MEMORY on more places (Jason) - anv_state_table_grow returns VkResult (Jason) - Rename variables to be more informative (Jason) - Return errors on state table grow. - Rename anv_state_table_push/pop to anv_free_list_push2/pop2 This will be renamed again to remove the trailing "2" later. v4: - Remove exit(-1) from anv_state_table (Jason). - Use uint32_t "next" field in anv_free_entry (Jason). Reviewed-by: Jason Ekstrand <[email protected]>
* anv/tests: Fix block_pool_no_free test.Rafael Antognolli2019-01-171-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were 2 problems with this test. First it was comparing highest, which was -1, with an uint32_t. So the current value would never be higher than that, and the assert would always be false. It just never reached this point because of the next problem. It was always looking for the highest value of each thread and storing it in thread_max. So a test case like this wouldn't work: [Thread]: [Blocks] [0]: [0, 32, 64, 96] [1]: [128, 160, 192, 224] [2]: [256, 288, 320, 352] Not only that would skip values and iterate only over thread number 2, instead of walking through all of them, but thread_max was also initialized to -1. And then compared to unsigned blocks[i][next[i]. We fix that by getting the smallest value of each thread, and checking if it is lower than thread_min, which is initialized to INT32_MAX. And then we end up walking through all the blocks of all threads. We also change "blocks" to be int32_t instead of uint32_t, since in some places (alloc_blocks) it was already referenced as int32_t, and that fixes the comparison to -1. v2: - keep highest initialized to -1, and change blocks to be int32_t. Reviewed-by: Jason Ekstrand <[email protected]>
* anv: fix invalid binding table index computationLionel Landwerlin2019-01-171-4/+2
| | | | | | | | The ++ operator strikes again. Fixes: f92c5bc8f3f517 ("anv/device: fix maximum number of images supported") Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv/device: fix maximum number of images supportedIago Toral Quiroga2019-01-174-13/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had defined MAX_IMAGES as 8, which we used to size the array for image push constant data. The comment there stated that this was for gen8, but anv_nir_apply_pipeline_layout runs for all gens and writes that array, asserting that we don't exceed that number of images, which imposes a limit of MAX_IMAGES on all gens. Furthermore, despite this, we are exposing up to 64 images per shader stage on all gens, gen8 included. This patch lowers the number of images we expose in gen8 to 8 and keeps 64 images for gen9+ while making sure that only pre-SKL gens use push constant space to handle images. v2: - <= instead of < in the assert (Eric, Lionel) - Change the way the assertion is written (Eric) v3: - Revert the way the assertion is written to the form it had in v1, the version in v2 was not equivalent and was incorrect. (Lionel) v4: - gen9+ doesn't need push constants for images at all (Jason) Cc: [email protected] Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> (v3)
* anv: do not advertise AHW support if extension not enabledTapani Pälli2019-01-171-6/+15
| | | | | | | | | | | | | | | | Fixes following failing vk-gl-cts cases on Linux desktop: dEQP-VK.api.external.memory.android_hardware_buffer.suballocated.buffer.info dEQP-VK.api.external.memory.android_hardware_buffer.suballocated.image.info dEQP-VK.api.external.memory.android_hardware_buffer.dedicated.image.info dEQP-VK.api.external.memory.android_hardware_buffer.dedicated.buffer.info Fixes: 517103abf1c "anv/android: add ahardwarebuffer external memory properties" Reported-by: Juan A. Suarez <[email protected]> Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Juan A. Suarez <[email protected]>
* vc4: Don't leak the GPU fd for renderonly usage.Eric Anholt2019-01-161-1/+1
| | | | | | | | Noticed while debugging V3D -- the ro->gpu_fd was freshly opened in ro setup, and it needs to stay open until screen close (since it may be used by renderonly) and should be the same one used by the vc4 screen. Fixes: 7029ec05e2c7 ("gallium: Add renderonly-based support for pl111+vc4.")
* v3d: Don't leak the GPU fd for renderonly usage.Eric Anholt2019-01-161-1/+1
| | | | | | | | | | The CTS was running out of fds, because of the ro->gpu_fd never being closed. ro->gpu_fd should match the screen (in case the caller of v3d_drm_screen_create_renderonly() has a scanout_for_resource() that uses gpu_fd) and the screen is expected to close its fd at the end, fixing the resource leak. Fixes: e113b21cb779 ("v3d: Add renderonly support.")
* v3d: Restructure RO allocations using resource_from_handle.Eric Anholt2019-01-161-29/+38
| | | | | | | | | | | | | | | I had bugs in the old path where I was laying out as tiled (so we'd render tiled) but then only allocating space in the shared object for linear rendering. The resource_from_handle makes it so the same layout choices are made in both the import and export scanout cases. Also, fixes a leak of the fd that was tripping up the CTS. Now that we're checking PIPE_BIND_SHARED to choose to use RO, the DRM_FORMAT_MOD_LINEAR check wasn't needed any more. Fixes visual corruption and MMU faults in X in renderonly mode. Fixes: bd09bb1629a7 ("v3d: SHARED but not necessarily SCANOUT buffers on RO must be linear.")
* v3d: If the modifier is not known on BO import, default to linear for RO.Eric Anholt2019-01-161-1/+3
| | | | | | Part of fixing DRI3 rendering with RO on X11. Fixes: e113b21cb779 ("v3d: Add renderonly support.")
* ac/nir_to_llvm: add support for structs to get_sampler_desc()Timothy Arceri2019-01-171-19/+26
| | | | Reviewed-by: Marek Olšák <[email protected]>
* ac/nir_to_llvm: fix regression in bindless supportTimothy Arceri2019-01-171-1/+6
| | | | | | This wasn't ported over when deref support was implemented. Reviewed-by: Marek Olšák <[email protected]>
* radeonsi/nir: get correct type for images inside structsTimothy Arceri2019-01-171-1/+2
| | | | Reviewed-by: Marek Olšák <[email protected]>
* ac/nir_to_llvm: fix type handling in image codeTimothy Arceri2019-01-171-15/+12
| | | | | | | | | | The current code only strips off arrays and cannot find the type for images that are struct members. Instead of trying to get the image type from the variable, we just get it directly from the deref instruction. Reviewed-by: Marek Olšák <[email protected]>
* radv: use dithered alpha-to-coverageRhys Perry2019-01-161-4/+5
| | | | | | | | This matches the behaviour of AMDVLK and hides banding. It is also seems to be allowed by the Vulkan spec. Signed-off-by: Rhys Perry <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* swr/rast: Store cached files in multiple subdirsAlok Hota2019-01-163-38/+52
| | | | | | This improves cache filesystem performance, especially during CI tests Also updated jitcache magic number due to codegen parameter changes Removed 2 `if constexpr` to prevent C++17 requirement
* swr/rast: New execution engine per JITAlok Hota2019-01-162-42/+65
| | | | Fixes relocation errors with LLVM 7.0.0
* swr/rast: Scope MEM_CLIENT enum for mem usagesAlok Hota2019-01-166-40/+38
| | | | | | | | Avoids confusion with other defaulted integer parameters - fixed some unspecified usages - removed unnecessary includes - removed unecessary protected access specifier in buckets framework
* swr/rast: Unaligned and translations in gathersAlok Hota2019-01-161-21/+35
| | | | | | | - added graphics address translation in odd gathers - added support for unaligned gathers in fetch shader - changed how 2+ GB offsets are handled to make them compatible with unaligned offsets
* swr/rast: partial support for Tiled ResourcesAlok Hota2019-01-162-0/+164
| | | | | | | | | - updated sample from TRTT surfaces correctly - implemented mapped status return for TRTT surfaces - implemented per-sample instruction minLod clamp - updated bilinear filter weight calculation to be closer to D3D specs - implemented "ReducedTexcoordRange" operation from D3D specs to avoid loss of precision on high-value normalized coordinates
* swr/rast: Add annotator to interleave isa textAlok Hota2019-01-162-3/+36
| | | | To make debugging simpler
* swr/rast: Use gfxptr_t value in JitGatherVerticesAlok Hota2019-01-161-18/+16
| | | | | Use gfxptr_t type value for stream pointer uses in gather and similar calls
* gallium/swr: Fix multi-context sync fence deadlock.Bruce Cherniak2019-01-161-1/+3
| | | | | | | | | | | | | | | | Various recreation scenarios lead to API thread getting stuck in swr_fence_finish(). This is a multi-context issue, whereby one context overwrites the fence read-value with a previous sync's lesser value. The fence sync value is supposed to be always increasing. In swr_fence_cb(), only update the "read" value if the new value is greater. (This may seem like we're not waiting on the other context to finish, but had we needed for it to finish there would have been a wait prior to submitting a new sync.) cc: [email protected]
* ac/nir: don't trash L1 caches for store operations with writeonly memorySamuel Pitoiset2019-01-161-5/+15
| | | | | | | Ported from RadeonSI. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* st/mesa: Optionally override RGB/RGBX dst alpha blend factorsKenneth Graunke2019-01-158-2/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Intel's blending hardware does not properly return 1.0 for destination alpha for RGBX formats; it requires the factors to be overridden to either zero or one. Broadcom vc4 and v3d also could use this override. While overriding these factors is safe in general, Nouveau and Radeon would prefer not to. Their blending hardware already returns correct values for RGB/RGBX formats, and would like to avoid the resulting per-buffer blending and independent blend factors (rgb != a) since it can cause additional overhead. I considered simply handling this in the driver, but it's not as nice. pipe_blend_state doesn't have any format information, so we'd need the hardware blend state to depend on both pipe_blend_state and pipe_framebuffer_state. Furthermore, Intel GPUs don't have a native RGBX_SNORM format, so I avoid exposing one, which makes Gallium fall back to RGBA_SNORM. The pipe_surfaces we get in the driver have an RGBA format, making it impossible to tell that there shouldn't be an alpha channel. One could argue that st not handling it in that case is a bug. To work around this, we'd have to expose RGBX pipe formats, mapped to RGBA hardware formats, and add format swizzling special cases. All doable, but it ends up being more code than I'd like. st_atom_blend already has access to the right information and it's trivial to accomplish there, so we just add a cap bit and do that. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* winsys/amdgpu: fix whitespaceMarek Olšák2019-01-151-1/+1
|
* gallium: Add the ability to query a single pipeline statistics counterKenneth Graunke2019-01-157-2/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gallium historically has treated pipeline statistics queries as a single query, PIPE_QUERY_PIPELINE_STATISTICS, which returns a block of 11 values. This was originally patterned after the D3D1x API. Much later, Brian introduced an OpenGL extension that exposed these counters - but it exposes 11 separate queries, each of which returns a single value. Today, st/mesa simply queries all 11 values, and returns a single value. While pipeline statistics counters aren't typically performance critical, this is still not a great fit. A D3D1x->GL translator might request all 11 counters by creating 11 separate GL queries...which Gallium would map to reads of all 11 values each time, resulting in a total 121 counter reads. That's not ideal. This patch adds a new cap, PIPE_CAP_QUERY_PIPELINE_STATISTICS_SINGLE, and corresponding query type PIPE_QUERY_PIPELINE_STATISTICS_SINGLE. When calling create_query(), q->index should be set to one of the PIPE_STAT_QUERY_* enums to select a counter. Unlike the block query, this returns the value in pipe_query_result::u64 (as it's a single value) instead of the pipe_query_data_pipeline_statistics group. We update st/mesa to expose ARB_pipeline_statistics_query if either capability is set, preferring the new SINGLE variant when available. Thanks to Roland, Ilia, and Marek for helping me sort this out. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* st/mesa: Rearrange PIPE_QUERY_PIPELINE_STATISTICS result fetching.Kenneth Graunke2019-01-151-43/+45
| | | | | | | | | | | This just changes the order of the switch statements, so we only look at target if the query type is PIPE_QUERY_PIPELINE_STATISTICS. The next commit will introduce a new SINGLE query type which can be used for the same GL query types, and it won't want this processing. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* st/mesa: Make an enum for pipeline statistics query result indices.Kenneth Graunke2019-01-152-11/+28
| | | | | | | | | | | | Gallium handles pipeline statistics queries as a single query (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values. Sometimes it's useful to refer to each of those values individually, rather than as a group. To avoid hardcoding numbers, we define a new enum for each value. Here, the name and enum value correspond to the index in the struct pipe_query_data_pipeline_statistics result. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* radv: add support for VK_EXT_memory_budgetSamuel Pitoiset2019-01-156-1/+124
| | | | | | | | | | | | A simple Vulkan extension that allows apps to query size and usage of all exposed memory heaps. The different usage values are not really accurate because they are per drm-fd, but they should be close enough. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Alex Smith <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radv: add two small helpers for getting VRAM and visible VRAM sizesSamuel Pitoiset2019-01-151-5/+16
| | | | | | Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Alex Smith <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radv: remove unnecessary returns in GetPhysicalDevice*Properties()Samuel Pitoiset2019-01-151-4/+4
| | | | | | | | These functions return nothing. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Alex Smith <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radv: Set partial_vs_wave for pipelines with just GS, not tess.Bas Nieuwenhuizen2019-01-151-8/+20
| | | | | | | | | | | | | | | | Looking at -pro we need to enable it for pipelines with just a GS too. This seems to reduce the hangs from https://bugs.freedesktop.org/show_bug.cgi?id=109242 on a RX 550 to the point where I can't reproduce, after the false start with the wd_switch_on_eop patch due to flakiness. (but people are reporting it does not fix the issue completely for them on polaris 11) CC: <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* radeonsi: also apply the GS hang workaround to draws without tessellationMarek Olšák2019-01-141-11/+14
| | | | | | | ported from AMDVLK. Cc: 18.3 <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* v3d: SHARED but not necessarily SCANOUT buffers on RO must be linear.Eric Anholt2019-01-141-1/+1
| | | | | We don't have a way to talk to RO about modifiers it can do yet, so assume the minimum.
* v3d: Add support for CS barrier() intrinsics.Eric Anholt2019-01-143-0/+61
|
* v3d: Add support for CS shared variable load/store/atomics.Eric Anholt2019-01-143-13/+83
| | | | | CS shared variables are handled effectively as SSBO access to a temporary buffer that will be allocated at CS dispatch time.
* v3d: Add support for CS workgroup/invocation id intrinsics.Eric Anholt2019-01-145-1/+67
| | | | | | We get a payload for the ivec3 workgroup and an int local invocation index, and we use the core lowering to turn into the global invocation id and the local invocation id ivec3s.
* v3d: Add support for shader_image_load_store.Eric Anholt2019-01-1413-5/+848
| | | | | | This is only exposed on V3D 4.1+, because we didn't have the TMU write operations for images on 3.3 (To do GLES 3.1 there, you have to lower it to SSBO load/stores, which is a problem to solve later).
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 19:44:35 +0000