Hi Leo,
I have tested your patch with my mplayer and it gives error when I try to
increase the size of the window. It gives the following error:-
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadDrawable (invalid Pixmap or Window parameter)
X11 error: BadPixmap (invalid Pixmap parameter)
Also when I made the back buffer linear instead of the providing the
handle myself,
it was working fine in my system.
Regards,
Nayan
On Fri, Sep 2, 2016 at 8:51 PM, Leo Liu <leo....@amd.com
<mailto:leo....@amd.com>> wrote:
On 09/02/2016 10:48 AM, Christian König wrote:
Am 02.09.2016 um 16:10 schrieb Leo Liu:
On 09/02/2016 09:50 AM, Christian König wrote:
Am 02.09.2016 um 15:27 schrieb Leo Liu:
On 09/02/2016 02:11 AM, Christian König wrote:
Am 02.09.2016 um 04:03 schrieb Michel Dänzer:
On 02/09/16 10:17 AM, Michel Dänzer wrote:
On 02/09/16 12:58 AM, Leo Liu wrote:
On 09/01/2016 11:54 AM, Nayan Deshmukh wrote:
I saw the code in dri3_glx.c and I could somewhat relate
some basic
code structure to the vl_winsys_dri3.c. But I am new to
this and not aware of the
terminology that you used about the buffers. Could you
please explain what needs
to be done in more detail or point me to where I can read
about it.
I believe it's from loader_dri3_helper.c with
"is_different_gpu"
condition true, that will include back buffer and front
buffer case.
you could try only back buffer case for now.
From a high level, PRIME mainly affects presentation, not
so much the
video decoding / rendering. The important thing is that the
buffer used
for presentation via the Present extension is linear, not
tiled. I'm not
sure whether it makes more sense to allocate a separate
linear buffer
for this purpose, as is done for GLX, or for the vl code to
make the
corresponding back (or front?) buffer linear in the first
place.
A separate linear buffer is probably better, actually, since
it will
also be pinned to system memory while it's being shared with
another GPU.
Yes, I agree. Nayan should also work on avoiding the extra
copy which currently occur because we can't allocate output
buffers directly in the format needed for presentation.
The general idea should be to to check during presentation if
the format in the output surface is displayable directly.
Also we have to consider drawable resized case.
Actually we don't. Take a look at the VDPAU spec the output
surface should be send for displaying without considering it's
size.
E.g. when the window is 256x256 pixels, but the application
allocated an output surface of 1024x768 we should still send
the whole surface to the X server.
It's the job of the application to resize the output surfaces
not the one of the VDPAU state tracker.
I thought this get done by vl compositor from presentation,
scaling up or down from output surface to back buffer based on
the resize.
No, that is incorrect. Take a look at the VDPAU spec:
Applications may choose to allow resizing of the presentation
queue target (which may be e.g. a regular Window when using an
X11-based implementation).
*clip_width* and *clip_height* may be used to limit the size of
the displayed region of a surface, in order to match the
specific region that was rendered to.
In turn, this allows the application to allocate over-sized
(e.g. screen-sized) surfaces, but render to a region that
matches the current size of the video window.
Using this technique, an application's response to window
resizing may simply be to render to, and display, a different
region of the surface, rather than de-/re-allocation of surfaces
to match the updated window size.
This means that we should send the original output surface size
to X, no matter what size it has or what size the window has it
is displayed in.
That wasn't possible with DRI2, that's why we have that
workaround with the delayed rendering in the mixer.
I did a quick hack on single GPU, and tested, this proves the
whole idea is working including resizing.
Linear is still displayable, just looks kind of sluggish when
playback.
Here is the hack for reference including remove back buffer
creating, and presentation rendering, use output surface handle for X
diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
b/src/gallium/auxiliary/vl/vl_winsys.h
index 26db9f2..908ec3a 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -59,6 +59,9 @@ struct vl_screen
void *
(*get_private)(struct vl_screen *vscreen);
+ void *
+ (*set_output_handle)(struct vl_screen *vscreen, struct
winsys_handle whandle);
+
struct pipe_screen *pscreen;
struct pipe_loader_device *dev;
};
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 3d596a6..4908699 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -64,6 +64,9 @@ struct vl_dri3_screen
xcb_connection_t *conn;
xcb_drawable_t drawable;
+ unsigned output_handle;
+ unsigned output_stride;
+
uint32_t width, height, depth;
xcb_present_event_t eid;
@@ -225,6 +228,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen
*scrn)
if (!shm_fence)
goto close_fd;
+#if 0
memset(&templ, 0, sizeof(templ));
templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW |
PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
@@ -248,6 +252,11 @@ dri3_alloc_back_buffer(struct vl_dri3_screen
*scrn)
usage);
buffer_fd = whandle.handle;
buffer->pitch = whandle.stride;
+#endif
+
+ buffer_fd = scrn->output_handle;
+ buffer->pitch = scrn->output_stride;
+
xcb_dri3_pixmap_from_buffer(scrn->conn,
(pixmap = xcb_generate_id(scrn->conn)),
scrn->drawable,
@@ -591,6 +600,15 @@ vl_dri3_screen_get_private(struct vl_screen
*vscreen)
}
static void
+vl_dri3_set_output_handle(struct vl_screen *vscreen, struct
winsys_handle whandle)
+{
+ struct vl_dri3_screen *scrn = (struct vl_dri3_screen *)vscreen;
+
+ scrn->output_handle = whandle.handle;
+ scrn->output_stride = whandle.stride;
+}
+
+static void
vl_dri3_screen_destroy(struct vl_screen *vscreen)
{
struct vl_dri3_screen *scrn = (struct vl_dri3_screen *)vscreen;
@@ -706,6 +724,7 @@ vl_dri3_screen_create(Display *display, int
screen)
scrn->base.set_next_timestamp = vl_dri3_screen_set_next_timestamp;
scrn->base.get_private = vl_dri3_screen_get_private;
scrn->base.pscreen->flush_frontbuffer = vl_dri3_flush_frontbuffer;
+ scrn->base.set_output_handle = vl_dri3_set_output_handle;
return &scrn->base;
diff --git a/src/gallium/state_trackers/vdpau/presentation.c
b/src/gallium/state_trackers/vdpau/presentation.c
index 2862eaf..d5e832e 100644
--- a/src/gallium/state_trackers/vdpau/presentation.c
+++ b/src/gallium/state_trackers/vdpau/presentation.c
@@ -30,6 +30,11 @@
#include "util/u_debug.h"
#include "util/u_memory.h"
+#include "util/u_sampler.h"
+#include "util/u_format.h"
+#include "util/u_surface.h"
+
+#include "state_tracker/drm_driver.h"
#include "vdpau_private.h"
@@ -216,6 +221,7 @@
vlVdpPresentationQueueDisplay(VdpPresentationQueue presentation_queue,
struct vl_compositor *compositor;
struct vl_compositor_state *cstate;
struct vl_screen *vscreen;
+ struct winsys_handle whandle;
pq = vlGetDataHTAB(presentation_queue);
if (!pq)
@@ -231,14 +237,26 @@
vlVdpPresentationQueueDisplay(VdpPresentationQueue presentation_queue,
vscreen = pq->device->vscreen;
pipe_mutex_lock(pq->device->mutex);
+
+ memset(&whandle, 0, sizeof(struct winsys_handle));
+ whandle.type = DRM_API_HANDLE_TYPE_FD;
+
+ if (!vscreen->pscreen->resource_get_handle(vscreen->pscreen,
surf->device->context,
+ surf->surface->texture, &whandle,
+ PIPE_HANDLE_USAGE_READ_WRITE))
+ return VDP_STATUS_NO_IMPLEMENTATION;
+
+ vscreen->set_output_handle(vscreen, whandle);
+
tex = vscreen->texture_from_drawable(vscreen, (void
*)pq->drawable);
- if (!tex) {
- pipe_mutex_unlock(pq->device->mutex);
- return VDP_STATUS_INVALID_HANDLE;
- }
+// if (!tex) {
+// pipe_mutex_unlock(pq->device->mutex);
+// return VDP_STATUS_INVALID_HANDLE;
+// }
dirty_area = vscreen->get_dirty_area(vscreen);
+#if 0
memset(&surf_templ, 0, sizeof(surf_templ));
surf_templ.format = tex->format;
surf_draw = pipe->create_surface(pipe, tex, &surf_templ);
@@ -269,6 +287,7 @@
vlVdpPresentationQueueDisplay(VdpPresentationQueue presentation_queue,
vl_compositor_set_dst_clip(cstate, &dst_clip);
vl_compositor_render(cstate, compositor, surf_draw,
dirty_area, true);
}
+#endif
vscreen->set_next_timestamp(vscreen, earliest_presentation_time);
pipe->screen->flush_frontbuffer(pipe->screen, tex, 0, 0,
@@ -294,8 +313,10 @@
vlVdpPresentationQueueDisplay(VdpPresentationQueue presentation_queue,
framenum++;
}
+#if 0
pipe_resource_reference(&tex, NULL);
pipe_surface_reference(&surf_draw, NULL);
+#endif
pipe_mutex_unlock(pq->device->mutex);
return VDP_STATUS_OK;
Regards,
Leo
But no worry it's only a minor issue and a good task for Nayan to
get deeper into the graphics stack.
Regards,
Christian.
Regards,
Leo
Regards,
Christian.
Regards,
Leo
If that is the case then handle of that surface should be
send directly to X.
If that isn't the case we reallocate the backing buffer, copy
the content of the output surface into it and then send the
new handle to X.
Regards,
Christian.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
<mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
<https://lists.freedesktop.org/mailman/listinfo/mesa-dev>
