From f3cc0d2747568a186dba433ac94af607c38fa024 Mon Sep 17 00:00:00 2001 From: Rob Clark Date: Sun, 21 Oct 2018 10:22:11 -0400 Subject: freedreno: import libdrm_freedreno + redesign submit In the pursuit of lowering driver overhead, it became clear that some amount of redesign of how libdrm_freedreno constructs the submit ioctl would be needed. In particular, as the gallium driver is starting to make heavier use of CP_SET_DRAW_STATE state groups/objects, the over- head of tracking cmd buffers and relocs becomes too much. And for "streaming" state, which isn't ever reused (like uniform uploads) the overhead of allocating/freeing ringbuffer[1] objects is too high. This redesign makes two main changes: 1) Introduces a fd_submit object for tracking bos and cmds table for the submit ioctl, making ringbuffer objects more light- weight. This was previously done in the ringbuffer. But we have many ringbuffer instances involved in a submit (gmem + draw + potentially 1000's of state-group rbs), and only need a single bos and cmds table. (Reloc table is still per-rb) The submit is also a convenient place for a slab allocator for ringbuffer objects. Other options would have required locking because, while we can guarantee allocations will only happen on a single thread, free's could happen either on the application thread or the flush_queue thread. With the slab allocator in the submit object, any frees that happen on the flush_queue thread happen after we know that the application thread is done with the submit. 2) Introduce a new "softpin" msm_ringbuffer_sp implementation that does not use relocs and only has cmds table entries for IB1 (ie. the cmdstream buffers that kernel needs to CP_INDIRECT_BUFFER to from the RB). To do this properly will require some updates on the kernel side, so whether you get the softpin or legacy submit/ringbuffer implementation at runtime depends on your kernel version. To make all these changes in libdrm would basically require adding a libdrm_freedreno2, so this is a good point to just pull the libdrm code into mesa. Plus it allows for using mesa's hashtable, slab allocator, etc. And it lets us have asserts enabled for debug mesa buids but omitted for release builds. And it makes life easier if further API changes become necessary. At this point I haven't tried to pull in the kgsl backend. Although I left the level of vfunc indirection which would make it possible to have other backends. (And this was convenient to keep to allow for the "softpin" ringbuffer to coexist.) NOTE: if bisecting a build error takes you here, try a clean build. There are a bunch of ways things can go wrong if you still have libdrm_freedreno cflags. [1] "ringbuffer" is probably a bad name, the only level of cmdstream buffer that is actually a ring is RB managed by kernel. User- space cmdstream is all IB1/IB2 and state-groups. Reviewed-by: Kristian H. Kristensen Reviewed-by: Eric Engestrom Signed-off-by: Rob Clark --- meson.build | 3 --- 1 file changed, 3 deletions(-) (limited to 'meson.build') diff --git a/meson.build b/meson.build index 690e7d3d8aa..18667988bac 100644 --- a/meson.build +++ b/meson.build @@ -1099,14 +1099,12 @@ dep_libdrm_amdgpu = null_dep dep_libdrm_radeon = null_dep dep_libdrm_nouveau = null_dep dep_libdrm_etnaviv = null_dep -dep_libdrm_freedreno = null_dep dep_libdrm_intel = null_dep _drm_amdgpu_ver = '2.4.95' _drm_radeon_ver = '2.4.71' _drm_nouveau_ver = '2.4.66' _drm_etnaviv_ver = '2.4.89' -_drm_freedreno_ver = '2.4.96' _drm_intel_ver = '2.4.75' _drm_ver = '2.4.75' @@ -1117,7 +1115,6 @@ _libdrm_checks = [ with_gallium_r300 or with_gallium_r600)], ['nouveau', (with_gallium_nouveau or with_dri_nouveau)], ['etnaviv', with_gallium_etnaviv], - ['freedreno', with_gallium_freedreno], ] # VC4 only needs core libdrm support of this version, not a libdrm_vc4 -- cgit v1.2.3