summaryrefslogtreecommitdiffstats
path: root/src/intel/vulkan
Commit message (Collapse)AuthorAgeFilesLines
* genxml: Make 3DSTATE_CONSTANT_BODY on Gen7+ use arrays.Kenneth Graunke2017-06-011-4/+4
| | | | | | This will let us initialize the constant buffers with loops. Reviewed-by: Lionel Landwerlin <[email protected]>
* anv: Port over CACHE_MODE_1 optimization fix enables from brw.Kenneth Graunke2017-05-301-0/+13
| | | | | | | | | Ben and I haven't observed these to help anything, but they enable hardware optimizations for particular cases. It's probably best to enable them ahead of time, before we run into such a case. Reviewed-by: Plamena Manolova <[email protected]> Acked-by: Jason Ekstrand <[email protected]>
* intel/blorp: Add support for gen4-5 SF programsJason Ekstrand2017-05-261-1/+4
| | | | | | | | As part of enabling support for SF programs, we plumb the SF URB size through to emit_urb_config. For now, it's always zero but, on gen4, it may be something larger. Reviewed-by: Topi Pohjolainen <[email protected]>
* anv: Require vertex buffers to come from a 32-bit heapJason Ekstrand2017-05-231-0/+12
| | | | | Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Advertise both 32-bit and 48-bit heaps when we have enough memoryJason Ekstrand2017-05-231-6/+36
| | | | | Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Refactor memory type setupJason Ekstrand2017-05-231-36/+40
| | | | | | | | This makes us walk over the heaps one at a time and add the types for LLC and !LLC to each heap. Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Make supports_48bit_addresses a heap propertyJason Ekstrand2017-05-232-3/+14
| | | | | Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Stop setting BO flags in bo_init_newJason Ekstrand2017-05-234-15/+25
| | | | | | | | | | | | | | | | | | The idea behind doing this was to make it easier to set various flags. However, we have enough custom flag settings floating around the driver that this is more of a nuisance than a help. This commit has the following functional changes: 1) The workaround_bo created in anv_CreateDevice loses both flags. This shouldn't matter because it's very small and entirely internal to the driver. 2) The bo created in anv_CreateDmaBufImageINTEL loses the EXEC_OBJECT_ASYNC flag. In retrospect, it never should have gotten EXEC_OBJECT_ASYNC in the first place. Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Set image memory types based on the type countJason Ekstrand2017-05-231-2/+4
| | | | | Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Add valid_bufer_usage to the memory type metadataJason Ekstrand2017-05-232-8/+26
| | | | | | | | | Instead of returning valid types as just a number, we now walk the list and check the buffer's usage against the usage flags we store in the new anv_memory_type structure. Currently, valid_buffer_usage == ~0. Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Determine the type of mapping based on type metadataJason Ekstrand2017-05-232-7/+7
| | | | | | | | | Before, we were just comparing the type index to 0. Now we actually look the type up in the table and check its properties to determine what kind of mapping we want to do. Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Set up memory types and heaps during physical device initJason Ekstrand2017-05-232-44/+77
| | | | | Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Predicate 48bit support on gen >= 8Jason Ekstrand2017-05-231-1/+6
| | | | | | | | | This doesn't matter right now since it only affects whether or not we set the kernel bit but, if we ever do anything else based on it, we'll want it to be correct per-gen. Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv/image: Get rid of the memset(aux, 0, sizeof(aux)) hackJason Ekstrand2017-05-231-28/+0
| | | | | | | | | | | | | Up until now, we've been memsetting the auxiliary surface to 0 at BindImageMemory time to ensure that it is properly initialized. However, this isn't correct because apps are allowed to freely alias memory between different images and buffers so long as they properly track whether or not a particular image is valid and, if it isn't, transition from UNINITIALIZED to something else before using it. We now implement those transitions so we can drop the hack. Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Handle transitioning depth from UNDEFINED to other layoutsJason Ekstrand2017-05-232-19/+19
| | | | | Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv: Handle color layout transitions from the UNINITIALIZED layoutJason Ekstrand2017-05-233-2/+108
| | | | | | | | This causes dEQP-VK.api.copy_and_blit.resolve_image.partial.* to start failing due to test bugs. See CL 1031 for a test fix. Reviewed-by: Nanley Chery <[email protected]> Cc: "17.1" <[email protected]>
* anv/formats: Update the three-channel BC1 mappingsNanley Chery2017-05-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The procedure for decompressing an opaque BC1 Vulkan format is dependant on the comparison of two colors stored in the first 32 bits of the compressed block. Here's the specified OpenGL (and Vulkan) behavior for reference: The RGB color for a texel at location (x,y) in the block is given by: RGB0, if color0 > color1 and code(x,y) == 0 RGB1, if color0 > color1 and code(x,y) == 1 (2*RGB0+RGB1)/3, if color0 > color1 and code(x,y) == 2 (RGB0+2*RGB1)/3, if color0 > color1 and code(x,y) == 3 RGB0, if color0 <= color1 and code(x,y) == 0 RGB1, if color0 <= color1 and code(x,y) == 1 (RGB0+RGB1)/2, if color0 <= color1 and code(x,y) == 2 BLACK, if color0 <= color1 and code(x,y) == 3 The sampling operation performed on an opaque DXT1 Intel format essentially hard-codes the comparison result of the two colors as color0 > color1. This means that the behavior is incompatible with OpenGL and Vulkan. This is stated in the SKL PRM, Vol 5: Memory Views: Opaque Textures (DXT1_RGB) Texture format DXT1_RGB is identical to DXT1, with the exception that the One-bit Alpha encoding is removed. Color 0 and Color 1 are not compared, and the resulting texel color is derived strictly from the Opaque Color Encoding. The alpha channel defaults to 1.0. Programming Note Context: Opaque Textures (DXT1_RGB) The behavior of this format is not compliant with the OGL spec. The opaque and non-opaque BC1 Vulkan formats are specified to be decoded in exactly the same way except the BLACK value must have a transparent alpha channel in the latter. Use the four-channel BC1 Intel formats with the alpha set to 1 to provide the behavior required by the spec. v2 (Kenneth Graunke): - Provide a more detailed commit message. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100925 Cc: <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Nanley Chery <[email protected]>
* anv: Add an option to abort on device lossJason Ekstrand2017-05-181-0/+5
| | | | | | | | | | | | | | | | This is mostly for running in our CI system to prevent dEQP from continuing on to the next test if we get a GPU hang. As it currently stands, dEQP uses the same VkDevice for almost all tests and if one of the tests hangs, we set the anv_device::device_lost flag and report VK_ERROR_DEVICE_LOST for all queue operations from that point forward without sending anything to the GPU. dEQP will happily continue trying to run tests and reporting failures until it eventually gets crash that forces the test runner to start over. This circumvents the problem by just aborting the process if we ever get a GPU hang. Since this is not the recommended behavior most of the time, we hide it behind an environment variable. Reviewed-by: Lionel Landwerlin <[email protected]>
* anv: Wrap the device lost error in vk_error in QueueSubmitJason Ekstrand2017-05-181-1/+1
| | | | | | | | We weren't wrapping this before because anv_cmd_buffer_execbuf may throw a more meaningful error message. However, we do change the error code into VK_ERROR_DEVICE_LOST, so we should print a new message. Reviewed-by: Lionel Landwerlin <[email protected]>
* anv: fix multiview for clear commandsIago Toral Quiroga2017-05-181-0/+41
| | | | | | | | | | | | | | | | | | | | According to the VK_KHX_multiview spec: "Multiview causes all drawing and clear commands in the subpass to behave as if they were broadcast to each view, where each view is represented by one layer of the framebuffer attachments." This adds support for multiview clears, which were missing in the initial implementation. v2 (Jason): - split multiview from regular case - Use for_each_bit() macro Fixes new CTS multiview tests: dEQP-VK.multiview.clear_attachments.* Reviewed-by: Jason Ekstrand <[email protected]>
* anv: Implement VK_KHR_get_surface_capabilities2Jason Ekstrand2017-05-163-0/+32
| | | | Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* anv: document that anv_gem_mmap returns MAP_FAILED on errorEmil Velikov2017-05-111-1/+1
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* anv: don't leak DRM devicesGrazvydas Ignotas2017-05-101-0/+1
| | | | | | | | | After successful drmGetDevices2() call, drmFreeDevices() needs to be called. Fixes: b1fb6e8d "anv: do not open random render node(s)" Signed-off-by: Grazvydas Ignotas <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]> # radv version
* anv: fix possible stack corruptionGrazvydas Ignotas2017-05-101-1/+1
| | | | | | | | | | drmGetDevices2 takes count and not size. Probably hasn't caused problems yet in practice and was missed as setups with more than 8 DRM devices are not very common. Fixes: b1fb6e8d "anv: do not open random render node(s)" Signed-off-by: Grazvydas Ignotas <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* intel/compiler/vs: Move inputs_read handling to generic codeJason Ekstrand2017-05-091-3/+0
| | | | | Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* nir: Embed the shader_info in the nir_shader againJason Ekstrand2017-05-091-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit e1af20f18a86f52a9640faf2d4ff8a71b0a4fa9b changed the shader_info from being embedded into being just a pointer. The idea was that sharing the shader_info between NIR and GLSL would be easier if it were a pointer pointing to the same shader_info struct. This, however, has caused a few problems: 1) There are many things which generate NIR without GLSL. This means we have to support both NIR shaders which come from GLSL and ones that don't and need to have an info elsewhere. 2) The solution to (1) raises all sorts of ownership issues which have to be resolved with ralloc_parent checks. 3) Ever since 00620782c92100d77c660f9783504c6d80fa1d58, we've been using nir_gather_info to fill out the final shader_info. Thanks to cloning and the above ownership issues, the nir_shader::info may not point back to the gl_shader anymore and so we have to do a copy of the shader_info from NIR back to GLSL anyway. All of these issues go away if we just embed the shader_info in the nir_shader. There's a little downside of having to copy it back after calling nir_gather_info but, as explained above, we have to do that anyway. Acked-by: Timothy Arceri <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* anv: check return value of anv_execbuf_add_boLionel Landwerlin2017-05-081-2/+7
| | | | | | | CID: 1405919 (Error handling issues) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* anv: avoid null pointer dereferenceLionel Landwerlin2017-05-081-1/+2
| | | | | | | | | The application might not give an output structure. CID: 1405765 (Null pointer dereferences) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* anv/allocator: Only write to _vg_ptr if we have valgrindJason Ekstrand2017-05-051-1/+1
| | | | | | | This fixes the build when not building against valgrind headers. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100945 Reviewed-by: Chad Versace <[email protected]>
* anv/query: handle more cases of 'out of host memory'Iago Toral Quiroga2017-05-051-0/+10
| | | | Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* anv/allocator: Improve block pool growing assertsJason Ekstrand2017-05-041-6/+5
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv: Drop the instruction pool block sizeJason Ekstrand2017-05-041-2/+1
| | | | | | | Now that we can allocate states larger than the block size, we no longer need a block size of 1MB which can be rather wasteful. Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Add support for large stream allocationsJason Ekstrand2017-05-041-4/+7
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Allow state pools to allocate large statesJason Ekstrand2017-05-041-0/+69
| | | | | | | | | | | | | | | | | | | | | | Previously, the maximum size of a state that could be allocated from a state pool was a block. However, this has caused us various issues particularly with shaders which are potentially very large. We've also hit issues with render passes with a large number of attachments when we go to allocate the block of surface state. This effectively removes the restriction on the maximum size of a single state. (There's still a limit of 1MB imposed by a fixed-length bucket array.) For states larger than the block size, we just grab a large block off of the block pool rather than sub-allocating. When we go to allocate some chunk of state and the current bucket does not have state, we try to pull a chunk from some larger bucket and split it up. This should improve memory usage if a client occasionally allocates a large block of state. This commit is inspired by some similar work done by Juan A. Suarez Romero <[email protected]>. Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Support pushing multiple blocks onto a free list at onceJason Ekstrand2017-05-041-3/+16
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Add helpers for dealing with bucket sizesJason Ekstrand2017-05-041-10/+20
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Add the capability to allocate blocks of different sizesJason Ekstrand2017-05-042-15/+13
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Rework a commentJason Ekstrand2017-05-041-4/+5
| | | | | | This commit just fixes up the English a bit and re-flows the comment. Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Tweak the block pool growing algorithmJason Ekstrand2017-05-041-10/+18
| | | | | | | | | The old algorithm worked fine assuming a constant block size. We're about to break that assumption so we need an algorithm that's a bit more robust against suddenly growing by a huge amount compared to the currently allocated quantity of memory. Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Embed the block_pool in the state_poolJason Ekstrand2017-05-0411-86/+66
| | | | | | | Now that the state stream is allocating off of the state pool, there's no reason why we need the block pool to be separate. Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Get rid of the ability to free blocksJason Ekstrand2017-05-042-34/+2
| | | | | | | Now that everything is going through the state pools, the block pool no longer needs to be able to handle re-use. Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv: Allocate binding table blocks through the state poolJason Ekstrand2017-05-042-27/+22
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Add support for "back" allocations to state_poolJason Ekstrand2017-05-042-2/+33
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Drop the block_size field from block_poolJason Ekstrand2017-05-049-50/+74
| | | | | | | | | | | | | Since the state_stream is now pulling from a state_pool, the only thing pulling directly off the block pool is the state pool so we can just move the block_size there. The one exception is when we allocate binding tables but we can just reference the state pool there as well. The only functional change here is that we no longer grow the block pool immediately upon creation so no BO gets allocated until our first state allocation. Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Pull the userptr part of block_pool_grow into a helperJason Ekstrand2017-05-041-91/+104
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Roll fixed_size_state_pool into state_poolJason Ekstrand2017-05-041-50/+35
| | | | | | | The helper functions aren't really gaining us as much as they claim and are actually about to be in the way. Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Remove the state_size field from fixed_size_state_poolJason Ekstrand2017-05-042-12/+10
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv: Get rid of a bunch of uses of size_tJason Ekstrand2017-05-044-14/+14
| | | | | | | | | | We should only use size_t when referring to sizes of bits of CPU memory. Anything on the GPU or just a regular array length should be a type that has the same size on both 32 and 64-bit architectures. For state objects, we use a uint32_t because we'll never allocate a piece of driver-internal GPU state larger than 2GB (more like 16KB). Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Convert the state stream to pull from a state poolJason Ekstrand2017-05-044-51/+55
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv/allocator: Return a null state for zero-size allocationsJason Ekstrand2017-05-042-0/+11
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 19:55:43 +0000