[Mesa-dev] [Bug 72895] Missing trees in flightgear 2.12.1 with r600 driver and mesa 10.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=72895 --- Comment #7 from Barto --- does anyone need more informations about this bug ? because this bug is still here with the new mesa 10.0.2, I did a bisect, the bug begins with 59b01ca252bd6706f08cd80a864819d71dfe741c commit, I can do another test but I need some help because I'm not a specialist in 3D programming -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2
Yeah, probably because XBMC still (incorrectly) calls the map function only once. Putting the flush into vlVdpResolveDelayedRendering solves the problem because it's called the next time somebody starts rendering, but it's way to late at this point. Need to sync up with the XBMC devs on this. Christian. Am 13.01.2014 15:20, schrieb Marek Olšák: This patch doesn't fix the bug. :( Marek On Mon, Jan 13, 2014 at 2:55 PM, Christian König wrote: From: Marek Olšák Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73191 When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which always flushes the context in the winsys if the buffer being mapped is busy. Since I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when combined with DISCARD_RANGE and I think the context isn't flushed anywhere else, so no commands are submitted to the GPU until the IB is full, which takes a lot of frames. Using DISCARD_RANGE is not the only way to trigger this bug. The other way is to reallocate the vertex buffer before every upload. BTW, I'm not sure if this is the right place for flushing, but it does fix the bug. v2 (chk): move the flush to the right place. Signed-off-by: Christian König --- src/gallium/state_trackers/vdpau/output.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/state_trackers/vdpau/output.c b/src/gallium/state_trackers/vdpau/output.c index e4e1433..7ff4196 100644 --- a/src/gallium/state_trackers/vdpau/output.c +++ b/src/gallium/state_trackers/vdpau/output.c @@ -736,6 +736,7 @@ struct pipe_resource *vlVdpOutputSurfaceGallium(VdpOutputSurface surface) pipe_mutex_lock(vlsurface->device->mutex); vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL); + vlsurface->device->context->flush(vlsurface->device->context, NULL, 0); pipe_mutex_unlock(vlsurface->device->mutex); return vlsurface->surface->texture; -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/egl: Flush resources before presentation
Pushed.
Marek
On Tue, Jan 7, 2014 at 11:20 PM, Martin Andersson wrote:
> Hi Marek,
>
> Since it seems no one else have any comments on this, maybe you could
> commit it for me?
>
> //Martin
>
> On Thu, Dec 26, 2013 at 1:15 PM, Marek Olšák wrote:
>> Reviewed-by: Marek Olšák
>>
>> Marek
>>
>> On Thu, Dec 26, 2013 at 10:33 AM, Martin Andersson
>> wrote:
>>> Fixes wayland regression on r600g due to fast clear introduced by commit
>>> edbbfac6.
>>> ---
>>> src/gallium/state_trackers/egl/common/native_helper.c | 15
>>> +++
>>> src/gallium/state_trackers/egl/common/native_helper.h | 5 +
>>> src/gallium/state_trackers/egl/wayland/native_wayland.c | 4
>>> 3 files changed, 24 insertions(+)
>>>
>>> diff --git a/src/gallium/state_trackers/egl/common/native_helper.c
>>> b/src/gallium/state_trackers/egl/common/native_helper.c
>>> index 4a77a50..856cbb6 100644
>>> --- a/src/gallium/state_trackers/egl/common/native_helper.c
>>> +++ b/src/gallium/state_trackers/egl/common/native_helper.c
>>> @@ -341,6 +341,21 @@ resource_surface_throttle(struct resource_surface
>>> *rsurf)
>>> }
>>>
>>> boolean
>>> +resource_surface_flush_resource(struct resource_surface *rsurf,
>>> +struct native_display *ndpy,
>>> +enum native_attachment which)
>>> +{
>>> + struct pipe_context *pipe = ndpy_get_copy_context(ndpy);
>>> +
>>> + if (!pipe)
>>> + return FALSE;
>>> +
>>> + pipe->flush_resource(pipe, rsurf->resources[which]);
>>> +
>>> + return TRUE;
>>> +}
>>> +
>>> +boolean
>>> resource_surface_flush(struct resource_surface *rsurf,
>>>struct native_display *ndpy)
>>> {
>>> diff --git a/src/gallium/state_trackers/egl/common/native_helper.h
>>> b/src/gallium/state_trackers/egl/common/native_helper.h
>>> index 4c369a7..0b53b28 100644
>>> --- a/src/gallium/state_trackers/egl/common/native_helper.h
>>> +++ b/src/gallium/state_trackers/egl/common/native_helper.h
>>> @@ -91,6 +91,11 @@ resource_surface_copy_swap(struct resource_surface
>>> *rsurf,
>>> boolean
>>> resource_surface_throttle(struct resource_surface *rsurf);
>>>
>>> +boolean
>>> +resource_surface_flush_resource(struct resource_surface *rsurf,
>>> +struct native_display *ndpy,
>>> +enum native_attachment which);
>>> +
>>> /**
>>> * Flush pending rendering using the copy context. This function saves a
>>> * marker for upcoming throttles.
>>> diff --git a/src/gallium/state_trackers/egl/wayland/native_wayland.c
>>> b/src/gallium/state_trackers/egl/wayland/native_wayland.c
>>> index cfdf4f8..0ab4be6 100644
>>> --- a/src/gallium/state_trackers/egl/wayland/native_wayland.c
>>> +++ b/src/gallium/state_trackers/egl/wayland/native_wayland.c
>>> @@ -259,6 +259,10 @@ wayland_surface_swap_buffers(struct native_surface
>>> *nsurf)
>>> if (ret == -1)
>>>return EGL_FALSE;
>>>
>>> + (void) resource_surface_flush_resource(surface->rsurf, &display->base,
>>> + NATIVE_ATTACHMENT_BACK_LEFT);
>>> + (void) resource_surface_flush(surface->rsurf, &display->base);
>>> +
>>> surface->frame_callback = wl_surface_frame(surface->win->surface);
>>> wl_callback_add_listener(surface->frame_callback, &frame_listener,
>>> surface);
>>> wl_proxy_set_queue((struct wl_proxy *) surface->frame_callback,
>>> --
>>> 1.8.5.1
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2
This patch doesn't fix the bug. :( Marek On Mon, Jan 13, 2014 at 2:55 PM, Christian König wrote: > From: Marek Olšák > > Bugzilla: > https://bugs.freedesktop.org/show_bug.cgi?id=73191 > > When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which always > flushes the context in the winsys if the buffer being mapped is busy. Since > I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when combined > with DISCARD_RANGE and I think the context isn't flushed anywhere else, > so no commands are submitted to the GPU until the IB is full, which takes > a lot of frames. > > Using DISCARD_RANGE is not the only way to trigger this bug. The other way > is to reallocate the vertex buffer before every upload. > > BTW, I'm not sure if this is the right place for flushing, but it does fix > the bug. > > v2 (chk): move the flush to the right place. > > Signed-off-by: Christian König > --- > src/gallium/state_trackers/vdpau/output.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gallium/state_trackers/vdpau/output.c > b/src/gallium/state_trackers/vdpau/output.c > index e4e1433..7ff4196 100644 > --- a/src/gallium/state_trackers/vdpau/output.c > +++ b/src/gallium/state_trackers/vdpau/output.c > @@ -736,6 +736,7 @@ struct pipe_resource > *vlVdpOutputSurfaceGallium(VdpOutputSurface surface) > > pipe_mutex_lock(vlsurface->device->mutex); > vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL); > + vlsurface->device->context->flush(vlsurface->device->context, NULL, 0); > pipe_mutex_unlock(vlsurface->device->mutex); > > return vlsurface->surface->texture; > -- > 1.8.1.2 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Mark debug_print with __attribute__ ((format(__printf__, 1, 0)))
Thierry Reding writes: > While at it, perhaps the drmMsg() and drmDebugPrint() functions should > be similarily annotated as well? I don't know; I'm just fixing X server warnings this week and this was the source of one of them. Additional warning fixes for drm would be a great idea! -- keith.pack...@intel.com pgp2Mp9hDDHGU.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vdpau: flush the context before exporting the surface v2
From: Marek Olšák Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73191 When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which always flushes the context in the winsys if the buffer being mapped is busy. Since I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when combined with DISCARD_RANGE and I think the context isn't flushed anywhere else, so no commands are submitted to the GPU until the IB is full, which takes a lot of frames. Using DISCARD_RANGE is not the only way to trigger this bug. The other way is to reallocate the vertex buffer before every upload. BTW, I'm not sure if this is the right place for flushing, but it does fix the bug. v2 (chk): move the flush to the right place. Signed-off-by: Christian König --- src/gallium/state_trackers/vdpau/output.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/state_trackers/vdpau/output.c b/src/gallium/state_trackers/vdpau/output.c index e4e1433..7ff4196 100644 --- a/src/gallium/state_trackers/vdpau/output.c +++ b/src/gallium/state_trackers/vdpau/output.c @@ -736,6 +736,7 @@ struct pipe_resource *vlVdpOutputSurfaceGallium(VdpOutputSurface surface) pipe_mutex_lock(vlsurface->device->mutex); vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL); + vlsurface->device->context->flush(vlsurface->device->context, NULL, 0); pipe_mutex_unlock(vlsurface->device->mutex); return vlsurface->surface->texture; -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa-demos: Fixes a bug in demo2 application
From: Yasir-Khan Vertices array is being passed to glColorPointer whereas its supposed to pass the color array Signed-off-by: Yasir-Khan diff --git a/src/egl/opengl/demo2.c b/src/egl/opengl/demo2.c index 71a1a31..505b474 100644 --- a/src/egl/opengl/demo2.c +++ b/src/egl/opengl/demo2.c @@ -35,7 +35,7 @@ static void _subset_Rectf(GLfloat x1, GLfloat y1, GLfloat x2, GLfloat y2, } glVertexPointer(2, GL_FLOAT, 0, v); - glColorPointer(4, GL_FLOAT, 0, v); + glColorPointer(4, GL_FLOAT, 0, c); glEnableClientState(GL_VERTEX_ARRAY); glEnableClientState(GL_COLOR_ARRAY); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] gallium/vl: use u_upload_mgr to upload vertices for vl_compositor
Am 13.01.2014 14:13, schrieb Marek Olšák:
From: Marek Olšák
This patch is: Reviewed-by: Christian König
This is the recommended way for streaming vertices. Always use this if you
need to upload vertices every frame.
---
src/gallium/auxiliary/vl/vl_compositor.c | 51
src/gallium/auxiliary/vl/vl_compositor.h | 1 +
2 files changed, 20 insertions(+), 32 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c
b/src/gallium/auxiliary/vl/vl_compositor.c
index 1c8312e..0c8b424 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -33,6 +33,7 @@
#include "util/u_memory.h"
#include "util/u_draw.h"
#include "util/u_surface.h"
+#include "util/u_upload_mgr.h"
#include "tgsi/tgsi_ureg.h"
@@ -498,23 +499,6 @@ static void cleanup_pipe_state(struct vl_compositor *c)
}
static bool
-create_vertex_buffer(struct vl_compositor *c)
-{
- assert(c);
-
- pipe_resource_reference(&c->vertex_buf.buffer, NULL);
- c->vertex_buf.buffer = pipe_buffer_create
- (
- c->pipe->screen,
- PIPE_BIND_VERTEX_BUFFER,
- PIPE_USAGE_STREAM,
- c->vertex_buf.stride * VL_COMPOSITOR_MAX_LAYERS * 4
- );
-
- return c->vertex_buf.buffer != NULL;
-}
-
-static bool
init_buffers(struct vl_compositor *c)
{
struct pipe_vertex_element vertex_elems[3];
@@ -526,7 +510,7 @@ init_buffers(struct vl_compositor *c)
*/
c->vertex_buf.stride = sizeof(struct vertex2f) + sizeof(struct vertex4f) *
2;
c->vertex_buf.buffer_offset = 0;
- create_vertex_buffer(c);
+ c->vertex_buf.buffer = NULL;
vertex_elems[0].src_offset = 0;
vertex_elems[0].instance_divisor = 0;
@@ -659,22 +643,15 @@ static void
gen_vertex_data(struct vl_compositor *c, struct vl_compositor_state *s,
struct u_rect *dirty)
{
struct vertex2f *vb;
- struct pipe_transfer *buf_transfer;
unsigned i;
assert(c);
- vb = pipe_buffer_map(c->pipe, c->vertex_buf.buffer,
-PIPE_TRANSFER_WRITE | PIPE_TRANSFER_DISCARD_RANGE |
PIPE_TRANSFER_DONTBLOCK,
-&buf_transfer);
-
- if (!vb) {
- // If buffer is still locked from last draw create a new one
- create_vertex_buffer(c);
- vb = pipe_buffer_map(c->pipe, c->vertex_buf.buffer,
- PIPE_TRANSFER_WRITE | PIPE_TRANSFER_DISCARD_RANGE,
- &buf_transfer);
- }
+ /* Allocate new memory for vertices. */
+ u_upload_alloc(c->upload, 0,
+ c->vertex_buf.stride * VL_COMPOSITOR_MAX_LAYERS * 4, /* size
*/
+ &c->vertex_buf.buffer_offset, &c->vertex_buf.buffer,
+ (void**)&vb);
for (i = 0; i < VL_COMPOSITOR_MAX_LAYERS; i++) {
if (s->used_layers & (1 << i)) {
@@ -705,7 +682,7 @@ gen_vertex_data(struct vl_compositor *c, struct
vl_compositor_state *s, struct u
}
}
- pipe_buffer_unmap(c->pipe, buf_transfer);
+ u_upload_unmap(c->upload);
}
static void
@@ -802,6 +779,7 @@ vl_compositor_cleanup(struct vl_compositor *c)
{
assert(c);
+ u_upload_destroy(c->upload);
cleanup_buffers(c);
cleanup_shaders(c);
cleanup_pipe_state(c);
@@ -1037,15 +1015,24 @@ vl_compositor_init(struct vl_compositor *c, struct
pipe_context *pipe)
c->pipe = pipe;
- if (!init_pipe_state(c))
+ c->upload = u_upload_create(pipe, 128 * 1024, 4, PIPE_BIND_VERTEX_BUFFER);
+
+ if (!c->upload)
+ return false;
+
+ if (!init_pipe_state(c)) {
+ u_upload_destroy(c->upload);
return false;
+ }
if (!init_shaders(c)) {
+ u_upload_destroy(c->upload);
cleanup_pipe_state(c);
return false;
}
if (!init_buffers(c)) {
+ u_upload_destroy(c->upload);
cleanup_shaders(c);
cleanup_pipe_state(c);
return false;
diff --git a/src/gallium/auxiliary/vl/vl_compositor.h
b/src/gallium/auxiliary/vl/vl_compositor.h
index 8e01901..6a60138 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.h
+++ b/src/gallium/auxiliary/vl/vl_compositor.h
@@ -89,6 +89,7 @@ struct vl_compositor_state
struct vl_compositor
{
struct pipe_context *pipe;
+ struct u_upload_mgr *upload;
struct pipe_framebuffer_state fb_state;
struct pipe_vertex_buffer vertex_buf;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: Add missing null check in glXCreateContextAttribsARB
Signed-off-by: Juha-Pekka Heikkila --- src/glx/create_context.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/glx/create_context.c b/src/glx/create_context.c index 38e949a..b15921f 100644 --- a/src/glx/create_context.c +++ b/src/glx/create_context.c @@ -90,6 +90,9 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig config, #endif } + if (gc == NULL) + return NULL; + gc->xid = xcb_generate_id(c); gc->share_xid = (share != NULL) ? share->xid : 0; -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] gallium/u_upload_mgr: don't expose u_upload_flush
From: Marek Olšák
It's unused and shouldn't be used at all in my opinion.
If some driver doesn't support the unsynchronized flag, u_upload_mgr should
avoid the synchronization by other means, e.g. by using the DONTBLOCK flag.
---
src/gallium/auxiliary/util/u_upload_mgr.c | 16
src/gallium/auxiliary/util/u_upload_mgr.h | 10 --
2 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c
b/src/gallium/auxiliary/util/u_upload_mgr.c
index 6859751..7349d00 100644
--- a/src/gallium/auxiliary/util/u_upload_mgr.c
+++ b/src/gallium/auxiliary/util/u_upload_mgr.c
@@ -87,16 +87,8 @@ void u_upload_unmap( struct u_upload_mgr *upload )
}
}
-/* Release old buffer.
- *
- * This must usually be called prior to firing the command stream
- * which references the upload buffer, as many memory managers will
- * cause subsequent maps of a fired buffer to wait.
- *
- * Can improve this with a change to pipe_buffer_write to use the
- * DONT_WAIT bit, but for now, it's easiest just to grab a new buffer.
- */
-void u_upload_flush( struct u_upload_mgr *upload )
+
+static void u_upload_release_buffer(struct u_upload_mgr *upload)
{
/* Unmap and unreference the upload buffer. */
u_upload_unmap(upload);
@@ -107,7 +99,7 @@ void u_upload_flush( struct u_upload_mgr *upload )
void u_upload_destroy( struct u_upload_mgr *upload )
{
- u_upload_flush( upload );
+ u_upload_release_buffer( upload );
FREE( upload );
}
@@ -120,7 +112,7 @@ u_upload_alloc_buffer( struct u_upload_mgr *upload,
/* Release the old buffer, if present:
*/
- u_upload_flush( upload );
+ u_upload_release_buffer( upload );
/* Allocate a new one:
*/
diff --git a/src/gallium/auxiliary/util/u_upload_mgr.h
b/src/gallium/auxiliary/util/u_upload_mgr.h
index 82215a5..63bf30e 100644
--- a/src/gallium/auxiliary/util/u_upload_mgr.h
+++ b/src/gallium/auxiliary/util/u_upload_mgr.h
@@ -57,16 +57,6 @@ struct u_upload_mgr *u_upload_create( struct pipe_context
*pipe,
void u_upload_destroy( struct u_upload_mgr *upload );
/**
- * Unmap and release old upload buffer.
- *
- * This is like u_upload_unmap() except the upload buffer is released for
- * recycling. This should be called on real hardware flushes on systems
- * that don't support the PIPE_TRANSFER_UNSYNCHRONIZED flag, as otherwise
- * the next u_upload_buffer will cause a sync on the buffer.
- */
-void u_upload_flush( struct u_upload_mgr *upload );
-
-/**
* Unmap upload buffer
*
* \param upload Upload manager
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] gallium/vl: use u_upload_mgr to upload vertices for vl_compositor
From: Marek Olšák
This is the recommended way for streaming vertices. Always use this if you
need to upload vertices every frame.
---
src/gallium/auxiliary/vl/vl_compositor.c | 51
src/gallium/auxiliary/vl/vl_compositor.h | 1 +
2 files changed, 20 insertions(+), 32 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c
b/src/gallium/auxiliary/vl/vl_compositor.c
index 1c8312e..0c8b424 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -33,6 +33,7 @@
#include "util/u_memory.h"
#include "util/u_draw.h"
#include "util/u_surface.h"
+#include "util/u_upload_mgr.h"
#include "tgsi/tgsi_ureg.h"
@@ -498,23 +499,6 @@ static void cleanup_pipe_state(struct vl_compositor *c)
}
static bool
-create_vertex_buffer(struct vl_compositor *c)
-{
- assert(c);
-
- pipe_resource_reference(&c->vertex_buf.buffer, NULL);
- c->vertex_buf.buffer = pipe_buffer_create
- (
- c->pipe->screen,
- PIPE_BIND_VERTEX_BUFFER,
- PIPE_USAGE_STREAM,
- c->vertex_buf.stride * VL_COMPOSITOR_MAX_LAYERS * 4
- );
-
- return c->vertex_buf.buffer != NULL;
-}
-
-static bool
init_buffers(struct vl_compositor *c)
{
struct pipe_vertex_element vertex_elems[3];
@@ -526,7 +510,7 @@ init_buffers(struct vl_compositor *c)
*/
c->vertex_buf.stride = sizeof(struct vertex2f) + sizeof(struct vertex4f) *
2;
c->vertex_buf.buffer_offset = 0;
- create_vertex_buffer(c);
+ c->vertex_buf.buffer = NULL;
vertex_elems[0].src_offset = 0;
vertex_elems[0].instance_divisor = 0;
@@ -659,22 +643,15 @@ static void
gen_vertex_data(struct vl_compositor *c, struct vl_compositor_state *s, struct
u_rect *dirty)
{
struct vertex2f *vb;
- struct pipe_transfer *buf_transfer;
unsigned i;
assert(c);
- vb = pipe_buffer_map(c->pipe, c->vertex_buf.buffer,
-PIPE_TRANSFER_WRITE | PIPE_TRANSFER_DISCARD_RANGE |
PIPE_TRANSFER_DONTBLOCK,
-&buf_transfer);
-
- if (!vb) {
- // If buffer is still locked from last draw create a new one
- create_vertex_buffer(c);
- vb = pipe_buffer_map(c->pipe, c->vertex_buf.buffer,
- PIPE_TRANSFER_WRITE | PIPE_TRANSFER_DISCARD_RANGE,
- &buf_transfer);
- }
+ /* Allocate new memory for vertices. */
+ u_upload_alloc(c->upload, 0,
+ c->vertex_buf.stride * VL_COMPOSITOR_MAX_LAYERS * 4, /* size
*/
+ &c->vertex_buf.buffer_offset, &c->vertex_buf.buffer,
+ (void**)&vb);
for (i = 0; i < VL_COMPOSITOR_MAX_LAYERS; i++) {
if (s->used_layers & (1 << i)) {
@@ -705,7 +682,7 @@ gen_vertex_data(struct vl_compositor *c, struct
vl_compositor_state *s, struct u
}
}
- pipe_buffer_unmap(c->pipe, buf_transfer);
+ u_upload_unmap(c->upload);
}
static void
@@ -802,6 +779,7 @@ vl_compositor_cleanup(struct vl_compositor *c)
{
assert(c);
+ u_upload_destroy(c->upload);
cleanup_buffers(c);
cleanup_shaders(c);
cleanup_pipe_state(c);
@@ -1037,15 +1015,24 @@ vl_compositor_init(struct vl_compositor *c, struct
pipe_context *pipe)
c->pipe = pipe;
- if (!init_pipe_state(c))
+ c->upload = u_upload_create(pipe, 128 * 1024, 4, PIPE_BIND_VERTEX_BUFFER);
+
+ if (!c->upload)
+ return false;
+
+ if (!init_pipe_state(c)) {
+ u_upload_destroy(c->upload);
return false;
+ }
if (!init_shaders(c)) {
+ u_upload_destroy(c->upload);
cleanup_pipe_state(c);
return false;
}
if (!init_buffers(c)) {
+ u_upload_destroy(c->upload);
cleanup_shaders(c);
cleanup_pipe_state(c);
return false;
diff --git a/src/gallium/auxiliary/vl/vl_compositor.h
b/src/gallium/auxiliary/vl/vl_compositor.h
index 8e01901..6a60138 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.h
+++ b/src/gallium/auxiliary/vl/vl_compositor.h
@@ -89,6 +89,7 @@ struct vl_compositor_state
struct vl_compositor
{
struct pipe_context *pipe;
+ struct u_upload_mgr *upload;
struct pipe_framebuffer_state fb_state;
struct pipe_vertex_buffer vertex_buf;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] gallium/hud: just unmap the upload vertex buffer instead of recreating it
From: Marek Olšák --- src/gallium/auxiliary/hud/hud_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/hud/hud_context.c b/src/gallium/auxiliary/hud/hud_context.c index c4a4f18..465013c 100644 --- a/src/gallium/auxiliary/hud/hud_context.c +++ b/src/gallium/auxiliary/hud/hud_context.c @@ -479,7 +479,7 @@ hud_draw(struct hud_context *hud, struct pipe_resource *tex) } /* unmap the uploader's vertex buffer before drawing */ - u_upload_flush(hud->uploader); + u_upload_unmap(hud->uploader); /* draw accumulated vertices for background quads */ cso_set_fragment_shader_handle(hud->cso, hud->fs_color); -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] radeonsi: handle R600_CONTEXT_PS_PARTIAL_FLUSH in si_emit_cache_flush
From: Marek Olšák
For consistency only, This unused by radeonsi currently.
---
src/gallium/drivers/radeonsi/si_state_draw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index f64b51a..9092fb1 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -680,7 +680,8 @@ void si_emit_cache_flush(struct r600_common_context *rctx,
struct r600_atom *ato
radeon_emit(cs, EVENT_TYPE(V_028A90_FLUSH_AND_INV_DB_META) |
EVENT_INDEX(0));
}
- if (rctx->flags & R600_CONTEXT_WAIT_3D_IDLE) {
+ if (rctx->flags & (R600_CONTEXT_WAIT_3D_IDLE |
+ R600_CONTEXT_PS_PARTIAL_FLUSH)) {
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cs, EVENT_TYPE(V_028A90_PS_PARTIAL_FLUSH) |
EVENT_INDEX(4));
} else if (rctx->flags & R600_CONTEXT_STREAMOUT_FLUSH) {
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] vdpau: flush the context after resolving delayed rendering
From: Marek Olšák
Bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=73191
When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which always
flushes the context in the winsys if the buffer being mapped is busy. Since
I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when combined
with DISCARD_RANGE and I think the context isn't flushed anywhere else,
so no commands are submitted to the GPU until the IB is full, which takes
a lot of frames.
Using DISCARD_RANGE is not the only way to trigger this bug. The other way
is to reallocate the vertex buffer before every upload.
BTW, I'm not sure if this is the right place for flushing, but it does fix
the bug.
---
src/gallium/state_trackers/vdpau/device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index fb9c68c..4fd6041 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -266,6 +266,7 @@ vlVdpResolveDelayedRendering(vlVdpDevice *dev, struct
pipe_surface *surface, str
{
struct vl_compositor_state *cstate;
vlVdpOutputSurface *vlsurface;
+ struct pipe_context *pipe = dev->context;
assert(dev);
@@ -283,6 +284,7 @@ vlVdpResolveDelayedRendering(vlVdpDevice *dev, struct
pipe_surface *surface, str
}
vl_compositor_render(cstate, &dev->compositor, surface, dirty_area, true);
+ pipe->flush(pipe, NULL, 0);
dev->delayed_rendering.surface = VDP_INVALID_HANDLE;
dev->delayed_rendering.cstate = NULL;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] r600g, radeonsi: if discarding the whole buffer range, discard the whole resource instead
From: Marek Olšák
Also set the unsynchronized flag if the whole resource was discarded
to avoid doing buffer-busy checks again.
---
src/gallium/drivers/radeon/r600_buffer_common.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index ac5fbcc..66e9d57 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -205,6 +205,12 @@ static void *r600_buffer_transfer_map(struct pipe_context
*ctx,
usage |= PIPE_TRANSFER_UNSYNCHRONIZED;
}
+ /* If discarding the entire range, discard the whole resource instead.
*/
+ if (usage & PIPE_TRANSFER_DISCARD_RANGE &&
+ box->x == 0 && box->width == resource->width0) {
+ usage |= PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE;
+ }
+
if (usage & PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE &&
!(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
assert(usage & PIPE_TRANSFER_WRITE);
@@ -214,6 +220,8 @@ static void *r600_buffer_transfer_map(struct pipe_context
*ctx,
rctx->ws->buffer_is_busy(rbuffer->buf,
RADEON_USAGE_READWRITE)) {
rctx->invalidate_buffer(&rctx->b, &rbuffer->b.b);
}
+ /* At this point, the buffer is always idle. */
+ usage |= PIPE_TRANSFER_UNSYNCHRONIZED;
}
else if ((usage & PIPE_TRANSFER_DISCARD_RANGE) &&
!(usage & PIPE_TRANSFER_UNSYNCHRONIZED) &&
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naming everything in src/gallium/drivers/radeonsi si_*
For the series: Reviewed-by: Marek Olšák Feel free to push this. Marek On Sat, Jan 11, 2014 at 4:20 PM, Andreas Hartmetz wrote: > Continuing here because the threads had diverged... > > I've updated the patch series under the same URL and applied all the > suggested improvements. The variable renames are still in, but at the > very end so they are trivial to omit. > > On Tuesday 07 January 2014 17:27:56 Andreas Hartmetz wrote: >> We have talked on IRC meanwhile: >> "Everywhere" was supposed to mean file names and data structures. >> >> I have made a patch series (git link because file renames produce huge >> diffs) that renames *everything* away from r600 (and also radeonsi) >> to si, where it is actually about SI. In the such modified code it is >> then clear at first glance that only resources, textures and some >> other low-level interface code from R600 / generic Radeon are actually >> used in SI code. >> >> The patch series is ordered by increasing controversy potential due >> to destruction of git blame history, so the last parts can be omitted >> if they are deemed too destructive to history. In my opinion, it is >> better to have code that is readable now than code that is less >> readable but with the possibility to look up how it became like that. >> >> Michel said on IRC that he'd prefer to keep the name radeonsi_pipe.h/c, >> I disagree: If the library name is to be kept, there must be a break >> between radeonsi and si *somewhere*, and it is normal for library names >> to not correspond to any file name in the library. The same scheme is >> used in llvmpipe, llvmpipe lib / directory versus lp_* file names. >> >> Here's the repository (branch is master): >> git git://anongit.kde.org/scratch/ahartmetz/mesa.git >> web http://quickgit.kde.org/?p=scratch%2Fahartmetz%2Fmesa.git >> >> On Monday 06 January 2014 15:50:05 Marek Olšák wrote: >> > It sounds good, but I'd like the prefix to be si_ everywhere. >> > >> > Marek >> > >> > On Mon, Jan 6, 2014 at 2:47 PM, Andreas Hartmetz >> >> wrote: >> > > Hello, >> > > >> > > many of the files in radeonsi originally came from other places where >> > > they had different names and were never renamed. >> > > Most of them now have names that don't tell what the files are for >> > > (r600 is not actually the first hardware supported by them, they start >> > > at radeonsi), and even those with radeonsi are split between >> > > radeonsi_ and si_. >> > > si_ is shorter than radeonsi_, but inconsistent with the directory and >> > > library name. I still think it's the best option, but no strong opinion >> > > from me. If and when the files are renamed, the next step would be >> > > doing the same with the r600_ struct and function names. >> > > Does that sound good? I'll send the patches shortly if so. >> > > >> > > Cheers, >> > > Andreas >> > > ___ >> > > mesa-dev mailing list >> > > mesa-dev@lists.freedesktop.org >> > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Mark debug_print with __attribute__ ((format(__printf__, 1, 0)))
On Sun, Jan 12, 2014 at 10:34:19AM -0800, Keith Packard wrote:
> the drmServerInfo member, debug_print, takes a printf format string
> and varargs list. Tell the compiler about it.
>
> Signed-off-by: Keith Packard
> ---
> xf86drm.h | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/xf86drm.h b/xf86drm.h
> index 1e763a3..5e170f8 100644
> --- a/xf86drm.h
> +++ b/xf86drm.h
> @@ -92,8 +92,14 @@ extern "C" {
> typedef unsigned int drmSize, *drmSizePtr; /**< For mapped
> regions */
> typedef void *drmAddress, **drmAddressPtr; /**< For mapped regions
> */
>
> +#if (__GNUC__ >= 3)
> +#define DRM_PRINTFLIKE(f, a) __attribute__ ((format(__printf__, f, a)))
> +#else
> +#define DRM_PRINTFLIKE(f, a)
> +#endif
> +
> typedef struct _drmServerInfo {
> - int (*debug_print)(const char *format, va_list ap);
> + int (*debug_print)(const char *format, va_list ap) DRM_PRINTFLIKE(1,0);
>int (*load_module)(const char *name);
>void (*get_perms)(gid_t *, mode_t *);
> } drmServerInfo, *drmServerInfoPtr;
While at it, perhaps the drmMsg() and drmDebugPrint() functions should
be similarily annotated as well?
Thierry
pgpizPDWnAMD5.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: use signed temporary variable to store _ColorDrawBufferIndexes
Reviewed-by: Marek Olšák
Marek
On Sun, Jan 12, 2014 at 11:52 PM, Emil Velikov wrote:
> _ColorDrawBufferIndexes is defined as GLint* and using a GLuint*
> will result in the first part of the conditional to be evaluated to
> true always.
>
> Unintentionally introduced by the following commit, this will result
> in a driver segfault if one is using an old version of the piglit test
>
> bin/clearbuffer-mixed-format -auto -fbo
>
> commit 03d848ea1003abefd8fe51a5b4a780527cd852af
> Author: Marek Olšák
> Date: Wed Dec 4 00:27:20 2013 +0100
>
> mesa: fix interpretation of glClearBuffer(drawbuffer)
>
> This corresponding piglit tests supported this incorrect behavior instead
> of
> pointing at it.
>
> Cc: Marek Olšák
> Cc: 10.0 9.2 9.1
> Signed-off-by: Emil Velikov
> ---
> src/mesa/main/clear.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
> index f0b525f..d568ed8 100644
> --- a/src/mesa/main/clear.c
> +++ b/src/mesa/main/clear.c
> @@ -274,7 +274,7 @@ make_color_buffer_mask(struct gl_context *ctx, GLint
> drawbuffer)
>break;
> default:
>{
> - GLuint buf = ctx->DrawBuffer->_ColorDrawBufferIndexes[drawbuffer];
> + GLint buf = ctx->DrawBuffer->_ColorDrawBufferIndexes[drawbuffer];
>
> if (buf >= 0 && att[buf].Renderbuffer) {
> mask |= 1 << buf;
> --
> 1.8.5.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
