summaryrefslogtreecommitdiffstats
path: root/src/intel
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* i965/vec4: Delete the system value infastructureJason Ekstrand2017-05-0911-137/+5
| | | | | | | | | The only thing still using it is INVOCATION_ID for geometry shaders. That's easily enough inlined into the nir_intrinsic_load_invocation_id handling code. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Use NIR to do GS input remappingJason Ekstrand2017-05-099-101/+59
| | | | | | | | We're already doing this in the FS back-end. This just does the same thing in the vec4 back-end. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Move remapping of gl_PointSize to the NIR levelJason Ekstrand2017-05-092-26/+21
| | | | | Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/nir: Inline remap_inputs_with_vue_mapJason Ekstrand2017-05-091-27/+22
| | | | | Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Use NIR remapping for VS attributesJason Ekstrand2017-05-096-121/+34
| | | | | | | | | | | | | The NIR pass already handles remapping system values to attributes for us so we delete the system value code as part of the conversion. We also change nir_lower_vs_inputs to take an explicit inputs_read bitmask and pass in the inputs_read from prog_data instead from pulling it out of NIR. This is because the version in prog_data may get EDGEFLAG added to it on some old platforms. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler/vs: Move inputs_read handling to generic codeJason Ekstrand2017-05-092-3/+3
| | | | | Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Set VERT_BIT_EDGEFLAG based on the VUE mapJason Ekstrand2017-05-091-0/+11
| | | | | | | We also add a nice little comment to make it more clear exactly what happens with the edge flag copy. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Lower gl_VertexID and friends to inputs at the NIR levelJason Ekstrand2017-05-094-70/+74
| | | | | | | | | NIR calls these system values but they come in from the VF unit as vertex data. It's terribly convenient to just be able to treat them as such in the back-end. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: Set uses_vertexid and friends from brw_compile_vsJason Ekstrand2017-05-093-11/+17
| | | | | Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Move multiply by 4 for VS ATTR setup into the scalar backend.Jason Ekstrand2017-05-092-2/+2
| | | | | | | | | | The vec4 backend will want to count in units of vec4s, not scalar components. The simplest solution is to move the multiplication by 4 into the scalar backend. This also improves consistency with how we count varyings. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/nir: Inline remap_vs_attrsJason Ekstrand2017-05-091-30/+26
| | | | | | | | | | Now that we have nice block iterators, there's no good reason for this to be off on it's own. While we're here, we convert to using the NIR const index getters/setters instead of whacking const_index values directly. 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-0917-155/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* intel: compiler: prevent integer overflowLionel Landwerlin2017-05-091-2/+2
| | | | | | | CID: 1399477, 1399478 (Integer handling issues) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel: compiler: remove duplicated codeLionel Landwerlin2017-05-091-12/+0
| | | | | | | CID: 1399470: (Control flow issues) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel: gen decoder: don't check for size_t negative valuesLionel Landwerlin2017-05-091-1/+1
| | | | | | | | | We should get either 0 or 1 here. CID: 1373562 (Control flow issues) Signed-off-by: Lionel Landwerlin <[email protected]> Acked-by: Matt Turner <[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]>
* anv/allocator: Add no-valgrind versions of state_pool_alloc/freeJason Ekstrand2017-05-041-5/+19
| | | | Reviewed-by: Juan A. Suarez Romero <[email protected]>
* anv: Simplify Cherryview line handling.Kenneth Graunke2017-05-041-49/+16
| | | | | | | | | We can just use the new CHVLineWidth field rather than an entirely different generation's packing function. v2: Inline the function (requested by Jason) Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Fix line width on Cherryview.Kenneth Graunke2017-05-041-0/+1
| | | | | | | | We just add another field to gen8.xml for the Cherryview line width, rather than trying to replicate the gymnastics done in the Vulkan driver to use gen9 SF pack functions. Reviewed-by: Jason Ekstrand <[email protected]>
* anv: fix anv_gem_mmap comment to not mention NULLEmil Velikov2017-05-041-1/+1
| | | | | | | | The function cannot return NULL, update the comment accordingly. Fixes: b546c9d ("anv: anv_gem_mmap() returns MAP_FAILED as mapping error") Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* anv: vkBindImageMemory() should return VK_ERROR_OUT_OF_{HOST,DEVICE}_MEMORY ↵Samuel Iglesias Gonsálvez2017-05-041-1/+1
| | | | | | | | | | | | | | on failure According to the spec we get VK_ERROR_OUT_OF_HOST_MEMORY or VK_ERROR_OUT_OF_DEVICE_MEMORY on vkBindImageMemory failure. Fixes returned value changed by b546c9d. Fixes: b546c9d ("anv: anv_gem_mmap() returns MAP_FAILED as mapping error") Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Cc: "17.0 17.1" <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* anv: anv_gem_mmap() returns MAP_FAILED as mapping errorSamuel Iglesias Gonsálvez2017-05-042-6/+4
| | | | | | | | | | | | | | Take it into account when checking if the mapping failed. v2: - Remove map == NULL and its related comment (Emil) Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Fixes: 6f3e3c715a7 ("vk/allocator: Add a BO pool") Fixes: 9919a2d34de ("anv/image: Memset hiz surfaces to 0 when binding memory") Cc: "17.0 17.1" <[email protected]>
* genxml: Fix 3DSTATE_DEPTH_BUFFER length on gen5.Rafael Antognolli2017-05-031-3/+3
| | | | | | | | The hardware docs are wrong, but the length used in the xml is also wrong. Signed-off-by: Rafael Antognolli <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* anv: Use BRW_BARYCENTRIC_NONPERSPECTIVE_BITS from common header.Rafael Antognolli2017-05-031-1/+2
| | | | | | | | In a previous patch some enums were split out from brw_eu_defines.h, so they could be used by genxml based code. anv can also benefit from this. Signed-off-by: Rafael Antognolli <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Move enums to brw_compiler.h.Rafael Antognolli2017-05-032-21/+21
| | | | | | | | | | These enums live inside struct brw_wm_prog_data, so it makes sense to keep them in the same header. It also allows to use them without including brw_eu_defines.h. Signed-off-by: Rafael Antognolli <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 13:19:31 +0000