Re: [Mesa-dev] [RFC 3/3] mesa: call DrawBuffer(s) driver hook in update_framebuffer for windows-system FB

2018-04-15 Thread Dieter Nützel

For the series

Tested-by: Dieter Nützel 

on RX 580

with glmark2, UH, UV, Blender 2.79, FreeCAD, some Wine games,
KDE Plasma 5

Dieter

Am 14.04.2018 06:45, schrieb Timothy Arceri:

From: Boyan Ding 

When draw buffers are changed on a bound framebuffer, DrawBuffer(s) 
hook

should be called. However, it is missing in update_framebuffer with
window-system framebuffer, in which FB's draw buffer state should match
context state, potentially resulting in a change.

Note: This seems to be needed because gallium delays creating the front
buffer. i965 works fine without this change.

V2 (Timothy Arceri):
 - Rebased on merged/simplified DrawBuffer driver function
 - Move DrawBuffer call outside fb->ColorDrawBuffer[0] !=
   ctx->Color.DrawBuffer[0] check to make piglit pass.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99116
---
 src/mesa/main/framebuffer.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 249e775f8cb..81d3b370e73 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -623,6 +623,12 @@ update_framebuffer(struct gl_context *ctx, struct
gl_framebuffer *fb)
  _mesa_drawbuffers(ctx, fb, ctx->Const.MaxDrawBuffers,
ctx->Color.DrawBuffer, NULL);
   }
+
+  /* Call device driver function if fb is the bound draw buffer. 
*/

+  if (fb == ctx->DrawBuffer) {
+ if (ctx->Driver.DrawBuffer)
+ctx->Driver.DrawBuffer(ctx);
+  }
}
else {
   /* This is a user-created framebuffer.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [RFC 3/3] mesa: call DrawBuffer(s) driver hook in update_framebuffer for windows-system FB

2018-04-13 Thread Timothy Arceri



On 14/04/18 14:45, Timothy Arceri wrote:

From: Boyan Ding 

When draw buffers are changed on a bound framebuffer, DrawBuffer(s) hook
should be called. However, it is missing in update_framebuffer with
window-system framebuffer, in which FB's draw buffer state should match
context state, potentially resulting in a change.

Note: This seems to be needed because gallium delays creating the front
buffer. i965 works fine without this change.


Meant to add here:

Fixes a number of Wine apps and the following piglit test on gallium:

./bin/glx-multi-context-front




V2 (Timothy Arceri):
  - Rebased on merged/simplified DrawBuffer driver function
  - Move DrawBuffer call outside fb->ColorDrawBuffer[0] !=
ctx->Color.DrawBuffer[0] check to make piglit pass.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99116
---
  src/mesa/main/framebuffer.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 249e775f8cb..81d3b370e73 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -623,6 +623,12 @@ update_framebuffer(struct gl_context *ctx, struct 
gl_framebuffer *fb)
   _mesa_drawbuffers(ctx, fb, ctx->Const.MaxDrawBuffers,
 ctx->Color.DrawBuffer, NULL);
}
+
+  /* Call device driver function if fb is the bound draw buffer. */
+  if (fb == ctx->DrawBuffer) {
+ if (ctx->Driver.DrawBuffer)
+ctx->Driver.DrawBuffer(ctx);
+  }
 }
 else {
/* This is a user-created framebuffer.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev