summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* intel/fs: the maximum supported stride width is 16Paulo Zanoni2019-09-191-1/+3
| | | | | | | | | | | | | | | | There are cases where we try to generate registers with a stride of 32, while the hardware maximum is just 16. This happens, for example, when using 8 bit integers on SIMD32. This results in a crash because the variable 'width' has a value of 32: ../../src/intel/compiler/brw_reg.h:550: brw_reg brw_vecn_reg(unsigned int, brw_reg_file, unsigned int, unsigned int): Assertion `!"Invalid register width"' failed. This change prevents the crash and makes the tests pass. Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]>
* intel/fs: roll the loop with the <0,1,0> additions in emit_scan()Paulo Zanoni2019-09-191-32/+14
| | | | | | | | | | | | IMHO the code is easier to understand this way, being explicit that we're doing exactly the same thing every time. No functional changes. v2: Adjust the loop breaking condition (Jason). Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]>
* intel/fs: make scan/reduce work with SIMD32 when it fits 2 registersPaulo Zanoni2019-09-191-0/+23
| | | | | | | | | | | | When dealing with uint16_t and uint8_t on SIMD32 we can do all the operations using just 2 registers, so we don't hit the recursion at the beginning of emit_scan(). Because of that, we need to actually compute scan/reduce for channels 31:16. v2: Still missed instructions (Jason). Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]>
* freedreno/regs: A couple of tess updatesKristian H. Kristensen2019-09-182-3/+41
| | | | Reviewed-by: Eric Anholt <[email protected]>
* freedreno/regs: Fix CP_DRAW_INDX_OFFSET commandKristian H. Kristensen2019-09-181-0/+14
| | | | | | On A5xx+ the INDX_BASE pointer is 64 bit. Reviewed-by: Eric Anholt <[email protected]>
* freedreno/a6xx: Write multiple regs for SP_VS_OUT_REG and SP_VS_VPC_DST_REGKristian H. Kristensen2019-09-181-6/+5
| | | | | | | Compute the number of writes up front. Signed-off-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* freedreno/a6xx: Turn on vectorize_ioKristian H. Kristensen2019-09-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want this for tessellation eventually, but we can turn it on now. Shader-db results: total instructions in shared programs: 8612905 -> 8611387 (-0.02%) instructions in affected programs: 164952 -> 163434 (-0.92%) total dwords in shared programs: 11952000 -> 11950560 (-0.01%) dwords in affected programs: 68096 -> 66656 (-2.11%) total full in shared programs: 315019 -> 315009 (<.01%) full in affected programs: 1642 -> 1632 (-0.61%) total constlen in shared programs: 2463654 -> 2463654 (0.00%) constlen in affected programs: 0 -> 0 total (ss) in shared programs: 152379 -> 152409 (0.02%) (ss) in affected programs: 1503 -> 1533 (2.00%) total (sy) in shared programs: 96473 -> 96525 (0.05%) (sy) in affected programs: 654 -> 706 (7.95%) total max_sun in shared programs: 1172454 -> 1172472 (<.01%) max_sun in affected programs: 104 -> 122 (17.31%) Signed-off-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* freedreno/a6xx: Share shader state constructor and destructorKristian H. Kristensen2019-09-186-190/+76
| | | | | | | Also, swap vs and fs constructor or so fs comes first. Signed-off-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* freedreno/a6xx: Track location of gl_Position out as we link itKristian H. Kristensen2019-09-183-13/+13
| | | | | | | | | | | | | | When using xfb and rasterizing, the fragment shader may have fewer inputs than the vertex shader outputs. We can't rely on gl_Position to be placed at fs->total_in, but have to instead remember where we add it in the link map and use that location. Fixes 100+ tesselation dEQPs under dEQP-GLES31.functional.tessellation.primitive_discard.* dEQP-GLES31.functional.tessellation.user_defined_io.* Reviewed-by: Eric Anholt <[email protected]>
* spirv: Add missing break for capability handlingCaio Marcelo de Oliveira Filho2019-09-181-0/+1
| | | | | | | New added cases "stole" the previous break. Fixes: 420ad0a1a3d ("spirv: check support for SPV_KHR_float_controls capabilities") Reviewed-by: Eric Engestrom <[email protected]>
* iris: Avoid uploading SURFACE_STATE descriptors for UBOs if possibleKenneth Graunke2019-09-183-17/+53
| | | | | | | | | | | | | | | | | | If we can entirely push uniform data, we don't need a SURFACE_STATE descriptor for pulling data. Since constant uploads are a very common operation, and being able to push all data is also very common, we would like to avoid the overhead in this case. This patch defers uploading new descriptors. Instead of handling that at iris_set_constant_buffer, we do it at iris_update_compiled_shaders, where we can see the currently bound shader variants. If any need pull descriptors, and descriptors are missing, we update them and flag that the binding table also needs to be refreshed. Improves performance in GFXBench5 gl_driver2 on an i7-6770HQ by 31.9774% +/- 1.12947% (n=15). Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* intel/compiler: Record whether any pull constant loads occurKenneth Graunke2019-09-183-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | I would like for iris to be able to avoid setting up SURFACE_STATE for UBOs in the common case where all constants are pushed. Unfortunately, we don't know up front whether everything will be pushed: the backend is allowed to demote pushed UBOs to pull loads fairly late in the process. This is probably desirable though, as we'd like the backend to be able to re-pull pushed data to break up long live ranges in response to register pressure. Here we simply add a "are there any pull loads at all" boolean to prog_data, which is a bit crude but at least allows us to skip work in the common "everything pushed" case. We could skip more work by tracking exactly which UBO surfaces are pulled in a bitmask, but I wanted to avoid bringing back the old mark_surface_used() mechanism. Finer-grained tracking could allow us to skip a bit more work when multiple UBOs are in use and /some/ are 100% pushed, but others are accessed via pulls. However, I'm not sure how common this is and it would save at most 4 pull descriptors, so we defer that for now. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* iris: Track per-stage bind history, reduce work accordinglyKenneth Graunke2019-09-184-6/+16
| | | | | | | | | | | | | | We now track per-stage bind history for constant and shader buffers, shader images, and sampler views by adding an extra res->bind_stages field to go with res->bind_history. This lets us flag IRIS_DIRTY_CONSTANTS for only the specific stages involved, and also skip some CPU overhead in iris_rebind_buffer. Cuts 4% of 3DSTATE_CONSTANT_XS packets in a Shadow of Mordor trace on Icelake. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* iris: Don't flag IRIS_DIRTY_BINDINGS for constant usage historyKenneth Graunke2019-09-181-2/+1
| | | | | | | | | | | | | | | | | | | The underlying buffer isn't changing - so we don't need to update any SURFACE_STATE descriptors - we just might have new constants, meaning we need to re-emit 3DSTATE_CONSTANT_XS. On Gen9, this means we need to update 3DSTATE_BINDING_TABLE_POINTERS_XS too, but that's now handled by the explicit check in the previous patch. On Gen9, this should cause us to re-emit the binding table /pointer/ on writing to a buffer with PIPE_BIND_CONSTANT_BUFFER, rather than emitting a whole new /table/. On Gen8 and Gen11, this avoids binding table churn altogether. Cuts 61% of 3DSTATE_BINDING_TABLE_POINTERS_XS packets in a Shadow of Mordor trace on Icelake. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* iris: Explicitly emit 3DSTATE_BTP_XS on Gen9 with DIRTY_CONSTANTS_XSKenneth Graunke2019-09-181-1/+6
| | | | | | | | | | | | | Right now, we usually flag both IRIS_DIRTY_{CONSTANTS,BINDINGS}_XS, because we have SURFACE_STATE for constant buffers in case the shaders access them via pull mode. But this flagging is overkill in many cases. Gen8 and Gen11 don't need it at all. Gen9 doesn't need that large of a hammer in all cases. Just handle it explicitly so the right thing happens. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* iris: Flag IRIS_DIRTY_BINDINGS_XS on constant buffer rebindsKenneth Graunke2019-09-181-1/+2
| | | | | | | We upload a new SURFACE_STATE for the UBO/SSBO in question, which means that we need new binding tables as well. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* radv: Add DFSM support.Bas Nieuwenhuizen2019-09-181-5/+17
| | | | | | | | | | | | Apparently we already enabled it without having support ... Not sure if we also need to set disable_start_of_prim when the PS has memory writes, but this mirrors radeonsi. Doubles fillrate in my dual_quad_bench from ~16 pixels/cycles to ~32 pixels/cycle on a Raven. Reviewed-by: Samuel Pitoiset <[email protected]>
* radv: Disable dfsm by default even on Raven.Bas Nieuwenhuizen2019-09-182-3/+4
| | | | | | When actually implementing it, Talos on low is still 3% slower. Reviewed-by: Samuel Pitoiset <[email protected]>
* radv: Only break batch on framebuffer change with dfsm.Bas Nieuwenhuizen2019-09-181-1/+1
| | | | Reviewed-by: Samuel Pitoiset <[email protected]>
* nir/opt_if: Fix undef handling in opt_split_alu_of_phi()Connor Abbott2019-09-181-55/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pass assumed that "Most ALU ops produce an undefined result if any source is undef" which is completely untrue. Due to how we lower if statements to selects and then optimize on those selects later, we simply cannot make that assumption. In particular this pass tried to replace an ior of undef and true, which had been generated by optimizing a select which itself came from flattening an if statement, to undef causing a miscompilation for a CTS test with radeonsi NIR. We fix this by always doing what the non-undef path did, i.e. duplicate the instruction twice. If there are cases where the instruction before the loop can be folded away due to having an undef source, we should add these to opt_undef instead. The comment above the pass says that if the phi source from before the loop is undef, and we can fold the instruction before the loop to undef, then we can ignore sources of the original instruction that don't dominate the block before the loop because we don't need them to create the instruction before the loop. This is incorrect, because the instruction at the bottom of the loop would get those sources from the wrong loop iteration. The code never actually did what the comment said, so we only have to update the comment to match what the pass actually does. We also update the example to more closely match what most actual loops look like after vtn and peephole_select. There are no shader-db changes with i965, radeonsi NIR, or radv. With anv and my vkpipeline-db there's only one change: total instructions in shared programs: 14125290 -> 14125300 (<.01%) instructions in affected programs: 2598 -> 2608 (0.38%) helped: 0 HURT: 1 total cycles in shared programs: 2051473437 -> 2051473397 (<.01%) cycles in affected programs: 36697 -> 36657 (-0.11%) helped: 1 HURT: 0 Fixes KHR-GL45.shader_subroutine.control_flow_and_returned_subroutine_values_used_as_subroutine_input with radeonsi NIR.
* gl: drop incorrect pkg-config file for glvndEric Engestrom2019-09-181-12/+2
| | | | | | | | | | | | | | | Akin to 1a25980c469b38d2c645 ("egl: drop incorrect pkg-config file for glvnd") and b01524fff05eef66e8cd ("meson: don't build libGLES*.so with GLVND") , removes a pkg-config file that shouldn't have been there in the first place, but was needed because of that GLVND bug. Now that the glvnd bug has been fixed, it was apparent that this gl.pc pkg-config file was forgotten to be removed, so let's do just that :) Suggested-by: Matt Turner <[email protected]> Cc: [email protected] Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* nir/opcodes: Clear variable names confusionAndres Gomez2019-09-181-10/+15
| | | | | | | | | | | Having Python and C variables sharing name in the same block of code makes its understanding a bit confusing. Make it explicit that the Python bit_size variable refers to the destination bit size. Suggested-by: Caio Marcelo de Oliveira Filho <[email protected]> Signed-off-by: Andres Gomez <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* radv: never kill a NGG GS shaderRhys Perry2019-09-181-1/+3
| | | | | | | | Seems to fix a hang with excessive vertex emissions when NGG is used for GS. Signed-off-by: Rhys Perry <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radv/gfx10: fix VK_KHR_pipeline_executable_properties with NGG GSSamuel Pitoiset2019-09-181-4/+13
| | | | | | | | | | | No GS copy shader if a pipeline enables NGG GS. This fixes dEQP-VK.pipeline.executable_properties.graphics.*geometry_stage*. Fixes: 86864eedd2d ("radv: Implement radv_GetPipelineExecutablePropertiesKHR.") Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radeonsi: include drm_fourcc.h to fix the buildMarek Olšák2019-09-181-0/+1
|
* radeonsi: implement pipe_screen::resource_get_paramMarek Olšák2019-09-181-22/+78
| | | | | | v2: return DRM_FORMAT_MOD_INVALID from the function Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* gallium: extend resource_get_param to be as capable as resource_get_handleMarek Olšák2019-09-187-16/+56
| | | | | Reviewed-by: Tapani Pälli <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* ac: move ac_get_num_physical_vgprs into radeon_infoMarek Olšák2019-09-183-13/+5
| | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* ac: move ac_get_num_physical_sgprs into radeon_infoMarek Olšák2019-09-185-17/+17
| | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* ac: move ac_get_max_wave64_per_simd into radeon_infoMarek Olšák2019-09-184-18/+6
| | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* ac: move num_sdp_interfaces into radeon_infoMarek Olšák2019-09-184-30/+17
| | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* ac: move PBB MAX_ALLOC_COUNT into radeon_infoMarek Olšák2019-09-184-62/+35
| | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* etnaviv: fix two-sided stencilJonathan Marek2019-09-185-30/+44
| | | | | | | | | | | | | * Set missing STENCIL_CONFIG_EXT2 bits * Swap stencil sides when rendering CCW Fixes following deqp tests (which were 99% failing): dEQP-GLES2.functional.fragment_ops.depth_stencil.* Note: deqp tests require --deqp-gl-config-name=rgba8888d24s8ms0 Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]>
* radv: fix loading 64-bit GS inputsSamuel Pitoiset2019-09-181-0/+35
| | | | | | | | | | | We have to load 2 32-bit integer and to cast correctly. This fixes crashes with gs-double-interpolator.vk_shader_test. Cc: 19.2 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111734 Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* tu: Set up glsl types.Bas Nieuwenhuizen2019-09-181-0/+3
| | | | | | | | | | | Addresses this assert: deqp-vk: ../mesa-freedreno-9999/src/compiler/glsl_types.cpp:1244: static const glsl_type *glsl_type::get_interface_instance(const glsl_struct_field *, unsigned int, enum glsl_interface_packing, bool, const char *): Assertion `glsl_type_users > 0' failed. running dEQP-VK.api.smoke.triangle . Fixes: 624789e3708 "compiler/glsl: handle case where we have multiple users for types" Reviewed-by: Lionel Landwerlin <[email protected]>
* radv: fix writing depth/stencil clear values to imageSamuel Pitoiset2019-09-181-3/+4
| | | | | | | | | Use the fastest way only if both aspects are used. Oops. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111728 Fixes: 218ce34962c ("radv: add mipmap support for the clear depth/stencil values") Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* i965: support AYUV/XYUV for external import onlyHaihao Xiang2019-09-181-0/+2
| | | | | | | | | Fixes: 89785e2d56e7fa ("i965: add support for sampling from AYUV") Fixes: 7cab8d3661f243 ("i965: Add support for sampling from XYUV images") Cc: Vivek Kasireddy <[email protected]> Cc: Lionel Landwerlin <[email protected]> Signed-off-by: Haihao Xiang <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* panfrost: Allocate tiler and scratchpad BOs per-batchBoris Brezillon2019-09-184-41/+68
| | | | | | | | | If we want to execute several batches in parallel they need to have their own tiler and scratchpad BOs. Let move those objects to panfrost_batch and allocate them on a per-batch basis. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Add FBO BOs to batch->bos earlierBoris Brezillon2019-09-184-3/+17
| | | | | | | | | | If we want the batch dependency tracking to work correctly we must make sure all BOs are added to the batch->bos set early enough. Adding FBO BOs when generating the fragment job is clearly to late. Add a panfrost_batch_add_fbo_bos helper and call it in the clear/draw path. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Add the panfrost_batch_create_bo() helperBoris Brezillon2019-09-184-25/+28
| | | | | | | | This helper automates the panfrost_bo_create()+panfrost_batch_add_bo()+ panfrost_bo_unreference() sequence that's done for all per-batch BOs. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Don't return imported/exported BOs to the cacheBoris Brezillon2019-09-182-0/+9
| | | | | | | | We don't know who else is using the BO in that case, and thus shouldn't re-use it for something else. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Add panfrost_bo_{alloc,free}()Boris Brezillon2019-09-181-76/+68
| | | | | | | | | Thanks to that we avoid the recursive call into panfrost_bo_create() and we can get rid of panfrost_bo_release() by inlining the code in panfrost_bo_unreference(). Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Stop using panfrost_bo_release() outside of pan_bo.cBoris Brezillon2019-09-184-7/+8
| | | | | | | | | | | | | | | panfrost_bo_unreference() should be used instead. The only difference caused by this change is that the scratchpad, tiler_heap and tiler_dummy BOs are now returned to the cache instead of being freed when a context is destroyed. This is only a problem if we care about context isolation, which apparently is not the case since transient BOs are already returned to the per-FD cache (and all contexts share the same address space anyway, so enforcing context isolation is almost impossible). Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Stop passing screen around for BO operationsBoris Brezillon2019-09-187-37/+37
| | | | | | | | Store a screen pointer in panfrost_bo so we don't have to pass a screen object to all functions manipulating the BO. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Don't check if BO is mmaped before calling panfrost_bo_mmap()Boris Brezillon2019-09-181-5/+1
| | | | | | | panfrost_bo_mmap() already takes care of that. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Stop exposing panfrost_bo_cache_{fetch,put}()Boris Brezillon2019-09-182-8/+2
| | | | | | | | They are not expected to be called directly, users should use panfrost_bo_{create,release}() instead. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Move the BO API to its own headerBoris Brezillon2019-09-1816-74/+112
| | | | | | | | Right now, the BO API is spread over pan_{allocate,resource,screen}.h. Let's move all BO related definitions to a separate header file. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: s/PAN_ALLOCATE_/PAN_BO_/Boris Brezillon2019-09-187-19/+19
| | | | | | | | Change the prefix for BO allocation flags to make it consistent with the rest of the BO API. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Move panfrost_bo_{reference,unreference}() to pan_bo.cBoris Brezillon2019-09-182-19/+20
| | | | | | | | This way we have all BO related functions placed in the same source file. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>
* panfrost: Get rid of pan_drm.cBoris Brezillon2019-09-1812-444/+382
| | | | | | | | | | | | | | | | pan_drm.c was only meaningful when we were supporting 2 kernel drivers (mali_kbase, and the drm one). Now that there's now kernel-driver abstraction we're better off moving those functions were they belong: * BO related functions in pan_bo.c * fence related functions + query_gpu_version() in pan_screen.c * submit related functions in pan_job.c While at it, we rename the functions according to the place they're being moved to. Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]>