date:20110510

Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

2011-05-10 Thread Michel Dänzer

On Fre, 2011-05-06 at 14:01 -0700, Jesse Barnes wrote: 
> On Fri, 6 May 2011 13:00:19 -0700
> Jeremy Huddleston  wrote:
> 
> > Yeah, that looks about right.
> > 
> > This in combination with the latest version of "xserver/glx/dri2: use new 
> > GLX/DRI2 swap event types"
> > 
> > Reviewed-by: Jeremy Huddleston 
> 
> Ok here's a more complete patch.  It touches GLX and involves drawable
> lifetimes, which I'm not that familiar with, so careful review
> appreciated.  Note the X vs GLX drawable ID switching in the DRI2 event
> handler (DRI2 just deals with X IDs).
> 
> Kristian and Jeremy, is this a good basis for moving the Apple stuff
> over to a client GLX drawable type?
> 
> -- 
> Jesse Barnes, Intel Open Source Technology Center
> 
> From fae63609dd4fd20ccd84d2211787136bb9a1da05 Mon Sep 17 00:00:00 2001
> From: Jesse Barnes 
> Date: Fri, 6 May 2011 10:31:24 -0700
> Subject: [PATCH] GLX/DRI2: handle swap event swap count wrapping
> 
> Create a new GLX drawable struct to track client related info, and add a
> wrap counter to it drawable and track it as we receive events.  This
> allows us to support the full 64 bits of the event structure we pass to
> the client even though the server only gives us a 32 bit count.
> 
> Signed-off-by: Jesse Barnes 

[...]

