Re: [Mesa-dev] [PATCH v2 1/6] mesa: wire up InvalidateFramebuffer

2018-12-12 Thread Frank Richter 

Hello,
On 12.12.18 16:48, Rob Clark wrote:

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 23e49396199..442435655fa 100644
@@ -4695,14 +4754,23 @@ _mesa_InvalidateNamedFramebufferSubData(GLuint 
framebuffer,
 invalidate_framebuffer_storage(ctx, fb, numAttachments, attachments,
x, y, width, height,
"glInvalidateNamedFramebufferSubData");
-}
  
+   discard_sub_framebuffer(ctx, fb, numAttachments, attachments,

+   x, y, width, height);
+}


From what I can see discard_sub_framebuffer() isn't defined yet. It is 
in patch 2/6.


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

[Mesa-dev] [PATCH] gallium/wgl: Avoid calling SetPixelFormat if used as drop-in opengl32

2018-11-05 Thread Frank Richter 

Hello,
I've stumbled across an issue were Mesa failed to create a context when 
it's used as a opengl32 surrogate (from Qt). The weird thing was that 
the failure only happened on certain graphics hardware, even though Mesa 
was supposed to take over GL duties.
As it turns out, the problem was the call to the GDI SetPixelFormat() 
function, which occasionally failed & broke the DC. The failure reason 
isn't quite clear, but it appears to be some sort of race condition, as 
everything works now and then, or when things happen with different timings.


Anyway, since Mesa is supposed to replace opengl32 entirely it seems 
appropriate to avoid calling GDI SetPixelFormat(). The code path that 
calls SetPixelFormat() will have set the pixel format in the 
Mesa-related structures, so GetPixelFormat() won't be called by the 
context creation anyway.


Thoughts on that? Does the reasoning sound sensible?

-f.r.
>From a0edbefb032c38a865870de779777570638cddf3 Mon Sep 17 00:00:00 2001
From: Frank Richter 
Date: Mon, 5 Nov 2018 11:42:55 +0100
Subject: [PATCH] gallium/wgl: Avoid calling SetPixelFormat if used as drop-in
 opengl32

If Mesa is used as a drop-in replacement GetPixelFormat() won't be called
from wglCreateContext() anyway, so we don't need to handle that case.
Also, this fixes issues where the SetPixelFormat() occasionally fails
and breaks the DC.
---
 src/gallium/state_trackers/wgl/stw_framebuffer.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/wgl/stw_framebuffer.c b/src/gallium/state_trackers/wgl/stw_framebuffer.c
index 232ab1d230..c578f97f65 100644
--- a/src/gallium/state_trackers/wgl/stw_framebuffer.c
+++ b/src/gallium/state_trackers/wgl/stw_framebuffer.c
@@ -39,6 +39,7 @@
 #include "stw_winsys.h"
 #include "stw_tls.h"
 #include "stw_context.h"
+#include "stw_ext_context.h"
 #include "stw_st.h"
 
 
@@ -455,9 +456,12 @@ DrvSetPixelFormat(HDC hdc, LONG iPixelFormat)
stw_framebuffer_unlock( fb );
 
/* Some applications mistakenly use the undocumented wglSetPixelFormat
-* function instead of SetPixelFormat, so we call SetPixelFormat here to
-* avoid opengl32.dll's wglCreateContext to fail */
-   if (GetPixelFormat(hdc) == 0) {
+* function instead of SetPixelFormat, so if we're used as an ICD
+* call SetPixelFormat here to avoid opengl32.dll's wglCreateContext
+* to fail.
+* However, if used as a drop-in, avoid calling into opengl32.dll. */
+   if ((wglCreateContext_func != ) &&
+   (GetPixelFormat(hdc) == 0)) {
   BOOL bRet = SetPixelFormat(hdc, iPixelFormat, NULL);
   if (!bRet) {
 	  debug_printf("SetPixelFormat failed\n");
-- 
2.17.2

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

Re: [Mesa-dev] [PATCH] anv_icd.py: improve reproducible builds

2018-01-26 Thread Frank Richter 

On 26.01.2018 09:56, Maxin B. John wrote:

@@ -44,4 +44,4 @@ if __name__ == '__main__':
  }

  with open(args.out, 'w') as f:
-json.dump(json_data, f, indent = 4)
+json.dump(json_data, f, indent = 4, sort_keys=True)


I'm slightly confused what exactly causes the issue.
Please shed some light so we can add it to the commit message.


As nobody answered earlier...
Python dicts do not guarantee any key order at all.
Practically, I think the order depends on the hash value of the key - 
but, since Python uses a different hash seed every time (security 
reasons or so), the hash values change every time, and thus any order of 
the keys changes as well.

Sorting keys obviously guarantees a specific order.

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

Re: [Mesa-dev] [PATCH 2/2] gallium/os: fix os_time_get_nano() to roll over less

2017-08-18 Thread Frank Richter 

Hi,
On 17.08.2017 02:34, Brian Paul wrote:

BTW, I wonder if we would win by using lldiv().  Because this is often
use for performance measurements, so these extra division might add some
impact.


Frank, do you want to look into that?  In the mean time, I'll push the 
patches as-is.


AFAICS, the lldiv implementation in the MSVC runtime (also used by 
MinGW) simply does “a = num / denom; b = num % denom;” as well, so it 
seems unlikely that lldiv() would give a benefit here.


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