For some reason the 2d engine can't handle this. Red formats get special
treatment there, so perhaps related.
Fixes dEQP-GLES3 tests of the form:
dEQP-GLES3.functional.fbo.blit.conversion.r{8,16f,32f}_to_srgb8_alpha8
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: mesa-stable@lists.freedesktop.org
The current state tracker can generate these sometimes. Fixing this is
more involved, and due to some integer math we can generate
divisions-by-zero.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: mesa-stable@lists.freedesktop.org
As with a5xx, hidden behind FD_MESA_DEBUG=lrz due to being paranoid
about z-fighting issues with some games (in particular, this was
observed with 0ad on a5xx.. but I think the proper solution to enable
this by default is to figure out how to do driver specific driconf
options).
Signed-off-by: Rob Clark <robdclark@gmail.com>
For testing it is of interest that all tests of dEQP pass, e.g. to test
virglrenderer on a host only providing software rendering like in a CI.
Hence make it possible to disable certain optimizations that make tests fail.
While we are there also add some documentation to the flags to make it clear
that this is opt-out.
Setting the environment variable "GALLIVM_PERF=no_filter_hacks" can be used to make
the following tests pass in release mode:
dEQP-GLES2.functional.texture.mipmap.2d.affine.*_linear_*
dEQP-GLES2.functional.texture.mipmap.cube.generate.*
dEQP-GLES2.functional.texture.vertex.2d.filtering.*_mipmap_linear_*
dEQP-GLES2.functional.texture.vertex.2d.wrap.*
Related:
https://bugs.freedesktop.org/show_bug.cgi?id=94957
v2: rename optimization disabling flag to 'safemath' and also move the
nopt flag to the perf flags.
v3: rename flag "safemath" to "no_filter_hacks" since safemath is usually
associated with floating point operations (Roland)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Pass the size of a resource when creating it so a backing can be kept in
the other side.
Also pass the required offset to transfer commands.
This moves vtest closer to how virtio-gpu works, making it more useful
for testing.
v2: - Use new messages for creation and transfers, as changing the
behavior of the existing messages would be messy given that we don't
want to break compatibility with older servers.
v3: - Use correct strides: The resource corresponding to the output display
might have a differnt line stride then the IOVs, so when reading back
to this resource take the resource stride and the the IOV stride
into account.
v4: Fix transfer size calculation (Andrey Simiklit)
v5: Add comment about transfer size value in the PUT commend (Gurchetan).
Add a comment about the size correction for transfers for reading and
writing the resource. Fixing this by correctly evaluating the size
upfront will need some work also on the virglrenderer side.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> (v2)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The transfer size used in virglrenderer refers to uint32_t, so one
must add 3 and then divide by 4 instead of adding 3/4 which is a no-op
with integers.
Fixes: b3b82fe8ea virgl/vtest: add vtest driver
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
reg_saved will have 64 bits, and (1 << reg) where reg > 31 has undefined
behavior. (1ull << reg) would be correct for 64 bits.
This commit shifts the other way in order to merge the conditions.
Check if server supports version negotation by sending a PING_PROTOCOL_VERSION
message right before a dummy RESOURCE_BUSY_WAIT. If we don't get a reply
for the first, we know the server doesn't support it.
If it does support it, we can query the max protocol version supported
by the server and fall back if needed.
v2: - Send a new message to negotiate the protocol version, checking if
the server supports this message by immediately sending a busy wait
message. (Dave Airlie)
v3: - Send a zero-arg command PING_PROTOCOL_VERSION so we actually keep
compatibility with older servers. (Code by Dave Airlie)
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Add the files otherwise things just won't build.
Haven't actually tested it, but it's a small step in the right
direction.
Fixes: de3b34df97 ("freedreno: Add a6xx backend")
Cc: Kristian H. Kristensen <hoegsberg@chromium.org>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
The pipe_loader_release API closes the fd given, even if the pipe-loader
should _not_ take ownership of it.
With earlier commit we fixed pipe_loader_drm_probe_fd, and now with
cover the final piece.
Note that unlike the DRM case, here the caller _did_ forget to dup
before using it ... most likely leading to all sorts of fun.
Don't forget the close in the error path. Seems like the things are a
bit leaky/asymmetrical with the semi-recent config work. But we can shave
that yak another day ;-)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Currently pipe_loader_drm_probe_fd takes ownership of the fd given.
To match that, pipe_loader_release closes it.
Yet we have many instances which do not want the change of ownership,
and thus duplicate the fd before passing it to the pipe-loader.
Move the dup() within pipe-loader, explicitly document that and document
all the cases through the codebase.
A trivial git grep -2 pipe_loader_release makes things as obvious as it
gets ;-)
Cc: Leo Liu <leo.liu@amd.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Axel Davy <davyaxel0@gmail.com>
Cc: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Axel Davy <davyaxel0@gmail.com> (for nine)
As the newly introduced comment says:
The pipe loader takes ownership of the fd
Thus, there's no need to close it again.
Cc: Patrick Rudolph <siro@das-labor.org>
Cc: Axel Davy <davyaxel0@gmail.com>
Cc: mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <davyaxel0@gmail.com>
Earlier commit added support for 'front_buffers', erroneously adding a
return in vl_dri3_screen_destroy. Effectively leaking a lot of state.
Fixes: 8d7ac0a4e4 ("vl/dri3: implement DRI3 BufferFromPixmap")
Cc: Leo Liu <leo.liu@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
The header was used only by dri2.c, containing a two-member struct and cast wrapper.
Just inline it where it's used/needed.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
As discussed in the review of the patch which added the comment:
Nothing happens when a thread is created, because pthread_atfork doesn't
affect creating threads. However, spawning a child process will likely
crash.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Pulling this logic out means we can share the logic and avoid a couple
of temporary variables that helped make things clearer before. Note
that in either vismode case, we always program vismode 0.
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Now that we've copied the emit logic into each branch of the
if (info->index_size) statement, we can simplify the logic a bit
according to which case we're in.
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
This splits the two code paths into separate functions and moves the
"if (info->indirect)" test into draw_impl().
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