> @@ -582,6 +584,14 @@ struct glx_display
>  #endif
>  };
>  
> +struct glx_drawable {
> +   XID xDrawable;
> +   XID drawable;
> +
> +   uint32_t lastEventSbc;
> +   int64_t eventSbcWrap;

Shouldn't eventSbcWrap be unsigned?


> diff --git a/src/glx/glxext.c b/src/glx/glxext.c
> index 02652cb..03c05a3 100644
> --- a/src/glx/glxext.c
> +++ b/src/glx/glxext.c
> @@ -106,7 +106,7 @@ XEXT_GENERATE_ERROR_STRING(__glXErrorString, 
> __glXExtensionName,
>  static Bool
>  __glXWireToEvent(Display *dpy, XEvent *event, xEvent *wire)
>  {
> - struct glx_display *glx_dpy = __glXInitialize(dpy);
> +   struct glx_display *glx_dpy = __glXInitialize(dpy);
>  
> if (glx_dpy == NULL)
>return False;

Superfluous whitespace-only change.


Looks good to me otherwise, but I'm not really familiar with the
client-side GLX drawable lifetime either.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] EGL: Add hardware cursor image format for EGL image extension.

2011-05-10 Thread zhigang gong

 Current EGL only support one drm buffer format which is
 EGL_DRM_BUFFER_FORMAT_ARGB32_MESA. This
 format works fine with normal image, but if we want to
 create a drm buffer which will be used for a hardware cursor,
 then it has problem. The default behaviou for this format is to
 enable tiling for i915 driver. Thus it will choose 512 as the buffer's
 stride. But the hardware cursor can only support 256 as the
 row stride. To solve this problem, I create a new drm buffer
 format named EGL_DRM_BUFFER_FORMAT_HWCURSOR_ARGB32_MESA
 for hardware cursor usage. It will disable the tiling by default
 for i915 driver and then choose 256 as its pitch value. I tested it on a
 Sandy bridge platform, it works fine.
---
 include/EGL/eglext.h  |1 +
 include/GL/internal/dri_interface.h   |1 +
 src/egl/drivers/dri2/egl_dri2.c   |3 +++
 src/mesa/drivers/dri/intel/intel_screen.c |7 +--
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index 9fd3eb8..d0153d3 100644
--- a/include/EGL/eglext.h
+++ b/include/EGL/eglext.h
@@ -127,6 +127,7 @@ typedef EGLBoolean (EGLAPIENTRYP
PFNEGLDESTROYIMAGEKHRPROC) (EGLDisplay dpy, EGL

 /* EGL_DRM_BUFFER_FORMAT_MESA tokens */
 #define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA  0x31D2
+#define EGL_DRM_BUFFER_FORMAT_HWCURSOR_ARGB32_MESA 0x31D3

 /* EGL_DRM_BUFFER_USE_MESA bits */
 #define EGL_DRM_BUFFER_USE_SCANOUT_MESA0x0001
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 2fb729a..fa2341b 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/interna
@@ -127,6 +127,7 @@ typedef EGLBoolean (EGLAPIENTRYP
PFNEGLDESTROYIMAGEKHRPROC) (EGLDisplay dpy, EGL

 /* EGL_DRM_BUFFER_FORMAT_MESA tokens */
 #define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA  0x31D2
+#define EGL_DRM_BUFFER_FORMAT_HWCURSOR_ARGB32_MESA 0x31D3

 /* EGL_DRM_BUFFER_USE_MESA bits */
 #define EGL_DRM_BUFFER_USE_SCANOUT_MESA0x0001
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 2fb729a..fa2341b 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -813,6 +813,7 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_FORMAT_RGB565   0x1001
 #define __DRI_IMAGE_FORMAT_XRGB 0x1002
 #define __DRI_IMAGE_FORMAT_ARGB 0x1003
+#define __DRI_IMAGE_FORMAT_HWCURSOR_ARGB 0x1004

 #define __DRI_IMAGE_USE_SHARE  0x0001
 #define __DRI_IMAGE_USE_SCANOUT0x0002
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 5e47fbe..23ab0ed 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1043,6 +1043,9 @@ dri2_create_drm_image_mesa(_EGLDriver *drv,
_EGLDisplay *disp,
}

switch (attrs.DRMBufferFormatMESA) {
+   case EGL_DRM_BUFFER_FORMAT_HWCURSOR_ARGB32_MESA:
+  format = __DRI_IMAGE_FORMAT_HWCURSOR_ARGB;
+  break;
case EGL_DRM_BUFFER_FORMAT_ARGB32_MESA:
   format = __DRI_IMAGE_FORMAT_ARGB;
   break;
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 7de0d12..475c142 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -217,11 +217,12 @@ intel_create_image(__DRIscreen *screen,
__DRIimage *image;
struct intel_screen *intelScreen = screen->private;
int cpp;
+   int tiling;

image = CALLOC(sizeof *image);
if (image == NULL)
   return NULL;
-
+   tiling = I915_TILING_X;
switch (format) {
case __DRI_IMAGE_FORMAT_RGB565:
   image->format = MESA_FORMAT_RGB565;
@@ -233,6 +234,8 @@ intel_create_image(__DRIscreen *screen,
   image->internal_format = GL_RGB;
   image->data_type = GL_UNSIGNED_BYTE;
   break;
+   case __DRI_IMAGE_FORMAT_HWCURSOR_ARGB:
+  tiling = I915_TILING_NONE;
case __DRI_IMAGE_FORMAT_ARGB:
   image->format = MESA_FORMAT_ARGB;
   image->internal_format = GL_RGBA;
@@ -247,7 +250,7 @@ intel_create_image(__DRIscreen *screen,
cpp = _mesa_get_format_bytes(image->format);

image->region =
-  intel_region_alloc(intelScreen, I915_TILING_X,
+  intel_region_alloc(intelScreen, tiling,
 cpp, width, height, GL_TRUE);
if (image->region == NULL) {
   FREE(image);
--
1.7.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] The current status of the gallium vmwgfx driver

2011-05-10 Thread HaiTao Feng

Dear Gallium Vmwgfx Developers,

Could I know the current status of the gallium vmwgfx driver? Is it able to
run Linux guest with OpenGL accelertion?

I want to try a Linux guest with gallium vmwgfx driver in Vmware player,
could you give me some instructions on how to build the kernel and mesa
source code?

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

[Mesa-dev] Mesa 7.11 devel fails on crosscompiling

2011-05-10 Thread Stephan Raue


Hi

Mesa 7.11 current git fails on crossompile between different archs (here 
i386 and x86_64) with generating the sources via python (output with 
enabled PYTHONVERBOSE). Tested with croscompiled Python build 
(hostpython) 2.6 and system installed python 2.7:


/home/stephan/projects/openelec-master/build.OpenELEC-test.x86_64-devel/toolchain/bin/x86_64-openelec-linux-gnu-gcc 
-I. -I../mesa -I../mapi -I../../include  -fPIC -march=atom -m64 
-fomit-frame-pointer -Wall -pipe -O3 -ffast-math 
-ftree-loop-distribution -floop-interchange -floop-strip-mine 
-floop-block -fgraphite-identity -fexcess-precision=fast  -mfpmath=sse 
-ftree-vectorize -mmovbe -Wall -Wmissing-prototypes -std=c99 -ffast-math 
-fno-strict-aliasing  -fPIC   -D_GNU_SOURCE -DPTHREADS 
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING 
-DHAVE_ALIAS  -DFEATURE_GL=1 -fvisibility=hidden  glcpp/glcpp-lex.o 
glcpp/glcpp-parse.o glcpp/pp.o ralloc.o glcpp/glcpp.o 
../mesa/program/hash_table.o -o glcpp/glcpp

Regenerating builtin_function.cpp...
/usr/bin/python -t -O -O builtins/tools/generate_builtins.py 
./builtin_compiler > builtin_function.cpp || rm -f builtin_function.cpp

# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /usr/lib/python2.7/site.pyo matches /usr/lib/python2.7/site.py
import site # precompiled from /usr/lib/python2.7/site.pyo
# /usr/lib/python2.7/os.pyo matches /usr/lib/python2.7/os.py
import os # precompiled from /usr/lib/python2.7/os.pyo
import errno # builtin
import posix # builtin
# /usr/lib/python2.7/posixpath.pyo matches /usr/lib/python2.7/posixpath.py
import posixpath # precompiled from /usr/lib/python2.7/posixpath.pyo
# /usr/lib/python2.7/stat.pyo matches /usr/lib/python2.7/stat.py
import stat # precompiled from /usr/lib/python2.7/stat.pyo
# /usr/lib/python2.7/genericpath.pyo matches 
/usr/lib/python2.7/genericpath.py

import genericpath # precompiled from /usr/lib/python2.7/genericpath.pyo
# /usr/lib/python2.7/warnings.pyo matches /usr/lib/python2.7/warnings.py
import warnings # precompiled from /usr/lib/python2.7/warnings.pyo
# /usr/lib/python2.7/linecache.pyo matches /usr/lib/python2.7/linecache.py
import linecache # precompiled from /usr/lib/python2.7/linecache.pyo
# /usr/lib/python2.7/types.pyo matches /usr/lib/python2.7/types.py
import types # precompiled from /usr/lib/python2.7/types.pyo
# /usr/lib/python2.7/UserDict.pyo matches /usr/lib/python2.7/UserDict.py
import UserDict # precompiled from /usr/lib/python2.7/UserDict.pyo
# /usr/lib/python2.7/_abcoll.pyo matches /usr/lib/python2.7/_abcoll.py
import _abcoll # precompiled from /usr/lib/python2.7/_abcoll.pyo
# /usr/lib/python2.7/abc.pyo matches /usr/lib/python2.7/abc.py
import abc # precompiled from /usr/lib/python2.7/abc.pyo
# /usr/lib/python2.7/_weakrefset.pyo matches 
/usr/lib/python2.7/_weakrefset.py

import _weakrefset # precompiled from /usr/lib/python2.7/_weakrefset.pyo
import _weakref # builtin
# /usr/lib/python2.7/copy_reg.pyo matches /usr/lib/python2.7/copy_reg.py
import copy_reg # precompiled from /usr/lib/python2.7/copy_reg.pyo
# /usr/lib/python2.7/sysconfig.pyo matches /usr/lib/python2.7/sysconfig.py
import sysconfig # precompiled from /usr/lib/python2.7/sysconfig.pyo
# /usr/lib/python2.7/re.pyo matches /usr/lib/python2.7/re.py
import re # precompiled from /usr/lib/python2.7/re.pyo
# /usr/lib/python2.7/sre_compile.pyo matches 
/usr/lib/python2.7/sre_compile.py

import sre_compile # precompiled from /usr/lib/python2.7/sre_compile.pyo
import _sre # builtin
# /usr/lib/python2.7/sre_parse.pyo matches /usr/lib/python2.7/sre_parse.py
import sre_parse # precompiled from /usr/lib/python2.7/sre_parse.pyo
# /usr/lib/python2.7/sre_constants.pyo matches 
/usr/lib/python2.7/sre_constants.py

import sre_constants # precompiled from /usr/lib/python2.7/sre_constants.pyo
# /usr/lib/python2.7/site-packages/abrt_exception_handler.pyo matches 
/usr/lib/python2.7/site-packages/abrt_exception_handler.py
import abrt_exception_handler # precompiled from 
/usr/lib/python2.7/site-packages/abrt_exception_handler.pyo

dlopen("/usr/lib/python2.7/lib-dynload/syslog.so", 2);
import syslog # dynamically loaded from 
/usr/lib/python2.7/lib-dynload/syslog.so

# /usr/lib/python2.7/socket.pyo matches /usr/lib/python2.7/socket.py
import socket # precompiled from /usr/lib/python2.7/socket.pyo
dlopen("/usr/lib/python2.7/lib-dynload/_socketmodule.so", 2);
import _socket # dynamically loaded from 
/usr/lib/python2.7/lib-dynload/_socketmodule.so

# /usr/lib/python2.7/functools.pyo matches /usr/lib/python2.7/functools.py
import functools # precompiled from /usr/lib/python2.7/functools.pyo
dlopen("/usr/lib/python2.7/lib-dynload/_functoolsmodule.so", 2);
import _functools # dynamically loaded from 
/usr/lib/python2.7/lib-dynload/_functoolsmodule.so

dlopen("/usr/lib/python2.7/lib-dynload/_ssl.so", 2);
import _ssl # dynamically loaded from /usr/lib/python2.7/lib-dynload/_ssl.so
dlopen("/usr/

Re: [Mesa-dev] [Intel-gfx] [PATCH] EGL: Add hardware cursor image format for EGL image extension.

2011-05-10 Thread Kristian Høgsberg

I implemented this just a few days ago:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=e5169e9615e8391ea369415b356168717b8f7be0

It's a new use flags instead of a new format, because, well, it's not
a new pixel format, but a restriction on how the buffers should be
allocated.

Kristian

On Tue, May 10, 2011 at 5:47 AM, zhigang gong  wrote:
>     Current EGL only support one drm buffer format which is
>     EGL_DRM_BUFFER_FORMAT_ARGB32_MESA. This
>     format works fine with normal image, but if we want to
>     create a drm buffer which will be used for a hardware cursor,
>     then it has problem. The default behaviou for this format is to
>     enable tiling for i915 driver. Thus it will choose 512 as the buffer's
>     stride. But the hardware cursor can only support 256 as the
>     row stride. To solve this problem, I create a new drm buffer
>     format named EGL_DRM_BUFFER_FORMAT_HWCURSOR_ARGB32_MESA
>     for hardware cursor usage. It will disable the tiling by default
>     for i915 driver and then choose 256 as its pitch value. I tested it on a
>     Sandy bridge platform, it works fine.
> ---
>  include/EGL/eglext.h                      |    1 +
>  include/GL/internal/dri_interface.h       |    1 +
>  src/egl/drivers/dri2/egl_dri2.c           |    3 +++
>  src/mesa/drivers/dri/intel/intel_screen.c |    7 +--
>  4 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
> index 9fd3eb8..d0153d3 100644
> --- a/include/EGL/eglext.h
> +++ b/include/EGL/eglext.h
> @@ -127,6 +127,7 @@ typedef EGLBoolean (EGLAPIENTRYP
> PFNEGLDESTROYIMAGEKHRPROC) (EGLDisplay dpy, EGL
>
>  /* EGL_DRM_BUFFER_FORMAT_MESA tokens */
>  #define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA      0x31D2
> +#define EGL_DRM_BUFFER_FORMAT_HWCURSOR_ARGB32_MESA 0x31D3
>
>  /* EGL_DRM_BUFFER_USE_MESA bits */
>  #define EGL_DRM_BUFFER_USE_SCANOUT_MESA                0x0001
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 2fb729a..fa2341b 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/interna
> @@ -127,6 +127,7 @@ typedef EGLBoolean (EGLAPIENTRYP
> PFNEGLDESTROYIMAGEKHRPROC) (EGLDisplay dpy, EGL
>
>  /* EGL_DRM_BUFFER_FORMAT_MESA tokens */
>  #define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA      0x31D2
> +#define EGL_DRM_BUFFER_FORMAT_HWCURSOR_ARGB32_MESA 0x31D3
>
>  /* EGL_DRM_BUFFER_USE_MESA bits */
>  #define EGL_DRM_BUFFER_USE_SCANOUT_MESA                0x0001
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 2fb729a..fa2341b 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -813,6 +813,7 @@ struct __DRIdri2ExtensionRec {
>  #define __DRI_IMAGE_FORMAT_RGB565       0x1001
>  #define __DRI_IMAGE_FORMAT_XRGB     0x1002
>  #define __DRI_IMAGE_FORMAT_ARGB     0x1003
> +#define __DRI_IMAGE_FORMAT_HWCURSOR_ARGB 0x1004
>
>  #define __DRI_IMAGE_USE_SHARE          0x0001
>  #define __DRI_IMAGE_USE_SCANOUT                0x0002
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 5e47fbe..23ab0ed 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1043,6 +1043,9 @@ dri2_create_drm_image_mesa(_EGLDriver *drv,
> _EGLDisplay *disp,
>    }
>
>    switch (attrs.DRMBufferFormatMESA) {
> +   case EGL_DRM_BUFFER_FORMAT_HWCURSOR_ARGB32_MESA:
> +      format = __DRI_IMAGE_FORMAT_HWCURSOR_ARGB;
> +      break;
>    case EGL_DRM_BUFFER_FORMAT_ARGB32_MESA:
>       format = __DRI_IMAGE_FORMAT_ARGB;
>       break;
> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> b/src/mesa/drivers/dri/intel/intel_screen.c
> index 7de0d12..475c142 100644
> --- a/src/mesa/drivers/dri/intel/intel_screen.c
> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> @@ -217,11 +217,12 @@ intel_create_image(__DRIscreen *screen,
>    __DRIimage *image;
>    struct intel_screen *intelScreen = screen->private;
>    int cpp;
> +   int tiling;
>
>    image = CALLOC(sizeof *image);
>    if (image == NULL)
>       return NULL;
> -
> +   tiling = I915_TILING_X;
>    switch (format) {
>    case __DRI_IMAGE_FORMAT_RGB565:
>       image->format = MESA_FORMAT_RGB565;
> @@ -233,6 +234,8 @@ intel_create_image(__DRIscreen *screen,
>       image->internal_format = GL_RGB;
>       image->data_type = GL_UNSIGNED_BYTE;
>       break;
> +   case __DRI_IMAGE_FORMAT_HWCURSOR_ARGB:
> +      tiling = I915_TILING_NONE;
>    case __DRI_IMAGE_FORMAT_ARGB:
>       image->format = MESA_FORMAT_ARGB;
>       image->internal_format = GL_RGBA;
> @@ -247,7 +250,7 @@ intel_create_image(__DRIscreen *screen,
>    cpp = _mesa_get_format_bytes(image->format);
>
>    image->region =
> -      intel_region_alloc(intelScreen, I915_TILING_X,
> +      intel_region_alloc(intelScreen, tiling,
>                         cpp, width, height, GL_TRUE);
>    if (image->region == NULL) {
>       FREE(image);
> --
> 1.7.3.1
>

[Mesa-dev] [Bug 36919] Yo Frankie: Crash in dst_register

2011-05-10 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=36919

--- Comment #12 from José Fonseca  2011-05-10 05:46:02 PDT 
---
I reproduced the bug here:

(gdb) bt
#0  0x7681aaa7 in _debug_assert_fail (expr=0x770285d7 "reg.File !=
TGSI_FILE_NULL", 
file=0x770285b0 "src/gallium/auxiliary/tgsi/tgsi_ureg.h", line=863,
function=0x77028c51 "ureg_writemask")
at src/gallium/auxiliary/util/u_debug.c:282
#1  0x76765607 in ureg_writemask (reg=..., writemask=7) at
src/gallium/auxiliary/tgsi/tgsi_ureg.h:863
#2  0x7677 in translate_dst (t=0x7fffc1d0, DstReg=0xd217f34,
saturate=0 '\000') at src/mesa/state_tracker/st_mesa_to_tgsi.c:310
#3  0x76767699 in compile_instruction (t=0x7fffc1d0,
inst=0xd217f18) at src/mesa/state_tracker/st_mesa_to_tgsi.c:673
#4  0x767691bb in st_translate_mesa_program (ctx=0xf444b0, procType=0,
ureg=0xf3ef2d0, program=0x111b7010, numInputs=2, 
inputMapping=0x7fffd3a0, inputSemanticName=0x7fffd4b0 "\001\003",
, inputSemanticIndex=0x7fffd490 "", 
interpMode=0x7fffd320, numOutputs=0, outputMapping=0x7fffd420,
outputSemanticName=0x7fffd470 "\002", 
outputSemanticIndex=0x7fffd450 "\240\324\377\377\377\177",
passthrough_edgeflags=0 '\000') at
src/mesa/state_tracker/st_mesa_to_tgsi.c:1230
#5  0x766a48c0 in st_translate_fragment_program (st=0xf94810,
stfp=0x111b7010, key=0x7fffd5a0) at src/mesa/state_tracker/st_program.c:609
#6  0x766a4a23 in st_get_fp_variant (st=0xf94810, stfp=0x111b7010,
key=0x7fffd5a0) at src/mesa/state_tracker/st_program.c:667
#7  0x7674dc6d in update_fp (st=0xf94810) at
src/mesa/state_tracker/st_atom_shader.c:86
#8  0x76749e05 in st_validate_state (st=0xf94810) at
src/mesa/state_tracker/st_atom.c:196
#9  0x767559ed in st_Clear (ctx=0xf444b0, mask=16) at
src/mesa/state_tracker/st_cb_clear.c:497
#10 0x766cb7df in _mesa_Clear (mask=256) at src/mesa/main/clear.c:250
#11 0x006fbd36 in KX_KetsjiEngine::RenderShadowBuffers(KX_Scene*) ()
#12 0x006fc1f3 in KX_KetsjiEngine::Render() ()
#13 0x0055ef12 in GPG_Application::processEvent(GHOST_IEvent*) ()
#14 0x0056be14 in GHOST_EventManager::dispatchEvent(GHOST_IEvent*) ()
#15 0x0056bd1d in GHOST_EventManager::dispatchEvent() ()
#16 0x0056bd6c in GHOST_EventManager::dispatchEvents() ()
#17 0x0056b548 in GHOST_System::dispatchEvents() ()
#18 0x0055d906 in main ()
(gdb) call _mesa_print_instruction(&program->Instructions[i])
LRP OUTPUT[2].xyz, TEMP[1]., TEMP[0], STATE[1];
(gdb) call _mesa_print_program(program)
# Fragment Program/Shader 0
  0: MAD_SAT TEMP[1].x, INPUT[3]., STATE[0]., STATE[0].;
  1: LRP OUTPUT[2].xyz, TEMP[1]., TEMP[0], STATE[1];
  2: MOV OUTPUT[2].w, TEMP[0];
  3: END
(gdb) 

The problem is that stfp->Base.Base.OutputsWritten is 0, which causes
st_translate_mesa_program() is receiving a bad numOutputs=0, and eventually the
assertion.


(gdb) p stfp->Base.Base.OutputsWritten
$18 = 0
(gdb) p stfp->Base.Base
$19 = {
  Id = 0, 
  String = 0x0, 
  RefCount = 3, 
  Target = 34820, 
  Format = 34933, 
  Resident = 1 '\001', 
  Instructions = 0xd217ed0, 
  InputsRead = 10, 
  OutputsWritten = 0, 
  SystemValuesRead = 0, 
  InputFlags = {0 }, 
  OutputFlags = {0 }, 
  TexturesUsed = {0 }, 
  SamplersUsed = 0, 
  ShadowSamplers = 0, 
  Parameters = 0xc8e2a90, 
  LocalParams = {{0, 0, 0, 0} }, 
  Varying = 0x0, 
  Attributes = 0x0, 
  SamplerUnits = "\000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017", 
  SamplerTargets = {TEXTURE_BUFFER_INDEX }, 
  IndirectRegisterFiles = 0, 
  NumInstructions = 4, 
  NumTemporaries = 2, 
  NumParameters = 0, 
  NumAttributes = 0, 
  NumAddressRegs = 0, 
  NumAluInstructions = 1, 
  NumTexInstructions = 0, 
  NumTexIndirections = 1, 
  NumNativeInstructions = 0, 
  NumNativeTemporaries = 0, 
  NumNativeParameters = 0, 
  NumNativeAttributes = 0, 
  NumNativeAddressRegs = 0, 
  NumNativeAluInstructions = 0, 
  NumNativeTexInstructions = 0, 
  NumNativeTexIndirections = 0
}

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Debugging crashes in llvm

2011-05-10 Thread Andreas Pokorny

Hi,

I recently stumbled over regular crashes with llvmpipe on llvm-2.9 in windows:

0261908D  mov ebx,dword ptr [esp+33Ch]
02619094  lea ebx,[ebx+3]
02619097  imulebx,edx
0261909A  add ebx,ecx
0261909C  insertpsxmm0,dword ptr [esi+ebx],30h  <--
026190A3  mov ecx,dword ptr [ebp+8]
026190A6  mov edx,dword ptr [ecx]
026190A8  movss   xmm2,dword ptr [edx+100h]

>   libEGL.dll!llvm_pipeline_generic(draw_pt_middle_end * 
> middle=0x, const draw_fetch_info * fetch_info=0x0006e828, const 
> draw_prim_info * prim_info=0x0006e838)  Line 262 + 0x12 bytes C
libEGL.dll!llvm_middle_end_linear_run(draw_pt_middle_end * middle=,
unsigned int start=, unsigned int count=, unsigned int prim_flags=)
Line 364 + 0x13 bytes   C
libEGL.dll!vsplit_run_linear(draw_pt_front_end *
frontend=0x03ff, unsigned int start=0, unsigned int count=150)
Line 61 + 0x11 bytesC
libEGL.dll!draw_pt_arrays(draw_context * draw=0x, unsigned
int prim=4, unsigned int start=0, unsigned int count=3)  Line 115   C
libEGL.dll!draw_vbo(draw_context * draw=0x, const
pipe_draw_info * info=0x)  Line 491 + 0x13 bytesC
libEGL.dll!llvmpipe_draw_vbo(pipe_context * pipe=0x021dc790, const
pipe_draw_info * info=0x0006e918)  Line 86  C
libEGL.dll!st_draw_vbo(gl_context * ctx=0x025a14b0, const
gl_client_array * * arrays=0x02661810, const _mesa_prim *
prims=0x0006e97c, unsigned int nr_prims=1, const _mesa_index_buffer *
ib=0x, unsigned char index_bounds_valid='', unsigned int
min_index=0, unsigned int max_index=149)  Line 750 + 0xf bytes  C
libEGL.dll!vbo_draw_arrays(gl_context * ctx=0x, unsigned int
mode=4, int start=0, int count=150, unsigned int numInstances=1)  Line
645 + 0x28 bytesC
libEGL.dll!vbo_exec_DrawArrays(unsigned int mode=4, int start=0, int
count=150)  Line 675 + 0x11 bytes   C
[...]

What Information can I gather to find the cause for the crash?



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

Re: [Mesa-dev] Debugging crashes in llvm

2011-05-10 Thread Jose Fonseca

It could be related with, https://bugs.freedesktop.org/show_bug.cgi?id=36738 , 
which I don't have much clue about ,given I wasn't able to reproduce locally so 
far.

It would be really useful if you could tell me the nature of the crash. Is it 
because 
- memory pointed by (esi+ebx) is undefined;
- memory pointed by (esi+ebx) is not 4-byte aligned

And then go up in the stack frame and inspect the pointers given in 
draw->pt.user and see which pointer (if any) is related with (esi+ebx).

Jose


- Original Message -
> Hi,
> 
> I recently stumbled over regular crashes with llvmpipe on llvm-2.9 in
> windows:
> 
> 0261908D  mov ebx,dword ptr [esp+33Ch]
> 02619094  lea ebx,[ebx+3]
> 02619097  imulebx,edx
> 0261909A  add ebx,ecx
> 0261909C  insertpsxmm0,dword ptr [esi+ebx],30h  <--
> 026190A3  mov ecx,dword ptr [ebp+8]
> 026190A6  mov edx,dword ptr [ecx]
> 026190A8  movss   xmm2,dword ptr [edx+100h]
> 
> > libEGL.dll!llvm_pipeline_generic(draw_pt_middle_end *
> > middle=0x, const draw_fetch_info * fetch_info=0x0006e828,
> > const draw_prim_info * prim_info=0x0006e838)  Line 262 + 0x12
> > bytes   C
>   libEGL.dll!llvm_middle_end_linear_run(draw_pt_middle_end * middle=,
> unsigned int start=, unsigned int count=, unsigned int prim_flags=)
> Line 364 + 0x13 bytes C
>   libEGL.dll!vsplit_run_linear(draw_pt_front_end *
> frontend=0x03ff, unsigned int start=0, unsigned int count=150)
> Line 61 + 0x11 bytes  C
>   libEGL.dll!draw_pt_arrays(draw_context * draw=0x, unsigned
> int prim=4, unsigned int start=0, unsigned int count=3)  Line 115 C
>   libEGL.dll!draw_vbo(draw_context * draw=0x, const
> pipe_draw_info * info=0x)  Line 491 + 0x13 bytes  C
>   libEGL.dll!llvmpipe_draw_vbo(pipe_context * pipe=0x021dc790, const
> pipe_draw_info * info=0x0006e918)  Line 86C
>   libEGL.dll!st_draw_vbo(gl_context * ctx=0x025a14b0, const
> gl_client_array * * arrays=0x02661810, const _mesa_prim *
> prims=0x0006e97c, unsigned int nr_prims=1, const _mesa_index_buffer *
> ib=0x, unsigned char index_bounds_valid='', unsigned int
> min_index=0, unsigned int max_index=149)  Line 750 + 0xf bytesC
>   libEGL.dll!vbo_draw_arrays(gl_context * ctx=0x, unsigned
>   int
> mode=4, int start=0, int count=150, unsigned int numInstances=1)
>  Line
> 645 + 0x28 bytes  C
>   libEGL.dll!vbo_exec_DrawArrays(unsigned int mode=4, int start=0,
>   int
> count=150)  Line 675 + 0x11 bytes C
> [...]
> 
> What Information can I gather to find the cause for the crash?
> 
> 
> 
> Regards
> Andreas Pokorny
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

2011-05-10 Thread Jesse Barnes

On Tue, 10 May 2011 10:46:17 +0200
Michel Dänzer  wrote:

> On Fre, 2011-05-06 at 14:01 -0700, Jesse Barnes wrote: 
> > On Fri, 6 May 2011 13:00:19 -0700
> > Jeremy Huddleston  wrote:
> > 
> > > Yeah, that looks about right.
> > > 
> > > This in combination with the latest version of "xserver/glx/dri2: use new 
> > > GLX/DRI2 swap event types"
> > > 
> > > Reviewed-by: Jeremy Huddleston 
> > 
> > Ok here's a more complete patch.  It touches GLX and involves drawable
> > lifetimes, which I'm not that familiar with, so careful review
> > appreciated.  Note the X vs GLX drawable ID switching in the DRI2 event
> > handler (DRI2 just deals with X IDs).
> > 
> > Kristian and Jeremy, is this a good basis for moving the Apple stuff
> > over to a client GLX drawable type?
> > 
> > -- 
> > Jesse Barnes, Intel Open Source Technology Center
> > 
> > From fae63609dd4fd20ccd84d2211787136bb9a1da05 Mon Sep 17 00:00:00 2001
> > From: Jesse Barnes 
> > Date: Fri, 6 May 2011 10:31:24 -0700
> > Subject: [PATCH] GLX/DRI2: handle swap event swap count wrapping
> > 
> > Create a new GLX drawable struct to track client related info, and add a
> > wrap counter to it drawable and track it as we receive events.  This
> > allows us to support the full 64 bits of the event structure we pass to
> > the client even though the server only gives us a 32 bit count.
> > 
> > Signed-off-by: Jesse Barnes 
> 
> [...]
> 
> > @@ -582,6 +584,14 @@ struct glx_display
> >  #endif
> >  };
> >  
> > +struct glx_drawable {
> > +   XID xDrawable;
> > +   XID drawable;
> > +
> > +   uint32_t lastEventSbc;
> > +   int64_t eventSbcWrap;
> 
> Shouldn't eventSbcWrap be unsigned?

The aevent sbc field is signed, so I thought I'd match it.  Making it
unsigned should be fine though too; client already have to check for
wraparound on this value.

> > diff --git a/src/glx/glxext.c b/src/glx/glxext.c
> > index 02652cb..03c05a3 100644
> > --- a/src/glx/glxext.c
> > +++ b/src/glx/glxext.c
> > @@ -106,7 +106,7 @@ XEXT_GENERATE_ERROR_STRING(__glXErrorString, 
> > __glXExtensionName,
> >  static Bool
> >  __glXWireToEvent(Display *dpy, XEvent *event, xEvent *wire)
> >  {
> > - struct glx_display *glx_dpy = __glXInitialize(dpy);
> > +   struct glx_display *glx_dpy = __glXInitialize(dpy);
> >  
> > if (glx_dpy == NULL)
> >return False;
> 
> Superfluous whitespace-only change.

Yeah I couldn't resist.  I'll push that separately.

> Looks good to me otherwise, but I'm not really familiar with the
> client-side GLX drawable lifetime either.

Ok, I'll double check things; I think it's ok since the new struct
matches the DRI drawable lifetime, but I'll look at those paths again
and make sure I haven't missed something.

Now anyone care to test?

-- 
Jesse Barnes, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dri2proto: add new DRI2BufferSwapComplete struct to match spec

2011-05-10 Thread Eric Anholt

On Thu, 5 May 2011 12:42:43 -0700, Jesse Barnes  
wrote:
> Just add a new struct to remain compatible with existing code.

Reviewed-by: Eric Anholt 


pgpc9QplGmPSu.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec

2011-05-10 Thread Eric Anholt

On Thu, 5 May 2011 12:39:57 -0700, Jesse Barnes  
wrote:
> Just add a new struct to remain compatible with existing code.
> 
> Signed-off-by: Jesse Barnes 
> 
> diff --git a/configure.ac b/configure.ac
> index a3047e4..a6c301c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1,5 +1,5 @@
>  AC_PREREQ([2.60])
> -AC_INIT([GLProto], [1.4.13], 
> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> +AC_INIT([GLProto], [1.4.14], 
> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
>  AM_INIT_AUTOMAKE([foreign dist-bzip2])
>  AM_MAINTAINER_MODE
>  
> diff --git a/glxproto.h b/glxproto.h
> index dfa0647..3f9e837 100644
> --- a/glxproto.h
> +++ b/glxproto.h
> @@ -1375,6 +1375,20 @@ typedef struct {
>  BYTE pad;
>  CARD16 sequenceNumber B16;
>  CARD16 event_type B16;

While this is the compat structure, I'd still like to see the padding
explicit so I don't worry about it when reading the code ever again.

> +CARD32 drawable;
> +CARD32 ust_hi B32;
> +CARD32 ust_lo B32;
> +CARD32 msc_hi B32;
> +CARD32 msc_lo B32;
> +CARD32 sbc_hi B32;
> +CARD32 sbc_lo B32;
> +} xGLXBufferSwapComplete;


pgpZYZ443xFVe.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 36738] Openarena crash with r300g, swrastg + llvm > 2.8

2011-05-10 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=36738

--- Comment #16 from Iaroslav  2011-05-10 12:11:10 PDT ---
I made two livecd 32 bit and 64 bit with a similar gdb,llvm and mesa packages,
xscreenserver and libs for run openarena from hdd.
32-bit 400 mb
http://susestudio.com/download/99d3c4cd9b6f3054a99c7ec79c6f360a/bug_36738.i686-0.0.5.iso
64-bit 400 mb
http://susestudio.com/download/5c3fbfc8859b961cc40591537446a89a/bug_36738.x86_64-0.0.4.iso

user  - bug 
password - empty

some result on my notebook
32 bit
r300g - xsreenserver/crackberg  show ~1-2 fps and segfault after 2-5 seconds.
llvmpipe - xsreenserver/crackberg fps is good, run without segfault.
r300g - openarena segfault when load map.
llvmpipe openarena segfault when load map.

64-bit
r300g - xsreenserver/crackberg  fps is good, sometimes reduced to 1 fps and
segfault after 6-20 seconds.
llvmpipe - xsreenserver/crackberg fps is good, run without segfault.
300g - openarena work fine
llvmpipe openarena work fine

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec

2011-05-10 Thread Jesse Barnes

On Tue, 10 May 2011 11:59:56 -0700
Eric Anholt  wrote:

> On Thu, 5 May 2011 12:39:57 -0700, Jesse Barnes  
> wrote:
> > Just add a new struct to remain compatible with existing code.
> > 
> > Signed-off-by: Jesse Barnes 
> > 
> > diff --git a/configure.ac b/configure.ac
> > index a3047e4..a6c301c 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -1,5 +1,5 @@
> >  AC_PREREQ([2.60])
> > -AC_INIT([GLProto], [1.4.13], 
> > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> > +AC_INIT([GLProto], [1.4.14], 
> > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> >  AM_INIT_AUTOMAKE([foreign dist-bzip2])
> >  AM_MAINTAINER_MODE
> >  
> > diff --git a/glxproto.h b/glxproto.h
> > index dfa0647..3f9e837 100644
> > --- a/glxproto.h
> > +++ b/glxproto.h
> > @@ -1375,6 +1375,20 @@ typedef struct {
> >  BYTE pad;
> >  CARD16 sequenceNumber B16;
> >  CARD16 event_type B16;
> 
> While this is the compat structure, I'd still like to see the padding
> explicit so I don't worry about it when reading the code ever again.

Ok, wanna push your existing patch for that or should I push it with
this stuff?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)

2011-05-10 Thread Christian König

Am Montag, den 09.05.2011, 20:04 +0100 schrieb Andy Furniss:
> Andy Furniss wrote:
> 
> > dd6cd206a6395be651bc965580e17c0d63513c7b
> >
> > [g3dvl] correctly implement non power of two buffers
> >
> > regresses rendering on my RV670.
Very interesting, sounds like a bug in the shader compiler for R6xx, but
this is not prio one on my todo list.

> I see with the weekend changes and master merge that the "new" xvmc 
> artifacts on my rv790 are now gone without patching.
Yes Alex patches combined with mine seems to indeed work right.

> mplayer vanilla is working and vdpau perf is much better.
Except for subpictures, a couple of crashes and a bunch of other still
open problems...

> On my rv790 there are still vdpau decode artifacts that don't show with 
> xvmc -
I tried to compare the shader input and output between xvmc and vdpau
for the last couple of days now, but still haven't found all the bugs
yet, but this should just be a matter of time.

> My rv670 is still suffering quite different problems both xvmc and vdpau -
Please try the following patch with xvmc:
--- a/src/gallium/drivers/r600/r600_video_context.c
+++ b/src/gallium/drivers/r600/r600_video_context.c
@@ -40,5 +40,5 @@ r600_video_create(struct pipe_screen *screen, void
*priv)
if (!pipe)
   return NULL;
 
-   return vl_create_context(pipe, false);
+   return vl_create_context(pipe, true);
 }

It won't work with vdpau, because it probably causes a buffer overflow
and/or crash right now.

Christian.

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

Re: [Mesa-dev] [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec

2011-05-10 Thread Eric Anholt

On Tue, 10 May 2011 12:32:24 -0700, Jesse Barnes  
wrote:
> On Tue, 10 May 2011 11:59:56 -0700
> Eric Anholt  wrote:
> 
> > On Thu, 5 May 2011 12:39:57 -0700, Jesse Barnes  
> > wrote:
> > > Just add a new struct to remain compatible with existing code.
> > > 
> > > Signed-off-by: Jesse Barnes 
> > > 
> > > diff --git a/configure.ac b/configure.ac
> > > index a3047e4..a6c301c 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -1,5 +1,5 @@
> > >  AC_PREREQ([2.60])
> > > -AC_INIT([GLProto], [1.4.13], 
> > > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> > > +AC_INIT([GLProto], [1.4.14], 
> > > [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> > >  AM_INIT_AUTOMAKE([foreign dist-bzip2])
> > >  AM_MAINTAINER_MODE
> > >  
> > > diff --git a/glxproto.h b/glxproto.h
> > > index dfa0647..3f9e837 100644
> > > --- a/glxproto.h
> > > +++ b/glxproto.h
> > > @@ -1375,6 +1375,20 @@ typedef struct {
> > >  BYTE pad;
> > >  CARD16 sequenceNumber B16;
> > >  CARD16 event_type B16;
> > 
> > While this is the compat structure, I'd still like to see the padding
> > explicit so I don't worry about it when reading the code ever again.
> 
> Ok, wanna push your existing patch for that or should I push it with
> this stuff?

Meh, just push it with your stuff.


pgpBCpD5ggZQH.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r600g: delay mapping until first map request.

2011-05-10 Thread Dave Airlie

From: Dave Airlie 

Currently r600g always maps every bo, this is quite pointless as it wastes
VM and on 32-bit with wine running VM space is quite useful.

So with this patch we don't create the mappings until first use, without
tiling enabled this probably won't make a major difference on its own,
but with tiled staged uploads it should avoid keeping maps for most of the
textures unnecessarily.

Signed-off-by: Dave Airlie 
---
 src/gallium/winsys/r600/drm/r600_priv.h |3 +++
 src/gallium/winsys/r600/drm/radeon_bo.c |7 +--
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/src/gallium/winsys/r600/drm/r600_priv.h 
b/src/gallium/winsys/r600/drm/r600_priv.h
index f8363f9..33cca45 100644
--- a/src/gallium/winsys/r600/drm/r600_priv.h
+++ b/src/gallium/winsys/r600/drm/r600_priv.h
@@ -145,6 +145,7 @@ int radeon_bo_get_tiling_flags(struct radeon *radeon,
 int radeon_bo_get_name(struct radeon *radeon,
   struct radeon_bo *bo,
   uint32_t *name);
+int radeon_bo_fixed_map(struct radeon *radeon, struct radeon_bo *bo);
 
 /*
  * r600_hw_context.c
@@ -192,6 +193,8 @@ struct r600_bo *r600_bomgr_bo_create(struct r600_bomgr *mgr,
  */
 static inline int radeon_bo_map(struct radeon *radeon, struct radeon_bo *bo)
 {
+   if (bo->map_count == 0)
+   return radeon_bo_fixed_map(radeon, bo);
bo->map_count++;
return 0;
 }
diff --git a/src/gallium/winsys/r600/drm/radeon_bo.c 
b/src/gallium/winsys/r600/drm/radeon_bo.c
index 13b1d50..9a534dd 100644
--- a/src/gallium/winsys/r600/drm/radeon_bo.c
+++ b/src/gallium/winsys/r600/drm/radeon_bo.c
@@ -33,7 +33,7 @@
 #include "xf86drm.h"
 #include "radeon_drm.h"
 
-static int radeon_bo_fixed_map(struct radeon *radeon, struct radeon_bo *bo)
+int radeon_bo_fixed_map(struct radeon *radeon, struct radeon_bo *bo)
 {
struct drm_radeon_gem_mmap args;
void *ptr;
@@ -127,11 +127,6 @@ struct radeon_bo *radeon_bo(struct radeon *radeon, 
unsigned handle,
return NULL;
}
}
-   if (radeon_bo_fixed_map(radeon, bo)) {
-   R600_ERR("failed to map bo\n");
-   radeon_bo_reference(radeon, &bo, NULL);
-   return bo;
-   }
 
if (handle)
util_hash_table_set(radeon->bo_handles, (void 
*)(uintptr_t)handle, bo);
-- 
1.7.5.1

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

[Mesa-dev] threads and X.org/AIGLX drivers

2011-05-10 Thread Dave Airlie

Hey,

So we got a bug reported against F15 where we were getting an illegal
input event type 0, after passing it around the RH X team I eventually
came to look at it.

The problem appears to be that we are using llvmpipe as our swrast
renderer and on systems that fallback to that we end up with threads
inside the X server, that we didn't spawn. It appears SIGIO gets
delivered to one of these threads while the main thread keeps on
trucking and fail ensues.

So I'm crossposting this as there are two fixes we can do that aren't
exclusive but could act as belt and braces on Linux at least (other
OSes get the belt only).

Fix 1: use F_SETOWN_EX, thank to DrNick and AaronP on irc for digging
up this nugget, "From  Linux  2.6.32 onwards, use F_SETOWN_EX to
target SIGIO
and SIGURG signals at a particular thread.". So on
Linux we would use that instead of F_SETOWN to make sure SIGIO only
goes to the main X process/thread. Though I'm not sure how to get the
defintion for gettid which we need, though I'll look into this a bit
more.

Fix 2: block all signals in the gallium thread spawning code, this
involves using pthread_sigmask around the pthread_create function.
Calling it once with a full set of signals to block, and get a copy of
the current signals, then calling it again to put back the current
signals. I think this might be a good plan for some other things, as I
can't see a good reason for a DRI driver to ever get SIGIO, esp as it
may interfere with the parent app.

I've built a test package with 2 in it for Fedora and am awaiting
feedback from the tester, but just though I'd raise the subject here
for some discussion/feedback.

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

Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

[Mesa-dev] [PATCH] EGL: Add hardware cursor image format for EGL image extension.

[Mesa-dev] The current status of the gallium vmwgfx driver

[Mesa-dev] Mesa 7.11 devel fails on crosscompiling

Re: [Mesa-dev] [Intel-gfx] [PATCH] EGL: Add hardware cursor image format for EGL image extension.

[Mesa-dev] [Bug 36919] Yo Frankie: Crash in dst_register

[Mesa-dev] Debugging crashes in llvm

Re: [Mesa-dev] Debugging crashes in llvm

Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

Re: [Mesa-dev] [PATCH] dri2proto: add new DRI2BufferSwapComplete struct to match spec

Re: [Mesa-dev] [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec

[Mesa-dev] [Bug 36738] Openarena crash with r300g, swrastg + llvm > 2.8

Re: [Mesa-dev] [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec

Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)

Re: [Mesa-dev] [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec

[Mesa-dev] [PATCH] r600g: delay mapping until first map request.

[Mesa-dev] threads and X.org/AIGLX drivers

17 matches

Site Navigation

Mail list logo

Footer information