[Mesa-dev] [PATCH v3] st/nine: skip position checks in SetCursorPosition()
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()
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()
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
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, &screen); 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
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
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
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
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
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
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/ta
Re: [Mesa-dev] [PATCH 0/2] Update on thread_submit
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
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(&ctx->mutex_pop); +cnd_destroy(&ctx->event_pop); + mtx_destroy(&ctx->mutex_push); +cnd_destroy(&ctx->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(&ctx->thread_resume); +mtx_destroy(&ctx->thread_running); + mtx_destroy(&ctx->mutex_processed); +cnd_destroy(&ctx->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
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(&pool->m, NULL); pthread_cond_init(&pool->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(&pool->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
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(&pool->new_work, &pool->m); -if (pool->shutdown) { -pthread_mutex_unlock(&pool->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
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.
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
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
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
Hi Thierry, On 21/02/18 16:30, Thierry Reding wrote: From: Thierry Reding 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 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.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL IR & TGSI on-disk shader cache
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
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 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 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
On Wed, Jul 24, 2013 at 12:11 AM, Jose Fonseca wrote: > > > - Original Message - >> On Tue, Jul 23, 2013 at 8:57 PM, Roland Scheidegger >> 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 >> >> --- >> >> 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 >> >> -#if defined(MSVC) >> >> +#if defined(PIPE_CC_MSVC) >> >> #include >> >> #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
Re: [Mesa-dev] [PATCH] gallium/util: Fix detection of AVX cpu caps
On Tue, Jul 23, 2013 at 8:57 PM, Roland Scheidegger 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 >> --- >> 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 >> -#if defined(MSVC) >> +#if defined(PIPE_CC_MSVC) >> #include >> #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
[Mesa-dev] [PATCH] gallium/util: Fix detection of AVX cpu caps
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 --- 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 -#if defined(MSVC) +#if defined(PIPE_CC_MSVC) #include #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