[Mesa-dev] [ANNOUNCE] mesa 20.1.2
Hi all,
I'd like to announce Mesa 20.1.2, the second bugfix release for the 20.1 branch.
Most of the fixes here are to the AMD drivers, and the rest is scattered
over the tree.
The next bugfix release is planned for 2 weeks from now, on 2020-07-08.
Cheers,
Eric
---
Bas Nieuwenhuizen (3):
vulkan/wsi/x11: Ensure we create at least minImageCount images.
radv/winsys: Deal with realloc failures in BO lists.
radv: Handle mmap failures.
Daniel Schürmann (1):
aco: fix WQM handling in nested loops
Danylo Piliaiev (1):
st/mesa: account for "loose", per-mipmap level textures in
CopyImageSubData
Eric Anholt (2):
freedreno/ir3: Fix register allocation assertion failures.
freedreno/ir3: Fix register allocation assertion failures.
Eric Engestrom (5):
docs/relnotes: add sha256 sums to 20.1.0
.pick_status.json: Update to 4fc0499049fcdb7f892f99ce7abf9d739730138e
v3d: add missing unlock() in error path
docs: Add release notes for 20.1.2
VERSION: bump to 20.1.2 release
Erik Faye-Lund (3):
Revert "gallium/hud: don't use user vertex buffers"
gallium/hud: don't use user vertex buffers
mesa/main: fix inverted condition
Gert Wollny (1):
r600/sfn: Don't set num_components on TESS sysvalue intrinsics
Jan Beich (2):
util: enable futex usage on BSDs after 7dc2f4788288
meson: unbreak sysctl.h detection on BSDs
Jose Maria Casanova Crespo (1):
nir: only uniforms with dynamically_uniform offset are dynamically_uniform
Kristian Høgsberg (1):
freedreno: Handle DRM_FORMAT_MOD_INVALID in shared code
Krzysztof Raszkowski (1):
gallium/swr: Fix building swr with MSVC
Marek Olšák (7):
ac/surface: don't recompute the DCC retile map for imported textures
amd/addrlib: don't recompute DCC info for every ComputeDccAddrFromCoord
call
amd/addrlib: remove unused members of
ADDR2_COMPUTE_DCC_ADDRFROMCOORD_INPUT
ac/surface: add a wrapper structure to hold ADDR_HANDLE
ac/surface: cache DCC retile maps (v2)
ac/surface: don't free dcc_retile_map on failure
ac/nir: fix 64-bit division for GL CTS
Mario Kleiner (1):
vulkan/wsi: Really terminate DRM lease in wsi_release_display().
Pierre-Eric Pelloux-Prayer (1):
st/mesa: make texture views inherit compressed_data storage
Rhys Perry (3):
radv: add new drirc option radv_no_dynamic_bounds
radv: enable radv_no_dynamic_bounds for Path of Exile
radv: enable radv_no_dynamic_bounds for more Path of Exile executables
Samuel Pitoiset (3):
radv: set DB_SHADER_CONTROL.CONSERVATIVE_Z_EXPORT correctly
spirv: fix using OpSampledImage with OpUndef instead of
OpType{Image,Sampler}
radv: lower discards to demote to workaround a RDR2 game bug
Timothy Arceri (2):
glsl: fix incorrect optimisation in opt_constant_variable()
st_glsl_to_nir: fix potential use after free
git tag: mesa-20.1.2
https://mesa.freedesktop.org/archive/mesa-20.1.2.tar.xz
SHA256: 283dff72814c8a80ce1ff8271e3f055895d26f4da3f4362acc49193e635780cb
mesa-20.1.2.tar.xz
SHA512:
467fc6a1cbfc1bc140ba2e6e90a14bd8d15d979b92ba14d084018b6cf22b172767575f5127c6edb5c3bdf12fe6696b27d9975826b3fbb5ad5909d258fc3b8433
mesa-20.1.2.tar.xz
PGP: https://mesa.freedesktop.org/archive/mesa-20.1.2.tar.xz.sig
___
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: > I assume 2. refers to the case of a single late frame, where the next > frame hitting the original absolute target would result in a second > visible stutter. While writing > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/22#note_548234 > , it occurred to me that although a relative target time may avoid > that second stutter, the audio stream needs to adapt to the visual > delay, likely producing audible artifacts instead? It's not obvious to > me that would be an overall win. (The only other way I can think of is > to re-synchronize later frames to the audio stream, but it's not clear > that this is possible without either producing visible stutter again, > or de-synced audio/video for a noticeable period of time) I think the idea is that the application would interpolate time values in the video stream to bring it back in sync with the expected time over a couple of frames. I think we could easily construct a demo which shows the difference and see what we think. I think we could ignore the audio stream as a 16ms lag between audio and video shouldn't be a big deal; we handle that in real life quite easily as that's the lag you get at a distance of about 5m. > P.S. Have you more formally proposed a Vulkan extension in the > meantime? If so, could you provide a reference to that here? No. If I had, the IP restrictions with Khronos would prevent me from discussing it here in any technical detail. -- -keith signature.asc Description: PGP 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
On 2020-02-02 7:51 a.m., Keith Packard wrote: > > I spent some time over the last week experimenting with a different > way of doing frame timing. > > Instead of specifying *when* a particular frame should be > displayed, how about we specify how *long* a particular frame > should be made visible to the user? > > This has a couple of advantages over the approach taken in > GOOGLE_display_timing: > > 1. It provides information to the backend about frame timing a > frame earlier. > > 2. Missing a frame can generate fewer artifacts. I assume 2. refers to the case of a single late frame, where the next frame hitting the original absolute target would result in a second visible stutter. While writing https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/22#note_548234 , it occurred to me that although a relative target time may avoid that second stutter, the audio stream needs to adapt to the visual delay, likely producing audible artifacts instead? It's not obvious to me that would be an overall win. (The only other way I can think of is to re-synchronize later frames to the audio stream, but it's not clear that this is possible without either producing visible stutter again, or de-synced audio/video for a noticeable period of time) P.S. Have you more formally proposed a Vulkan extension in the meantime? If so, could you provide a reference to that here? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
