We are about to add more to this function, so let's try to automate
the cleanup steps in the error path. Incrementing image_count as
we add new images to the swapchain allows us to call
wsi_win32_swapchain_destroy() even if not all images were initialized.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16200>
This release (23.0) contains less features than usual but the last
branchpoint was delayed and we had end of year holidays.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20609>
The render server path is required by crosvm to enable render server.
v2: updated script to package server binary properly
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com> (v1)
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19542>
If a shader's sampler state is dirty often, the sampler descriptor heap
can get used up quickly, forcing flushing. If that happens quickly, we
run out of batches and have to wait for batches to finish on the GPU.
When this happens, it is often because the sampler state is switching,
not because it's truly unique. This change hashes and saves sampler
descriptor tables that can be reused in subsequent draws in the same
batch, instead of re-copying the same descriptors and consuming the
heap.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20618>
The maximum number of mipmap levels supported for cubemap can be
determined from the maximum 2D texture size. There is no need
to limit the max to 12.
This fixes a regression in creating GL4.1 and up context since
commit 2658d02516 is now explicitly checking for
MaxCubeTextureLevels >= 15 for GL4.1 context.
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20600>
We already show the address range, which is most of why I'd think you'd be
looking at hex values. I find a more human-readable number nice for
debugging, instead of counting zeroes to decide if it's 1.5MB or 96kb.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20540>
We are now extremelly careful when copy propagating a mov that uses
relative addressing. The search for readers will trigger abort when it
sees any other instruction using a relative addressing, irrespective of
the actual used registers or whether an address register load was seen.
Additionally, since ntt switch all movs using the relative addressing are
actually used only once right on the next line, and are result of ntt converting
vec4 32 ssa_10 = intrinsic load_ubo_vec4 (ssa_0, ssa_9) (access=0, base=11, component=0)
into
5: ARL ADDR[0].x, TEMP[0].xxxx
6: MOV TEMP[2], CONST[0][ADDR[0].x+11]
RV530 shader-db:
total instructions in shared programs: 132966 -> 131904 (-0.80%)
instructions in affected programs: 29896 -> 28834 (-3.55%)
helped: 234
HURT: 2
total temps in shared programs: 16969 -> 16905 (-0.38%)
temps in affected programs: 604 -> 540 (-10.60%)
helped: 68
HURT: 12
Partial fix for: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7723
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20577>
We can use the new functionality in the draw-helper to implement
stippled smooth lines instead of what we currently do, which is aliased
stipping on smooth lines.
Reviewed-by: Soroush Kashani <soroush.kashani@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20134>
When computing line smoothing, we can also do something similar to
compute the line stippling. This can be useful for some drivers, who
can't easily split the lines before rasterizing them.
This does lead to slightly inaccurate stippling, because the
line-smoothing extends the line-length by a small amount. That leads to
the line-stippling pattern being over-stretched over the line-segment by
a fraction of a pixel in lenght. For short lines, this can be quite a
lot of error.
Reviewed-by: Soroush Kashani <soroush.kashani@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20134>
I'm convinced that u_blitter interactions with fbfetch can't be handled
in si_update_ps_colorbuf0_slot alone, so it has to be force-disabled
by si_blitter_begin. Another reason why it has to be disabled for u_blitter
and not ignored is because FBFETCH with MSAA enables sample shading
regardless of context states, and we don't want that for u_blitter.
Also, si_update_ps_colorbuf0_slot now disables FBFETCH explicitly before
its own DCC and CMASK decompression because even though u_blitter can't do
anything (due to blitter_running), si_blitter_end calls it too.
The result is that no recursion can occur thanks to the blitter_running
and suppress_update_ps_colorbuf0_slot flags, and FBFETCH is always
force-disabled before those flags are set, which is the state we want
to be in.
Fixes: bc6d22b920 ("radeonsi: fix ps_uses_fbfetch value")
Acked-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20318>
The Mesa CI LAVA job submitter was suffering from a bug in the LAVA
software that made their timeouts related to sub-actions unreliable,
such as waiting for the user login prompt automatic response.
The following MR
https://git.lavasoftware.org/lava/lava/-/merge_requests/1900 fixed this
issue. So we can now better control job timeouts granularity, failing
the job faster when there is something weird hanging the boot stage.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20596>
TS sharing isn't fully stable yet. There are some fixes pending, but they
don't take care of all reported issues. Hide TS sharing behind a debug
switch until all the known issues are resolved.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20606>
It looks like the LLVM assembler promotes true 16-bit instructions to VOP3
in this case.
No fossil-db changes.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20251>
Comparing the 64bit clear value to the lower half 32bit clear state is
obviously wrong and results in a lot of false positives.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20586>
