Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
On 2020-02-04 8:12 p.m., Keith Packard wrote: > Michel Dänzer writes: > >> Hmm, I didn't fully realize this in my reading of the draft, thanks >> Matias for pointing it out! >> >> That the timing of frame N+1 has to be specified when submitting frame >> N for presentation is odd to me TBH. While I can imagine this might be >> suitable for some apps such as video players, I'm skeptical about game >> engines. They would need to calculate frame time budget and choose >> simulation time for frame N+1 before submitting frame N for >> presentation. Is that really how game engines (want to) work? > > It's not asking the application to figure this out much earlier -- the > application needs to know the target time for the next frame before > starting any of the frame computations, and that happens right after > submitting the previous frame. > > The goal here is to provide the display system the timing information as > soon as the application knows it, in case that helps the backend work > better. With variable refresh rate, it could certainly be useful for the kernel to have this information as early as possible. It shouldn't make any difference with fixed refresh though, since the kernel should always be able to hit the next refresh in that case as long as the fences for the flip signal in time for vertical blank. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: Add format modifier aux plane query
Seems like you missed zink
On February 5, 2020 9:36:26 PM GMT+01:00, James Jones
wrote:
>Rather than hard-code a list of all the format
>modifiers supported by any gallium driver in
>the dri state tracker, add a screen proc that
>queries the number of auxiliary planes required
>for a given modifier+format pair.
>
>Since the only format modifier that requires
>auxiliary planes currently is the iris driver's
>I915_FORMAT_MOD_Y_TILED_CCS, provide a generic
>implementation of this screen proc as a utility
>function, and use that in every driver besides
>the iris driver, which requires a trivial
>customization on top of it.
>
>Signed-off-by: James Jones
>---
> src/gallium/auxiliary/util/u_screen.c | 35 ++
> src/gallium/auxiliary/util/u_screen.h | 7
> src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
> .../drivers/freedreno/freedreno_screen.c | 1 +
> src/gallium/drivers/iris/iris_resource.c | 17 +
> src/gallium/drivers/lima/lima_screen.c| 1 +
> .../drivers/nouveau/nvc0/nvc0_resource.c | 2 ++
> src/gallium/drivers/tegra/tegra_screen.c | 12 +++
> src/gallium/drivers/v3d/v3d_screen.c | 1 +
> src/gallium/drivers/vc4/vc4_screen.c | 1 +
> src/gallium/include/pipe/p_screen.h | 15
> src/gallium/state_trackers/dri/dri2.c | 36 ---
> 12 files changed, 107 insertions(+), 22 deletions(-)
>
>diff --git a/src/gallium/auxiliary/util/u_screen.c
>b/src/gallium/auxiliary/util/u_screen.c
>index 785d1bd3e24..0697d483372 100644
>--- a/src/gallium/auxiliary/util/u_screen.c
>+++ b/src/gallium/auxiliary/util/u_screen.c
>@@ -412,3 +412,38 @@ u_pipe_screen_get_param_defaults(struct
>pipe_screen *pscreen,
> unreachable("bad PIPE_CAP_*");
>}
> }
>+
>+bool
>+u_pipe_screen_get_modifier_aux_planes(struct pipe_screen *pscreen,
>+ uint64_t modifier,
>+ enum pipe_format format,
>+ unsigned *num_aux_planes)
>+{
>+ int num_mods, i;
>+ uint64_t *supported_mods;
>+
>+ pscreen->query_dmabuf_modifiers(pscreen, format, 0, NULL, NULL,
>+ &num_mods);
>+
>+ if (!num_mods)
>+ return false;
>+
>+ supported_mods = malloc(num_mods * sizeof(supported_mods[0]));
>+
>+ if (!supported_mods)
>+ return false;
>+
>+ pscreen->query_dmabuf_modifiers(pscreen, format, num_mods,
>supported_mods,
>+ NULL, &num_mods);
>+
>+ for (i = 0; i < num_mods && supported_mods[i] != modifier; i++);
>+
>+ free(supported_mods);
>+
>+ if (i == num_mods)
>+ return false;
>+
>+ *num_aux_planes = 0;
>+
>+ return true;
>+}
>diff --git a/src/gallium/auxiliary/util/u_screen.h
>b/src/gallium/auxiliary/util/u_screen.h
>index 3952a11f2ca..0abcfd282b1 100644
>--- a/src/gallium/auxiliary/util/u_screen.h
>+++ b/src/gallium/auxiliary/util/u_screen.h
>@@ -23,6 +23,7 @@
>
> struct pipe_screen;
> enum pipe_cap;
>+enum pipe_format;
>
> #ifdef __cplusplus
> extern "C" {
>@@ -32,6 +33,12 @@ int
> u_pipe_screen_get_param_defaults(struct pipe_screen *pscreen,
> enum pipe_cap param);
>
>+bool
>+u_pipe_screen_get_modifier_aux_planes(struct pipe_screen *pscreen,
>+ uint64_t modifier,
>+ enum pipe_format format,
>+ unsigned *num_aux_planes);
>+
> #ifdef __cplusplus
> };
> #endif
>diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c
>b/src/gallium/drivers/etnaviv/etnaviv_screen.c
>index dcceddc4729..32909a4e5ea 100644
>--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
>+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
>@@ -1019,6 +1019,7 @@ etna_screen_create(struct etna_device *dev,
>struct etna_gpu *gpu,
>pscreen->context_create = etna_context_create;
>pscreen->is_format_supported = etna_screen_is_format_supported;
> pscreen->query_dmabuf_modifiers = etna_screen_query_dmabuf_modifiers;
>+ pscreen->get_modifier_aux_planes =
>u_pipe_screen_get_modifier_aux_planes;
>
>etna_fence_screen_init(pscreen);
>etna_query_screen_init(pscreen);
>diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
>b/src/gallium/drivers/freedreno/freedreno_screen.c
>index 3c0ed69a9cb..5d25df02ebf 100644
>--- a/src/gallium/drivers/freedreno/freedreno_screen.c
>+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
>@@ -984,6 +984,7 @@ fd_screen_create(struct fd_device *dev, struct
>renderonly *ro)
> pscreen->fence_get_fd = fd_fence_get_fd;
>
> pscreen->query_dmabuf_modifiers = fd_screen_query_dmabuf_modifiers;
>+ pscreen->get_modifier_aux_planes =
>u_pipe_screen_get_modifier_aux_planes;
>
> if (!screen->supported_modifiers) {
> static const uint64_t supported_modifiers[] = {
>diff --git a/src/gallium/drivers/iris/iris_resource.c
>b/src/gallium/drivers/i
[Mesa-dev] [ANNOUNCE] mesa 20.0.0-rc2
Hi list, Sorry for the late -rc2, it's my fault. I was out of the office Monday and Tuesday and kinda lost track of time :/ Anyway, There's a lot of stuff in here, as is typical for -rc2. We've got a ton of intel related fixes from Jason, and then a bunch of stuff touching every bit of the tree. Next week -rc3 will come on Wednesday as planned Dylan Shortlog Bas Nieuwenhuizen (1): radv: Do not set SX DISABLE bits for RB+ with unused surfaces. Bernd Kuhls (1): util/os_socket: Include unistd.h to fix build error Boris Brezillon (1): panfrost: Fix the damage box clamping logic Daniel Schürmann (1): aco: fix image_atomic_cmp_swap Danylo Piliaiev (2): i965: Do not set front_buffer_dirty if there is no front buffer st/mesa: Handle the rest renderbuffer formats from OSMesa Dylan Baker (6): bin/pick-ui: Add a new maintainer script for picking patches .pick_status.json: Update to 0d14f41625fa00187f690f283c1eb6a22e354a71 .pick_status.json: Update to b550b7ef3b8d12f533b67b1a03159a127a3ff34a .pick_status.json: Update to 9afdcd64f2c96f3fcc1a28912987f2e8066aa995 .pick_status.json: Update to 7eaf21cb6f67adbe0e79b80b4feb8c816a98a720 VERSION: bump to 20.0-rc2 Eric Engestrom (3): util/os_socket: fix header unavailable on windows freedreno/perfcntrs: fix fd leak util/disk_cache: check for write() failure in the zstd path Erik Faye-Lund (1): st/mesa: use uint-result for sampling stencil buffers Ian Romanick (1): intel/fs: Don't count integer instructions as being possibly coissue Jan Vesely (1): clover: Use explicit conversion from llvm::StringRef to std::string Jason Ekstrand (18): genxml: Add a new 3DSTATE_SF field on gen12 anv,iris: Set 3DSTATE_SF::DerefBlockSize to per-poly on Gen12+ intel/genxml: Drop SLMEnable from L3CNTLREG on Gen11 iris: Set SLMEnable based on the L3$ config iris: Store the L3$ configs in the screen iris: Use the URB size from the L3$ config i965: Re-emit l3 state before BLORP executes intel: Take a gen_l3_config in gen_get_urb_config intel/blorp: Always emit URB config on Gen7+ iris: Consolodate URB emit anv: Emit URB setup earlier intel/common: Return the block size from get_urb_config intel/blorp: Plumb deref block size through to 3DSTATE_SF anv: Plumb deref block size through to 3DSTATE_SF iris: Plumb deref block size through to 3DSTATE_SF anv: Always fill out the AUX table even if CCS is disabled intel/fs: Write the address register with NoMask for MOV_INDIRECT anv/blorp: Use the correct size for vkCmdCopyBufferToImage Krzysztof Raszkowski (1): gallium/swr: Fix gcc 4.8.5 compile error Lionel Landwerlin (1): anv: implement gen9 post sync pipe control workaround Marek Vasut (1): etnaviv: Destroy rsc->pending_ctx set in etna_resource_destroy() Rob Clark (1): freedreno: allow ctx->batch to be NULL Samuel Pitoiset (1): aco: fix MUBUF VS input loads when expanding vec3 to vec4 on GFX6 Vinson Lee (1): lima: Fix build with GCC 10. git tag: mesa-20.0.0-rc2 https://mesa.freedesktop.org/archive/mesa-20.0.0-rc2.tar.xz SHA256: 4166288d6ca26cef5f0e47ddc0660a83e45b76433759550b9fc87353cfa63eef mesa-20.0.0-rc2.tar.xz SHA512: 27e23925ce7e3a38954088db47d564776c4ac7e028d30ef5c58229b3182b461ece37863a69bc42ea4ff0a4817c46c0b0ca8d70f6fafddb5c3fe60bd9c429563b mesa-20.0.0-rc2.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-20.0.0-rc2.tar.xz.sig signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
Michel Dänzer writes: > With variable refresh rate, it could certainly be useful for the kernel > to have this information as early as possible. It shouldn't make any > difference with fixed refresh though, since the kernel should always be > able to hit the next refresh in that case as long as the fences for the > flip signal in time for vertical blank. Although, if the application is mixing present_period and display_timing operations, things can still get mixed up -- a frame with present_period followed by a frame with display_timing can invalidate the computed next frame time. Applications doing that may not get the best possible result... Ok, it sounds like I should at least go clean up the implementation and make it into something not quite so embarrassing to me. Going forward, how can we provide this to application developers for experimentation? Would we consider including it in a release once reviewed within the Mesa community? -- -keith signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
