[Mesa-dev] [PATCH v3] st/nine: skip position checks in SetCursorPosition()

2019-04-11 Thread Andre Heider 
For HW cursors, "cursor.pos" doesn't hold the current position of the
pointer, just the position of the last call to SetCursorPosition().

Skip the check against stale values and bump the d3dadapter9 drm version
to expose this change of behaviour.

Signed-off-by: Andre Heider 
---

V3: improve version description in d3dadapter/drm.h

 include/d3dadapter/drm.h  | 7 +--
 src/gallium/state_trackers/nine/device9.c | 8 +---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/include/d3dadapter/drm.h b/include/d3dadapter/drm.h
index 647f017fc7f..6939dd4f239 100644
--- a/include/d3dadapter/drm.h
+++ b/include/d3dadapter/drm.h
@@ -29,11 +29,14 @@
 #define D3DADAPTER9DRM_NAME "drm"
 /* current version */
 #define D3DADAPTER9DRM_MAJOR 0
-#define D3DADAPTER9DRM_MINOR 1
+#define D3DADAPTER9DRM_MINOR 2
 
 /* version 0.0: Initial release
  * 0.1: All IDirect3D objects can be assumed to have a pointer to the
- *  internal vtable in second position of the structure */
+ *  internal vtable in second position of the structure
+ * 0.2: IDirect3DDevice9_SetCursorPosition always calls
+ *  ID3DPresent_SetCursorPos for hardware cursors
+ */
 
 struct D3DAdapter9DRM
 {
diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c
index c777f843b67..f165f24ee46 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -793,9 +793,11 @@ NineDevice9_SetCursorPosition( struct NineDevice9 *This,
 
 DBG("This=%p X=%d Y=%d Flags=%d\n", This, X, Y, Flags);
 
-if (This->cursor.pos.x == X &&
-This->cursor.pos.y == Y)
-return;
+/* present >= v1.4 handles this itself */
+if (This->minor_version_num < 4) {
+if (This->cursor.pos.x == X && This->cursor.pos.y == Y)
+return;
+}
 
 This->cursor.pos.x = X;
 This->cursor.pos.y = Y;
-- 
2.20.1

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

[Mesa-dev] [PATCH v2] st/nine: skip position checks in SetCursorPosition()

2019-04-08 Thread Andre Heider 
For HW cursors, "cursor.pos" doesn't hold the current position of the
pointer, just the position of the last call to SetCursorPosition().

Skip the check against stale values and bump the d3dadapter9 drm version
to expose this change of behaviour.

Signed-off-by: Andre Heider 
---
V2: don't introduce SetVersion(), bump D3DADAPTER9DRM_MINOR instead

Corresponding d3d9-nine.dll patch:
https://github.com/iXit/wine-nine-standalone/commit/e09fcbbad4efd481833df1123de0cb690e1b2860

 include/d3dadapter/drm.h  | 7 +--
 src/gallium/state_trackers/nine/device9.c | 8 +---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/include/d3dadapter/drm.h b/include/d3dadapter/drm.h
index 647f017fc7f..210e2395669 100644
--- a/include/d3dadapter/drm.h
+++ b/include/d3dadapter/drm.h
@@ -29,11 +29,14 @@
 #define D3DADAPTER9DRM_NAME "drm"
 /* current version */
 #define D3DADAPTER9DRM_MAJOR 0
-#define D3DADAPTER9DRM_MINOR 1
+#define D3DADAPTER9DRM_MINOR 2
 
 /* version 0.0: Initial release
  * 0.1: All IDirect3D objects can be assumed to have a pointer to the
- *  internal vtable in second position of the structure */
+ *  internal vtable in second position of the structure
+ * 0.2: IDirect3DDevice9_SetCursorPosition doesn't check the cursor
+ *  position anymore
+ */
 
 struct D3DAdapter9DRM
 {
diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c
index db1c3a1d23d..0b1fe59cb70 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -793,9 +793,11 @@ NineDevice9_SetCursorPosition( struct NineDevice9 *This,
 
 DBG("This=%p X=%d Y=%d Flags=%d\n", This, X, Y, Flags);
 
-if (This->cursor.pos.x == X &&
-This->cursor.pos.y == Y)
-return;
+/* present >= v1.4 handles this itself */
+if (This->minor_version_num < 4) {
+if (This->cursor.pos.x == X && This->cursor.pos.y == Y)
+return;
+}
 
 This->cursor.pos.x = X;
 This->cursor.pos.y = Y;
-- 
2.20.1

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

[Mesa-dev] [PATCH 2/2] st/nine: skip position checks in SetCursorPosition()

2019-04-04 Thread Andre Heider 
For HW cursors, "cursor.pos" doesn't hold the current position of the
pointer, just the position of the last call to SetCursorPosition().

Skip the check against stale values for present interface v1.5, so it
can do it properly itself.

Signed-off-by: Andre Heider 
---
Corresponding d3d9-nine.dll patch:
https://github.com/iXit/wine-nine-standalone/commit/e095d0beb2004f69a9b917266e556920296050f7

 src/gallium/state_trackers/nine/adapter9.c | 2 +-
 src/gallium/state_trackers/nine/device9.c  | 8 +---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/nine/adapter9.c 
b/src/gallium/state_trackers/nine/adapter9.c
index 4f648e894b8..774e3cf10dd 100644
--- a/src/gallium/state_trackers/nine/adapter9.c
+++ b/src/gallium/state_trackers/nine/adapter9.c
@@ -35,7 +35,7 @@
 #define DBG_CHANNEL DBG_ADAPTER
 
 /* The maximum supported present version */
-#define MAX_PRESENT_VERSION_MINOR 4
+#define MAX_PRESENT_VERSION_MINOR 5
 
 HRESULT
 NineAdapter9_ctor( struct NineAdapter9 *This,
diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c
index db1c3a1d23d..6f9094b62c2 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -793,9 +793,11 @@ NineDevice9_SetCursorPosition( struct NineDevice9 *This,
 
 DBG("This=%p X=%d Y=%d Flags=%d\n", This, X, Y, Flags);
 
-if (This->cursor.pos.x == X &&
-This->cursor.pos.y == Y)
-return;
+/* present >= v1.5 handles this itself */
+if (This->minor_version_num < 5) {
+if (This->cursor.pos.x == X && This->cursor.pos.y == Y)
+return;
+}
 
 This->cursor.pos.x = X;
 This->cursor.pos.y = Y;
-- 
2.20.1

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

[Mesa-dev] [PATCH 1/2] st/nine: introduce SetVersion() for present interface v1.4

2019-04-04 Thread Andre Heider 
A follow up patch requires a behaviour change, so we need to negotiate
the present version to be used to keep backward compatiblity.

We already get the supported version from the WINE side via GetVersion().
Introduce the member SetVersion() to pass back the maximum common
version.

Signed-off-by: Andre Heider 
---

Corresponding d3d9-nine.dll patch:
https://github.com/iXit/wine-nine-standalone/commit/c7d3b86ee3dc40f897508cd13a3862c277cbe08c

 include/d3dadapter/present.h   |  3 +++
 src/gallium/state_trackers/nine/adapter9.c | 11 +++
 2 files changed, 14 insertions(+)

diff --git a/include/d3dadapter/present.h b/include/d3dadapter/present.h
index 0325ebc511f..2f784837cfb 100644
--- a/include/d3dadapter/present.h
+++ b/include/d3dadapter/present.h
@@ -151,6 +151,8 @@ typedef struct ID3DPresentGroupVtbl
 /* used to create additional presentation interfaces along the way */
 HRESULT (WINAPI *CreateAdditionalPresent)(ID3DPresentGroup *This, 
D3DPRESENT_PARAMETERS *pPresentationParameters, ID3DPresent **ppPresent);
 void (WINAPI *GetVersion) (ID3DPresentGroup *This, int *major, int *minor);
+/* Available since version 1.4 */
+void (WINAPI *SetVersion) (ID3DPresentGroup *This, int major, int minor);
 } ID3DPresentGroupVtbl;
 
 struct ID3DPresentGroup
@@ -167,6 +169,7 @@ struct ID3DPresentGroup
 #define ID3DPresentGroup_GetPresent(p,a,b) (p)->lpVtbl->GetPresent(p,a,b)
 #define ID3DPresentGroup_CreateAdditionalPresent(p,a,b) 
(p)->lpVtbl->CreateAdditionalPresent(p,a,b)
 #define ID3DPresentGroup_GetVersion(p,a,b) (p)->lpVtbl->GetVersion(p,a,b)
+#define ID3DPresentGroup_SetVersion(p,a,b) (p)->lpVtbl->SetVersion(p,a,b)
 
 #endif /* __cplusplus */
 
diff --git a/src/gallium/state_trackers/nine/adapter9.c 
b/src/gallium/state_trackers/nine/adapter9.c
index 3aa95b93b2f..4f648e894b8 100644
--- a/src/gallium/state_trackers/nine/adapter9.c
+++ b/src/gallium/state_trackers/nine/adapter9.c
@@ -34,6 +34,9 @@
 
 #define DBG_CHANNEL DBG_ADAPTER
 
+/* The maximum supported present version */
+#define MAX_PRESENT_VERSION_MINOR 4
+
 HRESULT
 NineAdapter9_ctor( struct NineAdapter9 *This,
struct NineUnknownParams *pParams,
@@ -999,6 +1002,14 @@ NineAdapter9_CreateDevice( struct NineAdapter9 *This,
 return D3DERR_NOTAVAILABLE;
 }
 
+if (minor >= 4) {
+/* d3d9-nine.dll might support a higher present version than we do.
+ * Limit it to our supported version to keep expected behaviour.
+ */
+minor = MIN2(minor, MAX_PRESENT_VERSION_MINOR);
+ID3DPresentGroup_SetVersion(pPresentationGroup, major, minor);
+}
+
 hr = NineAdapter9_GetScreen(This, DeviceType, );
 if (FAILED(hr)) {
 DBG("Failed to get pipe_screen.\n");
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] st/nine: enable csmt per default on iris

2019-03-21 Thread Andre Heider 

On 20/03/2019 23:47, Axel Davy wrote:

On 20/03/2019 21:38, Andre Heider wrote:

iris is thread safe, enable csmt for a ~5% performace boost.

Signed-off-by: Andre Heider 
---
  src/gallium/state_trackers/nine/device9.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c

index 24c8ce062b3..db1c3a1d23d 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -266,13 +266,15 @@ NineDevice9_ctor( struct NineDevice9 *This,
  }
  /* Initialize CSMT */
+    /* r600, radeonsi and iris are thread safe. */
  if (pCTX->csmt_force == 1)
  This->csmt_active = true;
  else if (pCTX->csmt_force == 0)
  This->csmt_active = false;
-    else
-    /* r600 and radeonsi are thread safe. */
-    This->csmt_active = strstr(pScreen->get_name(pScreen), "AMD") 
!= NULL;

+    else if (strstr(pScreen->get_name(pScreen), "AMD") != NULL)
+    This->csmt_active = true;
+    else if (strstr(pScreen->get_name(pScreen), "Intel") != NULL)
+    This->csmt_active = true;
  /* We rely on u_upload_mgr using persistent coherent buffers 
(which don't
   * require flush to work in multi-pipe_context scenario) for 
vertex and



Could have been an || inside the same if, but maybe it is easier to read 
that way.


Yeah, I chose this way just for cosmetically reasons ;)


Reviewed-by: Axel Davy 


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

[Mesa-dev] [PATCH] st/nine: enable csmt per default on iris

2019-03-20 Thread Andre Heider 
iris is thread safe, enable csmt for a ~5% performace boost.

Signed-off-by: Andre Heider 
---
 src/gallium/state_trackers/nine/device9.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c
index 24c8ce062b3..db1c3a1d23d 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -266,13 +266,15 @@ NineDevice9_ctor( struct NineDevice9 *This,
 }
 
 /* Initialize CSMT */
+/* r600, radeonsi and iris are thread safe. */
 if (pCTX->csmt_force == 1)
 This->csmt_active = true;
 else if (pCTX->csmt_force == 0)
 This->csmt_active = false;
-else
-/* r600 and radeonsi are thread safe. */
-This->csmt_active = strstr(pScreen->get_name(pScreen), "AMD") != NULL;
+else if (strstr(pScreen->get_name(pScreen), "AMD") != NULL)
+This->csmt_active = true;
+else if (strstr(pScreen->get_name(pScreen), "Intel") != NULL)
+This->csmt_active = true;
 
 /* We rely on u_upload_mgr using persistent coherent buffers (which don't
  * require flush to work in multi-pipe_context scenario) for vertex and
-- 
2.20.1

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

Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected

2019-03-07 Thread Andre Heider 

On 07/03/2019 15:08, Dieter Nützel wrote:
can you please send a patch to the list (and then we will see it at 
Patchwork Mesa, too), please? It is much faster (for me) and I haven't 
the time to dig me into Gitlab MRs etc. stuff at the moment. OLD school 
man...


It's just a single patch in that MR. As with github, you can append 
.patch to the url:


https://gitlab.freedesktop.org/Venemo/mesa/commit/24d534e355f54edb4b27451d0e4d92a1adb1669c.patch

Or just `curl  | git am`. Does that work for you?

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

Re: [Mesa-dev] last call for autotools

2018-12-14 Thread Andre Heider 

On 14/12/2018 17:53, Dylan Baker wrote:

Quoting Gert Wollny (2018-12-14 03:44:32)

Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
(2) It would be nice if Meson would distribute some default cross build
files, currently everybody has to roll its own, and I guess in the end
they all look mostly the same.


Please ask your distro to write and distribute the cross files. It's simply
impossible for meson to distribute them for a huge number of reasons, but
basically it boils down to too many distros with too many differences. I have
done basically everything I can (personally) to make this easier, including
adding support for loading cross files from XDG paths (/usr/share/meson/cross,
etc)



(3) I also noted that with across build one has to set the library
install directory manually, because it defaults to the directory used
for the build machine - i.e. a i386 cross build on debian amd64 should
set the lib install directory on Debian to "lib/i386-linux-gnu" but it
sets it to "lib/x86_64-linux-gnu"


There is this issue: https://github.com/mesonbuild/meson/issues/4008

This is another case that is really hard to handle because of the way different
distros have handled installing x86 and x86_64 binaries on the same OS. To name
a few:
debian : lib/$gnu-tri/
arch   : lib/ + lib32/
fedora : lib64/ + lib32/

I'm sure there are more, but getting that right all of the time is actually
pretty hard. I'll look into it.


It's not just the libdir, there's no real way for a project to provide 
all the required cross settings so it works everywhere. Like the 
pkg-config binary name for e.g. cross-compiling 32bit binaries. I didn't 
find anything user friendly, so I worked around that on another project 
[0]. And I'm sure there's more.


While all that is doable, it is annoying. Isn't there any way for meson 
to provide a standard set of cross files for distros? If it's the 
distro's responsibility to provide these without any guidelines it's 
just going to be another mess, because either a distro doesn't at all or 
they all do it differently.


[0] https://github.com/dhewg/nine/blob/master/bootstrap.sh

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

Re: [Mesa-dev] [PATCH] d3dadapter9: use snprintf(..., "%s", ...) instead of strncpy

2018-11-26 Thread Andre Heider 

On 25/11/2018 17:23, Axel Davy wrote:
Reading 
https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ 

I think the snprintf variant suffers from the same issue, and the 
compiler is just not yet able to detect it,

and send the same warning (but it might do in later gcc versions).


In this case we care about the terminating NULL (which strncpy() does 
not ensure) and not really about the truncation, because all these 
chunks are about D3DADAPTER_IDENTIFIER9.Description with a fixed size of 
512 chars.


Even if those spots would get truncated, you won't get a warning about 
it, see [0] ;)


Probably a better fix would be to copy with a max size of 
sizeof(drvid->Description)-1 and do

drvid->Description[sizeof(drvid->Description)-1] = '\0';
(Though the webpage says only doing the assignment should be sufficient 
to please gcc).


Sure, but then mesa might as well import a helper like strlcpy() [1] 
instead of doing that locally.


For these few uncritical spots I think snprintf() is just fine, even if 
a format specifier of just "%s" looks weird. But that's your call.


Thanks,
Andre

[0] 97ae5a85 "meson+autotools: get rid of spammy GCC warning 
-Wformat-truncation"

[1] https://cgit.freedesktop.org/libbsd/tree/src/strlcpy.c
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] d3dadapter9: use snprintf(..., "%s", ...) instead of strncpy

2018-11-25 Thread Andre Heider 
Fixes -Wstringop-truncation compiler warnings.
See f836d799f9066adf58f36 "intel/decoder: use snprintf(..., "%s", ...) instead 
of strncpy"

Signed-off-by: Andre Heider 
---
 src/gallium/targets/d3dadapter9/description.c | 27 ---
 src/gallium/targets/d3dadapter9/drm.c |  8 +++---
 2 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/src/gallium/targets/d3dadapter9/description.c 
b/src/gallium/targets/d3dadapter9/description.c
index c0a86782f8..a3e4cd6177 100644
--- a/src/gallium/targets/d3dadapter9/description.c
+++ b/src/gallium/targets/d3dadapter9/description.c
@@ -20,6 +20,7 @@
  * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
  * USE OR OTHER DEALINGS IN THE SOFTWARE. */
 
+#include 
 #include 
 #include "adapter9.h"
 
@@ -239,7 +240,7 @@ d3d_match_vendor_id( D3DADAPTER_IDENTIFIER9* drvid,
 DBG("unknown vendor 0x4%x, emulating 0x4%x\n", drvid->VendorId, 
fallback_ven);
 drvid->VendorId = fallback_ven;
 drvid->DeviceId = fallback_dev;
-strncpy(drvid->Description, fallback_name, sizeof(drvid->Description));
+snprintf(drvid->Description, sizeof(drvid->Description), "%s", 
fallback_name);
 }
 
 /* fill in driver name and version */
@@ -277,46 +278,54 @@ void d3d_fill_cardname(D3DADAPTER_IDENTIFIER9* drvid) {
 case HW_VENDOR_INTEL:
 for (i = 0; i < sizeof(cards_intel) / sizeof(cards_intel[0]); i++) {
 if (strstr(drvid->Description, cards_intel[i].mesaname)) {
-strncpy(drvid->Description, cards_intel[i].d3d9name, 
sizeof(drvid->Description));
+snprintf(drvid->Description, sizeof(drvid->Description),
+ "%s", cards_intel[i].d3d9name);
 return;
 }
 }
 /* use a fall-back if nothing matches */
 DBG("Unknown card name %s!\n", drvid->DeviceName);
-strncpy(drvid->Description, cards_intel[0].d3d9name, 
sizeof(drvid->Description));
+snprintf(drvid->Description, sizeof(drvid->Description),
+ "%s", cards_intel[0].d3d9name);
 break;
 case HW_VENDOR_VMWARE:
 for (i = 0; i < sizeof(cards_vmware) / sizeof(cards_vmware[0]); i++) {
 if (strstr(drvid->Description, cards_vmware[i].mesaname)) {
-strncpy(drvid->Description, cards_vmware[i].d3d9name, 
sizeof(drvid->Description));
+snprintf(drvid->Description, sizeof(drvid->Description),
+ "%s", cards_vmware[i].d3d9name);
 return;
 }
 }
 /* use a fall-back if nothing matches */
 DBG("Unknown card name %s!\n", drvid->DeviceName);
-strncpy(drvid->Description, cards_vmware[0].d3d9name, 
sizeof(drvid->Description));
+snprintf(drvid->Description, sizeof(drvid->Description),
+ "%s", cards_vmware[0].d3d9name);
 break;
 case HW_VENDOR_AMD:
 for (i = 0; i < sizeof(cards_amd) / sizeof(cards_amd[0]); i++) {
 if (strstr(drvid->Description, cards_amd[i].mesaname)) {
-strncpy(drvid->Description, cards_amd[i].d3d9name, 
sizeof(drvid->Description));
+snprintf(drvid->Description, sizeof(drvid->Description),
+ "%s", cards_amd[i].d3d9name);
 return;
 }
 }
 /* use a fall-back if nothing matches */
 DBG("Unknown card name %s!\n", drvid->DeviceName);
-strncpy(drvid->Description, cards_amd[0].d3d9name, 
sizeof(drvid->Description));
+snprintf(drvid->Description, sizeof(drvid->Description),
+ "%s", cards_amd[0].d3d9name);
 break;
 case HW_VENDOR_NVIDIA:
 for (i = 0; i < sizeof(cards_nvidia) / sizeof(cards_nvidia[0]); i++) {
 if (strstr(drvid->Description, cards_nvidia[i].mesaname)) {
-strncpy(drvid->Description, cards_nvidia[i].d3d9name, 
sizeof(drvid->Description));
+snprintf(drvid->Description, sizeof(drvid->Description),
+ "%s", cards_nvidia[i].d3d9name);
 return;
 }
 }
 /* use a fall-back if nothing matches */
 DBG("Unknown card name %s!\n", drvid->DeviceName);
-strncpy(drvid->Description, cards_nvidia[0].d3d9name, 
sizeof(drvid->Description));
+snprintf(drvid->Description, sizeof(drvid->Description),
+ "%s", cards_nvidia[0].d3d9name);
 break;
 default:
 break;
diff --git a/src/gallium/targets/d3dadapter9/drm.c 
b/src/gallium/targets/d3dadapter9/drm.c
index 6fb8caf5c2..e08778b81d 100644
--- a/src/gallium/targets/d3

Re: [Mesa-dev] [PATCH 0/2] Update on thread_submit

2018-11-11 Thread Andre Heider 

On 10/11/2018 17:09, Axel Davy wrote:


Axel Davy (2):
   st/nine: Allow 'triple buffering' with thread_submit
   st/nine: Remove thread_submit warning


Nice! Series is:
Tested-by: Andre Heider 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] st/nine: plug thread related leaks

2018-11-06 Thread Andre Heider 
Signed-off-by: Andre Heider 
---
 src/gallium/state_trackers/nine/nine_queue.c | 4 
 src/gallium/state_trackers/nine/nine_state.c | 5 +
 2 files changed, 9 insertions(+)

diff --git a/src/gallium/state_trackers/nine/nine_queue.c 
b/src/gallium/state_trackers/nine/nine_queue.c
index 7a85798f0f..c09810b1a8 100644
--- a/src/gallium/state_trackers/nine/nine_queue.c
+++ b/src/gallium/state_trackers/nine/nine_queue.c
@@ -265,8 +265,12 @@ void
 nine_queue_delete(struct nine_queue_pool *ctx)
 {
 unsigned i;
+
 mtx_destroy(>mutex_pop);
+cnd_destroy(>event_pop);
+
 mtx_destroy(>mutex_push);
+cnd_destroy(>event_push);
 
 for (i = 0; i < NINE_CMD_BUFS; i++)
 FREE(ctx->pool[i].mem_pool);
diff --git a/src/gallium/state_trackers/nine/nine_state.c 
b/src/gallium/state_trackers/nine/nine_state.c
index 74aaf57a54..273be88e2b 100644
--- a/src/gallium/state_trackers/nine/nine_state.c
+++ b/src/gallium/state_trackers/nine/nine_state.c
@@ -234,7 +234,12 @@ nine_csmt_destroy( struct NineDevice9 *device, struct 
csmt_context *ctx )
 
 nine_csmt_wait_processed(ctx);
 nine_queue_delete(ctx->pool);
+
+mtx_destroy(>thread_resume);
+mtx_destroy(>thread_running);
+
 mtx_destroy(>mutex_processed);
+cnd_destroy(>event_processed);
 
 FREE(ctx);
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 1/3] st/nine: fix stack corruption due to ABI mismatch

2018-11-06 Thread Andre Heider 
This fixes various crashes and hangs when using nine's 'thread_submit'
feature.

On 64bit, the thread function's data argument would just be NULL.
On 32bit, the data argument would be garbage depending on the compiler
flags (in my case -march>=core2).

Fixes: f3fa7e3068512d ("st/nine: Use WINE thread for threadpool")
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Andre Heider 
---
 src/gallium/state_trackers/nine/threadpool.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/nine/threadpool.c 
b/src/gallium/state_trackers/nine/threadpool.c
index cc62fd2579..19721aab2d 100644
--- a/src/gallium/state_trackers/nine/threadpool.c
+++ b/src/gallium/state_trackers/nine/threadpool.c
@@ -37,6 +37,7 @@
 #include "os/os_thread.h"
 #include "threadpool.h"
 
+/* POSIX thread function */
 static void *
 threadpool_worker(void *data)
 {
@@ -76,6 +77,15 @@ threadpool_worker(void *data)
 return NULL;
 }
 
+/* Windows thread function */
+static DWORD NINE_WINAPI
+wthreadpool_worker(void *data)
+{
+threadpool_worker(data);
+
+return 0;
+}
+
 struct threadpool *
 _mesa_threadpool_create(struct NineSwapChain9 *swapchain)
 {
@@ -87,7 +97,9 @@ _mesa_threadpool_create(struct NineSwapChain9 *swapchain)
 pthread_mutex_init(>m, NULL);
 pthread_cond_init(>new_work, NULL);
 
-pool->wthread = NineSwapChain9_CreateThread(swapchain, threadpool_worker, 
pool);
+/* This uses WINE's CreateThread, so the thread function needs to use
+ * the Windows ABI */
+pool->wthread = NineSwapChain9_CreateThread(swapchain, wthreadpool_worker, 
pool);
 if (!pool->wthread) {
 /* using pthread as fallback */
 pthread_create(>pthread, NULL, threadpool_worker, pool);
-- 
2.19.1

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

[Mesa-dev] [PATCH 3/3] st/nine: clean up thead shutdown sequence a bit

2018-11-06 Thread Andre Heider 
Just break out of the loop instead, it does the same thing.

Signed-off-by: Andre Heider 
---
 src/gallium/state_trackers/nine/threadpool.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/nine/threadpool.c 
b/src/gallium/state_trackers/nine/threadpool.c
index 19721aab2d..3ce6cd5752 100644
--- a/src/gallium/state_trackers/nine/threadpool.c
+++ b/src/gallium/state_trackers/nine/threadpool.c
@@ -52,10 +52,8 @@ threadpool_worker(void *data)
 while (!pool->workqueue && !pool->shutdown)
 pthread_cond_wait(>new_work, >m);
 
-if (pool->shutdown) {
-pthread_mutex_unlock(>m);
-return NULL;
-}
+if (pool->shutdown)
+break;
 
 /* Pull the first task from the list.  We don't free it -- it now lacks
  * a reference other than the worker creator's, whose responsibility it
-- 
2.19.1

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

[Mesa-dev] [PATCH] gallium/hud: fix power sensor readings for amdgpu users

2018-10-27 Thread Andre Heider 
amdgpu doesn't use the INPUT but the AVERAGE subfeature:

$ sensors -u
amdgpu-pci-0100
Adapter: PCI adapter
power1:
  power1_average: 17.233
  power1_cap: 180.000

Signed-off-by: Andre Heider 
---
 src/gallium/auxiliary/hud/hud_sensors_temp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/auxiliary/hud/hud_sensors_temp.c 
b/src/gallium/auxiliary/hud/hud_sensors_temp.c
index c26e7b9b2a..c226e89cc4 100644
--- a/src/gallium/auxiliary/hud/hud_sensors_temp.c
+++ b/src/gallium/auxiliary/hud/hud_sensors_temp.c
@@ -122,6 +122,9 @@ get_sensor_values(struct sensors_temp_info *sti)
case SENSORS_POWER_CURRENT:
   sf = sensors_get_subfeature(sti->chip, sti->feature,
   SENSORS_SUBFEATURE_POWER_INPUT);
+  if (!sf)
+  sf = sensors_get_subfeature(sti->chip, sti->feature,
+  SENSORS_SUBFEATURE_POWER_AVERAGE);
   if (sf) {
  /* Sensors API returns in WATTs, even though driver is reporting mW,
   * convert back to mW */
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH] radv: Fix WSI & PCI bus info initialization order.

2018-10-19 Thread Andre Heider 

Hi,

On 19/10/2018 11:53, Bas Nieuwenhuizen wrote:

Trying to access the bus info before it is initialized is not going
to work.

Fixes: baa38c144f6 "vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108491


confirmed, fixes the issue I've been seeing:
Tested-by: Andre Heider 

Thanks for the quick fix,
Andre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching

2018-10-19 Thread Andre Heider 

Hi,

On 18/10/2018 17:13, Jason Ekstrand wrote:

This lets us avoid passing the DRM fd around all over the place and gets
us closer to layer utopia.
---
  src/amd/vulkan/radv_wsi.c   |  3 --
  src/amd/vulkan/radv_wsi_x11.c   |  4 +--
  src/intel/vulkan/anv_wsi.c  |  4 +--
  src/intel/vulkan/anv_wsi_x11.c  |  4 +--
  src/vulkan/wsi/wsi_common.c | 45 +
  src/vulkan/wsi/wsi_common.h |  5 ++--
  src/vulkan/wsi/wsi_common_display.c | 22 +-
  src/vulkan/wsi/wsi_common_private.h |  6 ++--
  src/vulkan/wsi/wsi_common_wayland.c |  3 --
  src/vulkan/wsi/wsi_common_x11.c | 34 +++---
  src/vulkan/wsi/wsi_common_x11.h |  1 -
  11 files changed, 61 insertions(+), 70 deletions(-)


unfortunately this regresses radv, see
https://bugs.freedesktop.org/show_bug.cgi?id=108491

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

Re: [Mesa-dev] [PATCH 00/15] radv: add support for VK_EXT_transform_feedback

2018-10-14 Thread Andre Heider 

Hi,

On 13/10/2018 14:57, Samuel Pitoiset wrote:

Hi,

This series implements VK_EXT_transform_feedback for RADV. We tested it
quite a lot with DXVK and also with RenderDoc, it should be stable enough.

Please review, thanks!


on Tonga, this series is:

Tested-by: Andre Heider 

On wine/dxvk/witcher3 I can now see those annoying sirens too ;)

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

Re: [Mesa-dev] [PATCH 0/5] NVIDIA Tegra support

2018-02-21 Thread Andre Heider 

Hi Thierry,

On 21/02/18 16:30, Thierry Reding wrote:

From: Thierry Reding <tred...@nvidia.com>

This series of patches implements initial support for Tegra. The first
two patches import DRM UAPI from v4.16-rc1 that provide framebuffer
modifiers that can be used to specify buffers shared between Nouveau
and the Tegra DRM driver.

Patches 3 and 4 add support for framebuffer modifiers to Nouveau and
patch 5 build on top of those to provide initial Tegra support in Mesa.
The current patches allow running common use-cases such as Wayland,
kmscube, etc.

Some people have been using earlier versions of these patches to run a
completely open-source graphics stack on various Tegra210 devices. I've
Cc'ed some of them so that they can provide feedback.


works for me with the GL apps/games I have on this boards, so for the 
series:

Tested-by: Andre Heider <a.hei...@gmail.com>

And thanks for taking care of meson, that cut the native build time down 
to almost 50% ;)


Regards,
Andre


This series is also available in a git repository here:

https://cgit.freedesktop.org/~tagr/mesa #master

though that also contains the Nouveau syncfd patches that are still work
in progress and which require new kernel/userspace ABI. The patches here
work on top of a vanilla recent (v4.16-rc1) Linux kernel.

Thierry

Thierry Reding (5):
   drm/fourcc: Fix fourcc_mod_code() definition
   drm/tegra: Sanitize format modifiers
   nouveau/nvc0: Extract common tile mode macro
   nouveau: Add framebuffer modifier support
   tegra: Initial support

  configure.ac   |   11 +-
  include/drm-uapi/drm_fourcc.h  |   38 +-
  include/drm-uapi/tegra_drm.h   |  225 
  meson.build|7 +-
  src/gallium/Makefile.am|5 +
  .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
  src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
  .../auxiliary/target-helpers/drm_helper_public.h   |3 +
  src/gallium/drivers/nouveau/Android.mk |3 +
  src/gallium/drivers/nouveau/Makefile.am|1 +
  src/gallium/drivers/nouveau/nouveau_buffer.c   |3 +-
  src/gallium/drivers/nouveau/nouveau_buffer.h   |3 +-
  src/gallium/drivers/nouveau/nouveau_screen.c   |   14 +
  src/gallium/drivers/nouveau/nv30/nv30_resource.c   |6 +-
  src/gallium/drivers/nouveau/nv50/nv50_resource.c   |5 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|8 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_resource.c   |   80 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_resource.h   |   20 +-
  src/gallium/drivers/tegra/Automake.inc |   11 +
  src/gallium/drivers/tegra/Makefile.am  |   18 +
  src/gallium/drivers/tegra/Makefile.sources |3 +
  src/gallium/drivers/tegra/meson.build  |   41 +
  src/gallium/drivers/tegra/tegra_context.c  | 1294 
  src/gallium/drivers/tegra/tegra_context.h  |   81 ++
  src/gallium/drivers/tegra/tegra_resource.h |   76 ++
  src/gallium/drivers/tegra/tegra_screen.c   |  674 ++
  src/gallium/drivers/tegra/tegra_screen.h   |   45 +
  src/gallium/meson.build|6 +
  src/gallium/targets/dri/Makefile.am|2 +
  src/gallium/targets/dri/meson.build|4 +-
  src/gallium/targets/dri/target.c   |4 +
  src/gallium/targets/vdpau/Makefile.am  |2 +
  src/gallium/winsys/tegra/drm/Makefile.am   |   11 +
  src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
  src/gallium/winsys/tegra/drm/meson.build   |   33 +
  src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
  src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   33 +
  37 files changed, 2797 insertions(+), 36 deletions(-)
  create mode 100644 include/drm-uapi/tegra_drm.h
  create mode 100644 src/gallium/drivers/tegra/Automake.inc
  create mode 100644 src/gallium/drivers/tegra/Makefile.am
  create mode 100644 src/gallium/drivers/tegra/Makefile.sources
  create mode 100644 src/gallium/drivers/tegra/meson.build
  create mode 100644 src/gallium/drivers/tegra/tegra_context.c
  create mode 100644 src/gallium/drivers/tegra/tegra_context.h
  create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
  create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
  create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
  create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
  create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
  create mode 100644 src/gallium/winsys/tegra/drm/meson.build
  create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
  create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c



___
mesa-dev mailing list
mesa-dev@lists.freedeskt

Re: [Mesa-dev] GLSL IR & TGSI on-disk shader cache

2017-02-11 Thread Andre Heider 

On 02/11/2017 03:44 AM, Pierre-Loup A. Griffais wrote:

On 02/10/2017 04:01 AM, Nicolai Hähnle wrote:

On 10.02.2017 12:46, Timothy Arceri wrote:

On 10/02/17 21:35, Nicolai Hähnle wrote:

The people who want to distribute precompiled binaries will have to
set up infrastructure where they do the precompilation across all the
distro/build combinations that they want to support.


I believe the plan is to also have them collected directly from users.


Oh $deity, please no. That's a security nightmare waiting to happen.


Debatable, but off-topic either way; happy to chat about it offline.


Maybe that's just me, but if this series allows 3rd parties to ship and 
run code from untrusted sources, then I don't see how this is off-topic.


It's rather that sort of topic that should not be discussed offline.

Regards,
Andre

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

Re: [Mesa-dev] [PATCH] r600g/sb: fix stack size computation on evergreen

2013-12-09 Thread Andre Heider 
On Sat, Dec 07, 2013 at 07:06:36PM +0400, Vadim Girlin wrote:
 On evergreen we have to reserve 1 stack element in some additional cases
 besides the ones mentioned in the docs, but stack size computation was
 recently reimplemented exactly as described in the docs by the patch that
 added workarounds for stack issues on EG/CM, resulting in regressions
 with some apps (Serious Sam 3).
 
 This patch fixes it by restoring previous behavior.
 
 Fixes https://bugs.freedesktop.org/show_bug.cgi?id=72369
 
 Signed-off-by: Vadim Girlin vadimgir...@gmail.com

No idea if one stack element is correct or two like Tom mentioned, but
one already fixes the Serious Sam 3 glitches, so this patch is:

Tested-by: Andre Heider a.hei...@gmail.com

Thanks,
Andre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: Fix detection of AVX cpu caps

2013-07-24 Thread Andre Heider 
On Wed, Jul 24, 2013 at 12:11 AM, Jose Fonseca jfons...@vmware.com wrote:


 - Original Message -
 On Tue, Jul 23, 2013 at 8:57 PM, Roland Scheidegger srol...@vmware.com
 wrote:
  Am 23.07.2013 19:08, schrieb Andre Heider:
  For AVX it's not sufficient to only rely on the cpuid flags. If the CPU
  supports these extensions, but the OS doesn't, issuing these insns will
  trigger an undefined opcode exception.
 
  In addition to the AVX cpuid bit we also need to:
  * test cpuid for OSXSAVE support
  * XGETBV to check if the OS saves/restores AVX regs on context switches
 
  See Detecting Availability and Support at
  http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions
 
  Signed-off-by: Andre Heider a.hei...@gmail.com
  ---
   src/gallium/auxiliary/util/u_cpu_detect.c | 27
   +--
   1 file changed, 25 insertions(+), 2 deletions(-)
 
  diff --git a/src/gallium/auxiliary/util/u_cpu_detect.c
  b/src/gallium/auxiliary/util/u_cpu_detect.c
  index b118fc8..588fc7c 100644
  --- a/src/gallium/auxiliary/util/u_cpu_detect.c
  +++ b/src/gallium/auxiliary/util/u_cpu_detect.c
  @@ -67,7 +67,7 @@
 
   #if defined(PIPE_OS_WINDOWS)
   #include windows.h
  -#if defined(MSVC)
  +#if defined(PIPE_CC_MSVC)
   #include intrin.h
   #endif
   #endif
  @@ -211,6 +211,27 @@ cpuid(uint32_t ax, uint32_t *p)
  p[3] = 0;
   #endif
   }
  +
  +static INLINE uint64_t xgetbv(void)
  +{
  +#if defined(PIPE_CC_GCC)
  +   uint32_t eax, edx;
  +
  +   __asm __volatile (
  + .byte 0x0f, 0x01, 0xd0 // xgetbv isn't supported on gcc  4.4
  + : =a(eax),
  +   =d(edx)
  + : c(0)
  +   );
  +
  +   return ((uint64_t)edx  32) | eax;
  +#elif defined(PIPE_CC_MSVC)  defined(_MSC_FULL_VER) 
  defined(_XCR_XFEATURE_ENABLED_MASK)
  +   return _xgetbv(_XCR_XFEATURE_ENABLED_MASK);
  +#else
  +   return 0;
  +#endif
  +
  +}
   #endif /* X86 or X86_64 */
 
   void
  @@ -284,7 +305,9 @@ util_cpu_detect(void)
util_cpu_caps.has_sse4_1 = (regs2[2]  19)  1;
util_cpu_caps.has_sse4_2 = (regs2[2]  20)  1;
util_cpu_caps.has_popcnt = (regs2[2]  23)  1;
  - util_cpu_caps.has_avx= (regs2[2]  28)  1;
  + util_cpu_caps.has_avx= ((regs2[2]  28)  1)  // AVX
  +((regs2[2]  27)  1)  // OSXSAVE
  +((xgetbv()  6) == 6);// XMM 
  YMM
util_cpu_caps.has_f16c   = (regs2[2]  29)  1;
util_cpu_caps.has_mmx2   = util_cpu_caps.has_sse; /* SSE cpus
supports mmxext too */
 
 
 
  Looks good to me though

 Looks good to me too. Thanks.

  it's a pity detection depends on compiler.
  Granted it looks like icc currently won't work but still...
  I guess that technically the test for sse(x) isn't correct neither as
  that too requires OS support, I don't know off-hand though how to check
  for it (and we'd be talking ANCIENT os here...).

 Ancient indeed ;)

 But with AVX the problem becomes more urgent: All SSE versions used
 the same registers, AVX extended those.
 Now we recently got a AVX enabled vSphere server, and exposing that to
 XP guests doesn't go too well with llvmpipe without this patch.

 I don't know of many llvmpipe windows users, specially XP.   If it's not 
 confidential, how are you using it?

I think the situation can be compared to GNOME Shell/Chrome/Qt5: Its
used for remote sessions and serves as a fallback in case the native
GL driver sucks too much.
According to our render guy: While there's a MS software renderer, it
only implements GL 1.1. No multi texturing, npot restrictions,
additional code paths, testing those paths...  llvmpipe makes life
easier there.

Regards,
Andre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium/util: Fix detection of AVX cpu caps

2013-07-23 Thread Andre Heider 
For AVX it's not sufficient to only rely on the cpuid flags. If the CPU
supports these extensions, but the OS doesn't, issuing these insns will
trigger an undefined opcode exception.

In addition to the AVX cpuid bit we also need to:
* test cpuid for OSXSAVE support
* XGETBV to check if the OS saves/restores AVX regs on context switches

See Detecting Availability and Support at
http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions

Signed-off-by: Andre Heider a.hei...@gmail.com
---
 src/gallium/auxiliary/util/u_cpu_detect.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_cpu_detect.c 
b/src/gallium/auxiliary/util/u_cpu_detect.c
index b118fc8..588fc7c 100644
--- a/src/gallium/auxiliary/util/u_cpu_detect.c
+++ b/src/gallium/auxiliary/util/u_cpu_detect.c
@@ -67,7 +67,7 @@
 
 #if defined(PIPE_OS_WINDOWS)
 #include windows.h
-#if defined(MSVC)
+#if defined(PIPE_CC_MSVC)
 #include intrin.h
 #endif
 #endif
@@ -211,6 +211,27 @@ cpuid(uint32_t ax, uint32_t *p)
p[3] = 0;
 #endif
 }
+
+static INLINE uint64_t xgetbv(void)
+{
+#if defined(PIPE_CC_GCC)
+   uint32_t eax, edx;
+
+   __asm __volatile (
+ .byte 0x0f, 0x01, 0xd0 // xgetbv isn't supported on gcc  4.4
+ : =a(eax),
+   =d(edx)
+ : c(0)
+   );
+
+   return ((uint64_t)edx  32) | eax;
+#elif defined(PIPE_CC_MSVC)  defined(_MSC_FULL_VER)  
defined(_XCR_XFEATURE_ENABLED_MASK)
+   return _xgetbv(_XCR_XFEATURE_ENABLED_MASK);
+#else
+   return 0;
+#endif
+
+}
 #endif /* X86 or X86_64 */
 
 void
@@ -284,7 +305,9 @@ util_cpu_detect(void)
  util_cpu_caps.has_sse4_1 = (regs2[2]  19)  1;
  util_cpu_caps.has_sse4_2 = (regs2[2]  20)  1;
  util_cpu_caps.has_popcnt = (regs2[2]  23)  1;
- util_cpu_caps.has_avx= (regs2[2]  28)  1;
+ util_cpu_caps.has_avx= ((regs2[2]  28)  1)  // AVX
+((regs2[2]  27)  1)  // OSXSAVE
+((xgetbv()  6) == 6);// XMM  YMM
  util_cpu_caps.has_f16c   = (regs2[2]  29)  1;
  util_cpu_caps.has_mmx2   = util_cpu_caps.has_sse; /* SSE cpus 
supports mmxext too */
 
-- 
1.8.3.2

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

Re: [Mesa-dev] [PATCH] gallium/util: Fix detection of AVX cpu caps

2013-07-23 Thread Andre Heider 
On Tue, Jul 23, 2013 at 8:57 PM, Roland Scheidegger srol...@vmware.com wrote:
 Am 23.07.2013 19:08, schrieb Andre Heider:
 For AVX it's not sufficient to only rely on the cpuid flags. If the CPU
 supports these extensions, but the OS doesn't, issuing these insns will
 trigger an undefined opcode exception.

 In addition to the AVX cpuid bit we also need to:
 * test cpuid for OSXSAVE support
 * XGETBV to check if the OS saves/restores AVX regs on context switches

 See Detecting Availability and Support at
 http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions

 Signed-off-by: Andre Heider a.hei...@gmail.com
 ---
  src/gallium/auxiliary/util/u_cpu_detect.c | 27 +--
  1 file changed, 25 insertions(+), 2 deletions(-)

 diff --git a/src/gallium/auxiliary/util/u_cpu_detect.c 
 b/src/gallium/auxiliary/util/u_cpu_detect.c
 index b118fc8..588fc7c 100644
 --- a/src/gallium/auxiliary/util/u_cpu_detect.c
 +++ b/src/gallium/auxiliary/util/u_cpu_detect.c
 @@ -67,7 +67,7 @@

  #if defined(PIPE_OS_WINDOWS)
  #include windows.h
 -#if defined(MSVC)
 +#if defined(PIPE_CC_MSVC)
  #include intrin.h
  #endif
  #endif
 @@ -211,6 +211,27 @@ cpuid(uint32_t ax, uint32_t *p)
 p[3] = 0;
  #endif
  }
 +
 +static INLINE uint64_t xgetbv(void)
 +{
 +#if defined(PIPE_CC_GCC)
 +   uint32_t eax, edx;
 +
 +   __asm __volatile (
 + .byte 0x0f, 0x01, 0xd0 // xgetbv isn't supported on gcc  4.4
 + : =a(eax),
 +   =d(edx)
 + : c(0)
 +   );
 +
 +   return ((uint64_t)edx  32) | eax;
 +#elif defined(PIPE_CC_MSVC)  defined(_MSC_FULL_VER)  
 defined(_XCR_XFEATURE_ENABLED_MASK)
 +   return _xgetbv(_XCR_XFEATURE_ENABLED_MASK);
 +#else
 +   return 0;
 +#endif
 +
 +}
  #endif /* X86 or X86_64 */

  void
 @@ -284,7 +305,9 @@ util_cpu_detect(void)
   util_cpu_caps.has_sse4_1 = (regs2[2]  19)  1;
   util_cpu_caps.has_sse4_2 = (regs2[2]  20)  1;
   util_cpu_caps.has_popcnt = (regs2[2]  23)  1;
 - util_cpu_caps.has_avx= (regs2[2]  28)  1;
 + util_cpu_caps.has_avx= ((regs2[2]  28)  1)  // AVX
 +((regs2[2]  27)  1)  // OSXSAVE
 +((xgetbv()  6) == 6);// XMM  YMM
   util_cpu_caps.has_f16c   = (regs2[2]  29)  1;
   util_cpu_caps.has_mmx2   = util_cpu_caps.has_sse; /* SSE cpus 
 supports mmxext too */



 Looks good to me though it's a pity detection depends on compiler.
 Granted it looks like icc currently won't work but still...
 I guess that technically the test for sse(x) isn't correct neither as
 that too requires OS support, I don't know off-hand though how to check
 for it (and we'd be talking ANCIENT os here...).

Ancient indeed ;)

But with AVX the problem becomes more urgent: All SSE versions used
the same registers, AVX extended those.
Now we recently got a AVX enabled vSphere server, and exposing that to
XP guests doesn't go too well with llvmpipe without this patch.

Thanks,
Andre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev