Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
And just reference pipe_resources to it in the validate callbacks.
Avoids pipe_resource leaks when st_framebuffer_validate ends up calling
the validate callback multiple times, e.g. when a window is resized.
v2:
* Use generic stable tag instead of Fixes: tag, since the problem could
already happen before the commit referenced in v1 (Thomas Hellstrom)
* Use memset to initialize the array on the stack instead of allocating
the array with os_calloc.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Implement the state tracker manager drawable interface flush_swapbuffer
method by plumbing it through to dri3 if available.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
With commit 5124bf9823, a framebuffer interface hash table is
created in st_gl_api_create(), which is called in
dri_init_screen_helper() for each screen. When the hash table is
overwritten with multiple calls to st_gl_api_create(), it can cause
race condition. This patch fixes the problem by creating a
framebuffer interface hash table per state tracker manager.
Fixes crash with steam.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101876
Fixes: 5124bf9823 ("st/mesa: add destroy_drawable interface")
Tested-by: Christoph Haag <haagch@frickel.club>
Reviewed-by: Brian Paul <brianp@vmware.com>
With this patch, the st manager will maintain a hash table for
the active framebuffer interface objects. A destroy_drawable interface
is added to allow the state tracker to notify the st manager to remove
the associated framebuffer interface object from the hash table,
so the associated framebuffer and its resources can be deleted
at framebuffers purge time.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101829
Fixes: 147d7fb772 ("st/mesa: add a winsys buffers list in st_context")
Tested-by: Brad King <brad.king@kitware.com>
Tested-by: Gert Wollny <gw.fossdev@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Commit a5e733c6b5 fixes the dangling
framebuffer object by unreferencing the window system draw/read buffers
when context is released. However this can prematurely destroy the
resources associated with these window system buffers. The problem is
reproducible with Turbine Demo running with VMware driver. In this case,
the depth buffer content was lost when the context is rebound to a
drawable.
To prevent premature destroy of the resources associated with
window system buffers, this patch maintains a list of these buffers in
the context, making sure the reference counts of these buffers will not
reach zero until the associated framebuffer interface objects no
longer exist. This also helps to avoid unnecessary destruction and
re-construction of the resources associated with the framebuffer.
Fixes VMware bug 1909807.
Reviewed-by: Brian Paul <brianp@vmware.com>
required by glClientWaitSync (GL 4.5 Core spec) that can optionally flush
the context
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Fixes Gallium based DRI drivers failing to load on big endian hosts
because they can't find any matching fbconfigs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71789
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Ilia Mirkin <imirkin@alum.mit.edu>
v2: Instead of telling the driver that the window system ancillaries have
been invalidated (when the driver doesn't know which of its buffers
are the window system's!), introduce a method for invalidating
specific surfaces.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Move the driver_name to dri2/drisw and remove all the SPLIT_TAGETS
mayhem. In the next step we'll unify the dri and dri-swrast targets,
completing the gallium DRI megadriver.
v2: Remove leftover st/dri Makefiles from CONFIG_FILES. Spotted by
Thomas Helland.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Rob Clark <robclark@freedesktop.org>
Tested-by: Thomas Helland <thomashelland90 at gmail.com>
Acked-by: Tom Stellard <thomas.stellard@amd.com>
There is currently no user of this new interface. As the inteface can
coexist with st_public.h, everthing should work as before.
ST_TEXTURE_2D is both defined by st_public.h and st_api.h. Reorder the
headers in st/dri to avoid conflicts.
Instead of having these functions on a side interface like on
drm_api create a opaque winsys_handle that is to be passed down
into the winsys.
Currently the only thing ported to this new interface is drm_api,
and of that only the components that builds by default is ported.
All the drivers and any extra state trackers needs to be ported
before this can go into master.
We probably don't want to propagate this condition to the pipe driver,
this reverts commit f455ca6490 and the
dri_update_buffer flush altogether until an agreement is reached.
we actually need to specify the formats for different attachements, otherwise
if the color buffer is 24bpp and the app asks for 16bpp depth buffer than
we end up fetching the depth from the drawable which is 24bpp and end up
creating the wrong depth buffer. use the new getBuffersWithFormat extension
to pass the depth correctly.
This used to take GLX tokens, but the DRI interface can't depend on GLX
defines. We fix this by introducing DRI tokens that have the same value
as the GLX texture format tokens.
We use the presence of the getBuffersWithFormat extension function to
detect whether the server automatically adds a front.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
This should be the correct, but sub-optimal way to handle things on
pre-1.7 servers. For servers that automatically adds a fake front
we should never request the fake front and handle the reply differently.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
This reverts commit 1336989ec6.
The commit breaks frontbuffer rendering and the possibility to do
on-demand frontbuffer requests on all Xservers prior to 1.7.
The commit should be conditioned on a dri2 version check.
I've submitted a patch to Xserver to bump dri2 minor, and it's acked by Ian.
To be able to check the version from within the state tracker, we will
probably need another dri2 extension function that returns the server
version. The protocol has support for it.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
As part of the DRI driver interface rewrite I merged __DRIscreenPrivate
and __DRIscreen, and likewise for __DRIdrawablePrivate and
__DRIcontextPrivate. I left typedefs in place though, to avoid renaming
all the *Private use internal to the driver. That was probably a
mistake, and it turns out a one-line find+sed combo can do the mass
rename. Better late than never.