date:20110711

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

--- Comment #9 from Jonathan Kirkham jonathan.kirk...@arm.com 2011-07-11 
00:55:03 PDT ---
(In reply to comment #8)
 (In reply to comment #7)
  The attributes are valid for glxChooseFBConfig, the attributes and their 
  values
  are just ignore by it.
  
  Returning NULL in choose_visual causes glxConfigFBConfig to also return NULL
  which is incorrect, it should return the list of valid configs. Passing in
  these ignored attributes should not alter the configs returned by
  glxChooseFBConfig.
 
 Note that the 'fbConfig' var indicates if the caller is glXChooseFBConfig or
 glXChooseVisual.  The attributes in question are only valid for the former, 
 not
 the later.

Ahh, my mistake, apologies.

This looks good to me then.

Thanks

Jon

-- 
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 00/13] Floating-point depth buffers

It should be fixed by now. There is a bug in our beloved build system
such that the assert macro is disabled if some completely-unrelated
configure options are enabled. I will send a fix for that soon as
well.

Marek

On Mon, Jul 11, 2011 at 5:00 AM, Eric Anholt e...@anholt.net wrote:
 On Fri,  1 Jul 2011 02:29:32 +0200, Marek Olšák mar...@gmail.com wrote:
 Hi,

 this patch series implements ARB_depth_buffer_float in Mesa and Gallium. 
 There is complete r600g/r600-r700 support in my private branch, which passes 
 the same tests that pass for Z24S8. Softpipe has only sampler support. This 
 has turned out to be not so trivial, so it's possible I missed something.

 I did not implement NV_depth_buffer_float, because it's not compatible with 
 the ARB variant. (GL_DEPTH_COMPONENT32F != GL_DEPTH_COMPONENT32F_NV etc.) 
 The NV extension can operate on unclamped depth values, whereas the ARB one 
 always clamps them.

 My mesa is now crashing on startup with:

 glxgears: main/formats.c:1488: _mesa_test_formats: Assertion
 `info-DataType == 0x8C17 || info-DataType == 0x8F9C || info-DataType
 == 0x1405 || info-DataType == 0x1404 || info-DataType == 0x1406'
 failed.

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

Re: [Mesa-dev] Mesa (master): mesa: fix assertion failure in _mesa_test_formats

2011-07-11 Thread Jose Fonseca

Marek,

Please add the comment /* Z32_FLOAT_X24S8 has DataType of GL_NONE */ in from of 
DataType == GL_NONE, otherwise I think nobody will guess what that's about.

Jose

- Original Message -
 Module: Mesa
 Branch: master
 Commit: e134eaa2c5619b47e944e33d053ee23c61da7aa9
 URL:

 http://cgit.freedesktop.org/mesa/mesa/commit/?id=e134eaa2c5619b47e944e33d053ee23c61da7aa9
 
 Author: Marek Olšák mar...@gmail.com
 Date:   Mon Jul 11 13:53:42 2011 +0200
 
 mesa: fix assertion failure in _mesa_test_formats
 
 Z32_FLOAT_X24S8 has DataType of GL_NONE.
 
 ---
 
  src/mesa/main/formats.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
 index f58b197..e01ea11 100644
 --- a/src/mesa/main/formats.c
 +++ b/src/mesa/main/formats.c
 @@ -1485,7 +1485,8 @@ _mesa_test_formats(void)
   info-DataType == GL_SIGNED_NORMALIZED ||
   info-DataType == GL_UNSIGNED_INT ||
   info-DataType == GL_INT ||
 - info-DataType == GL_FLOAT);
 + info-DataType == GL_FLOAT ||
 + info-DataType == GL_NONE);
  
if (info-BaseFormat == GL_RGB) {
   assert(info-RedBits  0);
 
 ___
 mesa-commit mailing list
 mesa-com...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-commit
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): mesa: fix assertion failure in _mesa_test_formats

Done.

Marek

On Mon, Jul 11, 2011 at 3:14 PM, Jose Fonseca jfons...@vmware.com wrote:
 Marek,

 Please add the comment /* Z32_FLOAT_X24S8 has DataType of GL_NONE */ in from 
 of DataType == GL_NONE, otherwise I think nobody will guess what that's about.

 Jose

 - Original Message -
 Module: Mesa
 Branch: master
 Commit: e134eaa2c5619b47e944e33d053ee23c61da7aa9
 URL:
    
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=e134eaa2c5619b47e944e33d053ee23c61da7aa9

 Author: Marek Olšák mar...@gmail.com
 Date:   Mon Jul 11 13:53:42 2011 +0200

 mesa: fix assertion failure in _mesa_test_formats

 Z32_FLOAT_X24S8 has DataType of GL_NONE.

 ---

  src/mesa/main/formats.c |    3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

 diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
 index f58b197..e01ea11 100644
 --- a/src/mesa/main/formats.c
 +++ b/src/mesa/main/formats.c
 @@ -1485,7 +1485,8 @@ _mesa_test_formats(void)
               info-DataType == GL_SIGNED_NORMALIZED ||
               info-DataType == GL_UNSIGNED_INT ||
               info-DataType == GL_INT ||
 -             info-DataType == GL_FLOAT);
 +             info-DataType == GL_FLOAT ||
 +             info-DataType == GL_NONE);

        if (info-BaseFormat == GL_RGB) {
           assert(info-RedBits  0);

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

 ___
 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 1/2] mesa: return early if mask is cleared to zero in BlitFramebuffer


On 07/10/2011 12:30 PM, Marek Olšák wrote:

 From ARB_framebuffer_object:
 If a buffer is specified inmask  and does not exist in both the
 read and draw framebuffers, the corresponding bit is silently
 ignored.
---
  src/mesa/main/fbobject.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index d094dd3..8496936 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2603,6 +2603,10 @@ _mesa_BlitFramebufferEXT(GLint srcX0, GLint srcY0, GLint 
srcX1, GLint srcY1,
}
 }

+   if (!mask) {
+  return;
+   }
+
 ASSERT(ctx-Driver.BlitFramebuffer);
 ctx-Driver.BlitFramebuffer(ctx,
 srcX0, srcY0, srcX1, srcY1,


Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: Check after _mesa_create_context()


On 07/09/2011 06:56 AM, Emil Velikov wrote:

In some cases _mesa_create_context() can return NULL
an in the mesa state tracker, we do not concider the
case, which may cause issues within st_create_context_priv()

This patch adds a simple check (similar to the one in the
dri drivers), as well as clears the function table 'funcs'

Signed-off-by: Emil Velikovemil.l.veli...@gmail.com
---
  src/mesa/state_tracker/st_context.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index 6eddbfc..d021d64 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -179,6 +179,10 @@ struct st_context *st_create_context(gl_api api, struct 
pipe_context *pipe,
 st_init_driver_functions(funcs);

 ctx = _mesa_create_context(api, visual, shareCtx,funcs, NULL);
+   if (!ctx) {
+  memset(funcs, 0, sizeof(funcs));
+  return NULL;
+   }

 /* XXX: need a capability bit in gallium to query if the pipe
  * driver prefers DP4 or MUL/MAD for vertex transformation.


I don't see the need to zero-out the funcs table.
Otherwise, looks good.

-Brian

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

[Mesa-dev] [Bug 38842] Various valid GLX attributes are rejected by MESA glxChooseFBConfig

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

Brian Paul bri...@vmware.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Brian Paul bri...@vmware.com 2011-07-11 07:04:24 PDT ---
Patch committed (d60880db35fd11d9348ce4b2bfbcc9325d2ebf91).  I'll put this into
7.11 too.

-- 
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] configure.ac: do not let LLVM_CONFIG to define NDEBUG and disable assertions

2011-07-11 Thread Jose Fonseca

Looks good. But this would be more correct:

  llvm-config --cppflags | sed 's/-DNDEBUG\//g'

I'll do the same thing in scons. 

Jose

- Original Message -
 Re-enables assertions in src/mesa.
 ---
  configure.ac |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index dde13c9..84710ed 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1806,7 +1806,7 @@ fi
  if test x$enable_gallium_llvm = xyes; then
  if test x$LLVM_CONFIG != xno; then
   LLVM_VERSION=`$LLVM_CONFIG --version`
 - LLVM_CFLAGS=`$LLVM_CONFIG --cppflags`
 + LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed s/-DNDEBUG//g`
   LLVM_LIBS=`$LLVM_CONFIG --libs` -lstdc++
  
   LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
 --
 1.7.4.1
 
 ___
 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

[Mesa-dev] [Bug 39116] [intel] manywin xdemo texture issue

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

Brian Paul bri...@vmware.com changed:

   What|Removed |Added

Summary|manywin xdemo texture issue |[intel] manywin xdemo
   ||texture issue

--- Comment #1 from Brian Paul bri...@vmware.com 2011-07-11 07:07:38 PDT ---
Mabye an issue with texture sharing among contexts.

-- 
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] robust-tarballs branch (Was: Error building on Windows with SCons)


On 07/09/2011 07:03 AM, Jose Fonseca wrote:

I heard no concerns so I went ahead and made a branch where:
- I removed GLUT
- derived Mesa tarballs' file list from git ls-files.

http://cgit.freedesktop.org/mesa/mesa/log/?h=robust-tarballs

I've confirmed that both automake and scons+crossmingw32 build correctly on 
Linux.

I'd like to merge to main if there are no objections.

Concerning GLUT, we can make a separate branch/repos with just its source code 
if anybody sees value on it. ?


Yes, I'd definitely like to see a new repo for glut.  I still prefer 
it over freeglut.


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

[Mesa-dev] [PATCH] autoconf: Do not select Xlib when building DRI

2011-07-11 Thread Emil Velikov

As Chia-I Wu said 'There are two libGL providers, Xlib and DRI based
they cannot coexist'

Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
 configure.ac |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index dde13c9..19cc531 100644
--- a/configure.ac
+++ b/configure.ac
@@ -791,7 +791,7 @@ esac
 if test x$enable_dri = xyes; then
 DRIVER_DIRS=$DRIVER_DIRS dri
 
-GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/xlib sw/dri
+GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/dri
 GALLIUM_STATE_TRACKERS_DIRS=dri $GALLIUM_STATE_TRACKERS_DIRS
 HAVE_ST_DRI=yes
 fi
-- 
1.7.6

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

[Mesa-dev] About merging pipe-video to master

2011-07-11 Thread Christian König

Hi guys,

as the subject already indicates: I'm about to merge pipe-video to
master and just wanted to ask if anybody has still any objections?

After following Jose and Younes discussion on mesa-dev about how to
design such an abstraction layer I took another round of cleaning up the
interface and moved some more parts into the state tracker.

So the interface between the state tracker and drivers only consist of
the following now:

1. two additional functions for the screen object: get_video_param and
is_video_format_supported. get_video_param gets a parameter for a
specified codec (like max width/height of decoding target, which could
be smaller than texture max width/height), and is_video_format_supported
which checks if a texture format is supported as a decoding target for a
codec.

2. create_video_decoder function in the pipe_context object, which
creates a decoder object for a given codec. The decoder object in turn
includes everything needed to decode a video stream of that codec and
uses pipe_video_decode_buffer objects to hold the input data of a single
frame of that video codec.

3. create_video_buffer function in the pipe_context object, which
creates a video_buffer object to store a decoded video frame. This
video_buffer object is then used for both rendering to the screen with
normal pipe_context functionality and also as the input for reference
frames back to the decoder.

The pipe_video_buffer object is there because I think hardware decoders
need some special memory layout of the different planes of a yuv buffer.
There is a standard implementation that just uses normal textures as the
different planes for yuv buffer, which can be used by a driver when
there is no need for a special memory layout or when the driver just
uses shader based decoding.

The other option would be adding a PIPE_BIND_VIDEO_BUFFER flag to the
resource creation functions, but I don't want to repeat functionality in
the different drivers and as far as I can see the current resource
functions (samplers/surfaces) can't be used to create a surface for just
one plane/component of a yuv buffer and we could still clean that up to
use the standard resource functions if the need arise.

Everything else, especially the vl_compositor functionality, is now part
of the state tracker instead of the driver. The interface was mostly
designed keeping two things in mind: First it should abstract the
functionality of hardware video decoding from the state tracker and
second it should be possible to implement a wide variety of different
video decoding apis with it. For the second part I checked that it's at
least possible to do XvMC,VDPAU,VAAPI and DXVA with it.

So what do you guys think about it?

Regards,
Christian.

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

[Mesa-dev] [Bug 39147] New: egl_gallium.so: errors when linking

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

   Summary: egl_gallium.so: errors when linking
   Product: Mesa
   Version: git
  Platform: All
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: lordhea...@gmail.com


When trying to build egl driver under ArchLinux, there is erros while linking:

---8---
make[3]: Leaving directory
`/build/src/mesa-b033f050fd5179b051181a0a4b6d94110624d25c/src/gallium/winsys/nouveau/drm'
make[2]: Leaving directory
`/build/src/mesa-b033f050fd5179b051181a0a4b6d94110624d25c/src/gallium/winsys'
make[2]: Entering directory
`/build/src/mesa-b033f050fd5179b051181a0a4b6d94110624d25c/src/gallium/targets'
make[3]: Entering directory
`/build/src/mesa-b033f050fd5179b051181a0a4b6d94110624d25c/src/gallium/targets/egl-static'
gcc -c -o egl.o egl.c -DFEATURE_ES1=1 -DFEATURE_ES2=1 -DFEATURE_GL=1
-DGALLIUM_RBUG -DGALLIUM_SOFTPIPE -DGALLIUM_TRACE -D_EGL_EXTERNAL_GL=1
-D_EGL_MAIN=_eglMain -D_EGL_PIPE_NOUVEAU=1 -D_EGL_PIPE_R300=1
-D_EGL_PIPE_R600=1 -I../../../../include -I../../../../src/egl/main
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I../../../../src/gallium/include -I../../../../src/gallium/state_trackers/egl
-I../../../../src/gallium/winsys -I../../../../src/mesa -I/usr/include/libdrm
-DGALLIUM_LLVMPIPE -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBUDEV -DHAVE_XCB_DRI2
-DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -march=x86-64 -mtune=generic -O2
-pipe -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing
-fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBUDEV -DHAVE_XCB_DRI2
-DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
gcc -c -o egl_pipe.o egl_pipe.c -DFEATURE_ES1=1 -DFEATURE_ES2=1 -DFEATURE_GL=1
-DGALLIUM_RBUG -DGALLIUM_SOFTPIPE -DGALLIUM_TRACE -D_EGL_EXTERNAL_GL=1
-D_EGL_MAIN=_eglMain -D_EGL_PIPE_NOUVEAU=1 -D_EGL_PIPE_R300=1
-D_EGL_PIPE_R600=1 -I../../../../include -I../../../../src/egl/main
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I../../../../src/gallium/include -I../../../../src/gallium/state_trackers/egl
-I../../../../src/gallium/winsys -I../../../../src/mesa -I/usr/include/libdrm
-DGALLIUM_LLVMPIPE -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBUDEV -DHAVE_XCB_DRI2
-DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -march=x86-64 -mtune=generic -O2
-pipe -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing
-fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBUDEV -DHAVE_XCB_DRI2
-DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
gcc -c -o egl_st.o egl_st.c -DFEATURE_ES1=1 -DFEATURE_ES2=1 -DFEATURE_GL=1
-DGALLIUM_RBUG -DGALLIUM_SOFTPIPE -DGALLIUM_TRACE -D_EGL_EXTERNAL_GL=1
-D_EGL_MAIN=_eglMain -D_EGL_PIPE_NOUVEAU=1 -D_EGL_PIPE_R300=1
-D_EGL_PIPE_R600=1 -I../../../../include -I../../../../src/egl/main
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I../../../../src/gallium/include -I../../../../src/gallium/state_trackers/egl
-I../../../../src/gallium/winsys -I../../../../src/mesa -I/usr/include/libdrm
-DGALLIUM_LLVMPIPE -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBUDEV -DHAVE_XCB_DRI2
-DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -march=x86-64 -mtune=generic -O2
-pipe -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing
-fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBUDEV -DHAVE_XCB_DRI2
-DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209

[Mesa-dev] [Bug 39147] egl_gallium.so: errors when linking

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

Laurent carlier lordhea...@gmail.com changed:

   What|Removed |Added

 CC||lordhea...@gmail.com

-- 
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] robust-tarballs branch (Was: Error building on Windows with SCons)

2011-07-11 Thread Dave Airlie

On Mon, Jul 11, 2011 at 3:20 PM, Jose Fonseca jfons...@vmware.com wrote:
 - Original Message -
 On 07/09/2011 07:03 AM, Jose Fonseca wrote:
  I heard no concerns so I went ahead and made a branch where:
  - I removed GLUT
  - derived Mesa tarballs' file list from git ls-files.
 
  http://cgit.freedesktop.org/mesa/mesa/log/?h=robust-tarballs
 
  I've confirmed that both automake and scons+crossmingw32 build
  correctly on Linux.
 
  I'd like to merge to main if there are no objections.
 
  Concerning GLUT, we can make a separate branch/repos with just its
  source code if anybody sees value on it. ?

 Yes, I'd definitely like to see a new repo for glut.  I still prefer
 it over freeglut.

 OK. I'll get it done then.

 I've filed https://bugs.freedesktop.org/show_bug.cgi?id=39138 requesting the 
 creation of mesa/glut. Probably your sanction as Mesa project lead will be 
 necessary.

Used my one and only super-power to create this repo, so let me know
if it works.

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

[Mesa-dev] [Bug 39147] egl_gallium.so: errors when linking

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

a.ra...@arcor.de changed:

   What|Removed |Added

 CC||a.ra...@arcor.de

-- 
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] [PATCHv3] r600g: get and use backends mask for occlusion queries

2011-07-11 Thread Vadim Girlin

Use backend_map kernel query if supported, otherwise analyze ZPASS_DONE
results to get the mask.

Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
 src/gallium/drivers/r600/r600.h|4 +
 src/gallium/winsys/r600/drm/evergreen_hw_context.c |2 +
 src/gallium/winsys/r600/drm/r600_drm.c |   57 +++
 src/gallium/winsys/r600/drm/r600_hw_context.c  |  100 +++-
 src/gallium/winsys/r600/drm/r600_priv.h|2 +
 5 files changed, 160 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index 2af4d31..b4dc879 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -94,6 +94,8 @@ struct r600_tiling_info *r600_get_tiling_info(struct radeon 
*radeon);
 unsigned r600_get_clock_crystal_freq(struct radeon *radeon);
 unsigned r600_get_minor_version(struct radeon *radeon);
 unsigned r600_get_num_backends(struct radeon *radeon);
+unsigned r600_get_num_tile_pipes(struct radeon *radeon);
+unsigned r600_get_backend_map(struct radeon *radeon);
 
 /* r600_bo.c */
 struct r600_bo;
@@ -254,6 +256,7 @@ struct r600_context {
u32 *pm4;
struct list_headquery_list;
unsignednum_query_running;
+   unsignedzpass_backends_mask;
struct list_headfenced_bo;
unsignedmax_db; /* for OQ */
unsignednum_dest_buffers;
@@ -275,6 +278,7 @@ struct r600_draw {
struct r600_bo  *indices;
 };
 
+void r600_get_zpass_backends_mask(struct r600_context *ctx);
 int r600_context_init(struct r600_context *ctx, struct radeon *radeon);
 void r600_context_fini(struct r600_context *ctx);
 void r600_context_pipe_state_set(struct r600_context *ctx, struct 
r600_pipe_state *state);
diff --git a/src/gallium/winsys/r600/drm/evergreen_hw_context.c 
b/src/gallium/winsys/r600/drm/evergreen_hw_context.c
index 4d9dd50..87445ab 100644
--- a/src/gallium/winsys/r600/drm/evergreen_hw_context.c
+++ b/src/gallium/winsys/r600/drm/evergreen_hw_context.c
@@ -1018,6 +1018,8 @@ int evergreen_context_init(struct r600_context *ctx, 
struct radeon *radeon)
 
LIST_INITHEAD(ctx-fenced_bo);
 
+   r600_get_zpass_backends_mask(ctx);
+
return 0;
 out_err:
r600_context_fini(ctx);
diff --git a/src/gallium/winsys/r600/drm/r600_drm.c 
b/src/gallium/winsys/r600/drm/r600_drm.c
index b5a4d92..74db67e 100644
--- a/src/gallium/winsys/r600/drm/r600_drm.c
+++ b/src/gallium/winsys/r600/drm/r600_drm.c
@@ -50,6 +50,14 @@
 #define RADEON_INFO_NUM_BACKENDS 0xa
 #endif
 
+#ifndef RADEON_INFO_NUM_TILE_PIPES
+#define RADEON_INFO_NUM_TILE_PIPES 0xb
+#endif
+
+#ifndef RADEON_INFO_BACKEND_MAP
+#define RADEON_INFO_BACKEND_MAP 0xd
+#endif
+
 enum radeon_family r600_get_family(struct radeon *r600)
 {
return r600-family;
@@ -75,6 +83,16 @@ unsigned r600_get_num_backends(struct radeon *radeon)
return radeon-num_backends;
 }
 
+unsigned r600_get_num_tile_pipes(struct radeon *radeon)
+{
+   return radeon-num_tile_pipes;
+}
+
+unsigned r600_get_backend_map(struct radeon *radeon)
+{
+   return radeon-backend_map;
+}
+
 unsigned r600_get_minor_version(struct radeon *radeon)
 {
return radeon-minor_version;
@@ -241,6 +259,40 @@ static int radeon_get_num_backends(struct radeon *radeon)
return 0;
 }
 
+static int radeon_get_num_tile_pipes(struct radeon *radeon)
+{
+   struct drm_radeon_info info = {};
+   uint32_t num_tile_pipes = 0;
+   int r;
+
+   info.request = RADEON_INFO_NUM_TILE_PIPES;
+   info.value = (uintptr_t)num_tile_pipes;
+   r = drmCommandWriteRead(radeon-fd, DRM_RADEON_INFO, info,
+   sizeof(struct drm_radeon_info));
+   if (r)
+   return r;
+
+   radeon-num_tile_pipes = num_tile_pipes;
+   return 0;
+}
+
+static int radeon_get_backend_map(struct radeon *radeon)
+{
+   struct drm_radeon_info info = {};
+   uint32_t backend_map = 0;
+   int r;
+
+   info.request = RADEON_INFO_BACKEND_MAP;
+   info.value = (uintptr_t)backend_map;
+   r = drmCommandWriteRead(radeon-fd, DRM_RADEON_INFO, info,
+   sizeof(struct drm_radeon_info));
+   if (r)
+   return r;
+
+   radeon-backend_map = backend_map;
+   return 0;
+}
+
 
 static int radeon_init_fence(struct radeon *radeon)
 {
@@ -362,6 +414,11 @@ static struct radeon *radeon_new(int fd, unsigned device)
if (radeon-minor_version = 9)
radeon_get_num_backends(radeon);
 
+   if (radeon-minor_version = 11) {
+   radeon_get_num_tile_pipes(radeon);
+   radeon_get_backend_map(radeon);
+   }
+
radeon-bomgr = r600_bomgr_create(radeon, 100);
if (radeon-bomgr == NULL) {
return NULL;
diff --git a/src/gallium/winsys/r600/drm/r600_hw_context.c

[Mesa-dev] [PATCH] linker: Only over-ride built-ins when a prototype has been seen

2011-07-11 Thread Ian Romanick

From: Ian Romanick ian.d.roman...@intel.com

The GLSL spec says:

If a built-in function is redeclared in a shader (i.e., a
prototype is visible) before a call to it, then the linker will
only attempt to resolve that call within the set of shaders that
are linked with it.

This patch enforces this behavior.  When a function call is processed
a flag is set in the ir_call to indicate whether the previously seen
prototype is the built-in or not.  At link time a call will only bind
to an instance of a function that matches the want built-in setting
in the ir_call.

This has the odd side effect that first call to abs() in the shader
below will call the built-in and the second will not:

float foo(float x) { return abs(x); }
float abs(float x) { return -x; }
float bar(float x) { return abs(x); }

This seems insane, but it matches what the spec says.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31744
---
 src/glsl/ir.h   |4 
 src/glsl/link_functions.cpp |   22 +-
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 42a3936..80ad3dd 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -991,6 +991,7 @@ public:
   assert(callee-return_type != NULL);
   type = callee-return_type;
   actual_parameters-move_nodes_to( this-actual_parameters);
+  this-use_builtin = callee-is_builtin;
}
 
virtual ir_call *clone(void *mem_ctx, struct hash_table *ht) const;
@@ -1054,6 +1055,9 @@ public:
/* List of ir_rvalue of paramaters passed in this call. */
exec_list actual_parameters;
 
+   /** Should this call only bind to a built-in function? */
+   bool use_builtin;
+
 private:
ir_call()
   : callee(NULL)
diff --git a/src/glsl/link_functions.cpp b/src/glsl/link_functions.cpp
index ae8818b..7ba760d 100644
--- a/src/glsl/link_functions.cpp
+++ b/src/glsl/link_functions.cpp
@@ -31,7 +31,8 @@
 
 static ir_function_signature *
 find_matching_signature(const char *name, const exec_list *actual_parameters,
-   gl_shader **shader_list, unsigned num_shaders);
+   gl_shader **shader_list, unsigned num_shaders,
+   bool use_builtin);
 
 class call_link_visitor : public ir_hierarchical_visitor {
 public:
@@ -75,7 +76,8 @@ public:
* final linked shader.  If it does, use it as the target of the call.
*/
   ir_function_signature *sig =
-find_matching_signature(name, callee-parameters, linked, 1);
+find_matching_signature(name, callee-parameters, linked, 1,
+ir-use_builtin);
   if (sig != NULL) {
 ir-set_callee(sig);
 return visit_continue;
@@ -85,7 +87,7 @@ public:
* linked.  If it's not found there, return an error.
*/
   sig = find_matching_signature(name, ir-actual_parameters, shader_list,
-   num_shaders);
+   num_shaders, ir-use_builtin);
   if (sig == NULL) {
 /* FINISHME: Log the full signature of unresolved function.
  */
@@ -110,7 +112,9 @@ public:
 
   ir_function_signature *linked_sig =
 f-exact_matching_signature(callee-parameters);
-  if (linked_sig == NULL) {
+  if ((linked_sig == NULL)
+ || ((linked_sig != NULL)
+  (linked_sig-is_builtin != ir-use_builtin))) {
 linked_sig = new(linked) ir_function_signature(callee-return_type);
 f-add_signature(linked_sig);
   }
@@ -241,7 +245,8 @@ private:
  */
 ir_function_signature *
 find_matching_signature(const char *name, const exec_list *actual_parameters,
-   gl_shader **shader_list, unsigned num_shaders)
+   gl_shader **shader_list, unsigned num_shaders,
+   bool use_builtin)
 {
for (unsigned i = 0; i  num_shaders; i++) {
   ir_function *const f = shader_list[i]-symbols-get_function(name);
@@ -254,6 +259,13 @@ find_matching_signature(const char *name, const exec_list 
*actual_parameters,
   if ((sig == NULL) || !sig-is_defined)
 continue;
 
+  /* If this function expects to bind to a built-in function and the
+   * signature that we found isn't a built-in, keep looking.  Also keep
+   * looking if we expect a non-built-in but found a built-in.
+   */
+  if (use_builtin != sig-is_builtin)
+   continue;
+
   return sig;
}
 
-- 
1.7.4.4

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

Re: [Mesa-dev] [PATCH 2/3] intel: Fix height in stencil buffer region allocation

On Sat,  9 Jul 2011 09:01:07 -0700, Chad Versace c...@chad-versace.us wrote:
 If the height of the stencil buffer were odd, then we allocated a region
 whose height was too small --- `height / 2` rather than
 `height / 2 + height % 2`.

Generally this is written (height + 1) / 2 or ALIGN(height, 2) / 2.

So, did the math end up working out so that Y tiling the W buffer was
easier?


pgpcCZPYI90qA.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 1/3] intel: Fix span functions for stencil buffer

2011-07-11 Thread Dan McCabe


On 07/09/2011 08:56 AM, Chad Versace wrote:

Up until this point, we incorrectly believed that the stencil buffer is
Y-tiled. In fact, it is W tiled. From PRM Vol 1 Part 2 Section 4.5.2.1
W-Major Tile Format:
 W-Major Tile Format is used for separate stencil.

Since the stencil buffer is allocated with I915_TILING_Y, the span
functions must decode W tiling through a Y tiled fence.

On gen5 with intel_screen.hw_must_use_separate_stencil enabled,
Fixes-Piglit-test: stencil-drawpixels
Fixes-Piglit-test: stencil-scissor-clear
Fixes-Piglit-test: readpixels-24_8

Note: This is a candidate for the 7.11 branch
Signed-off-by: Chad Versacec...@chad-versace.us
---
  src/mesa/drivers/dri/intel/intel_span.c |   52 +--
  1 files changed, 35 insertions(+), 17 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_span.c 
b/src/mesa/drivers/dri/intel/intel_span.c
index 153803f..f39c008 100644
--- a/src/mesa/drivers/dri/intel/intel_span.c
+++ b/src/mesa/drivers/dri/intel/intel_span.c
@@ -141,28 +141,46 @@ intel_set_span_functions(struct intel_context *intel,
  /**
   * \brief Get pointer offset into stencil buffer.
   *
- * The stencil buffer interleaves two rows into one. Yay for crazy hardware.
- * The table below demonstrates how the pointer arithmetic behaves for a buffer
- * with positive stride (s=stride).
- *
- * x| y | byte offset
- * --
- * 0| 0 | 0
- * 0| 1 | 1
- * 1| 0 | 2
- * 1| 1 | 3
- * ...  | ...   | ...
- * 0| 2 | s
- * 0| 3 | s + 1
- * 1| 2 | s + 2
- * 1| 3 | s + 3
- *
+ * The stencil buffer is W-tiled, yet the drm buffer is allocated with
+ * I915_TILING_Y. So here we must decode the W tiling through a Y fence.
   *
+ * From PRM Vol 1 Part 2 Section 4.5.2.1 W-Major Tile Format:
+ * W-Major Tile Format is used for separate stencil.
   */
  static inline intptr_t
  intel_offset_S8(int stride, GLint x, GLint y)
  {
-   return 2 * ((y / 2) * stride + x) + y % 2;
+   /* f: (x, y) -  (fx, fy) */
+   int fx = x / 8;
+   int fy = y / 4;
+
+   /* e: (x, y) -  (ex, 0) */
+   int ex = (x % 8) / 4;
+
+   /* d: (x, y) -  (dx, dy) */
+   int dx = (x % 4) / 2;
+   int dy = (y % 4) / 2;
+
+   /* c: (x, y) -  (cx, cy) */
+   int cx = x % 2;
+   int cy = y % 2;
+
+   int s = stride;
+   intptr_t o = 0;
+
+   if (s  0) {
+  /*f*/ o += 16 * fx + 4 * s * fy;
+  /*e*/ o += 2 * s * ex;
+  /*d*/ o += 4 * dx + 8 * dy;
+  /*c*/ o += cx + 2 * cy;
+   } else {
+  /*f*/ o += 16 * fx + 4 * s * fy;
+  /*e*/ o += 2 * s * (1 - ex);
+  /*d*/ o += 4 * dx + 8 * (1 - dy);
+  /*c*/ o += cx + 2 * (1 - cy);
+   }
+
+   return o;
  }

  #define WRITE_STENCIL(x, y, src)  buf[intel_offset_S8(stride, x, y)] = src;
Can stride ever be negative? If so, why? If the app ever specified a 
negative stride, it could have fixed at buffer creation time (by also 
adjusting the buffer base address). No need to worry about that issue 
thereafter. On the other hand, negative strides could be considered evil :).


Also, can x or y ever be negative? I'm assuming these address 
manipulations are performed after clipping and/or scissoring, in which 
case, they would always be non-negative (but that assertion should be 
confirmed, preferably prior to compile time).


Using *, / and % for bit manipulations of pixel addresses should 
be avoided. Shifts and masks are clearer for bit manipulation, IMO.


Regarding the offset computation, it might be useful to think of x,y 
addresses of the tile and then of x,y addresses within the tile to make 
the code more readable and perhaps simplify your computations.


For example, if stride is a power of 2, tile size is 2x2 pixels, and 
your x and y address bits look like (upper case bits are tile bits and 
lower case letters are intra-tile bits):

Xx
and
Yy
then the offset for that pixel and a power of two stride has a bit 
pattern that looks like

yx
But the devil is in the details and this might not be valid for our 
particular (crazy?) hardware. YMMV.


cheers, danm



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

[Mesa-dev] [PATCH 1/2] st/mesa: derive a stencil sampler format from the actual texture format

---
 src/mesa/state_tracker/st_cb_drawpixels.c |   70 +++--
 1 files changed, 26 insertions(+), 44 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index dca3324..f25656a 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -273,26 +273,6 @@ make_passthrough_vertex_shader(struct st_context *st,
 
 
 /**
- * Return a texture base format for drawing/copying an image
- * of the given format.
- */
-static GLenum
-base_format(GLenum format)
-{
-   switch (format) {
-   case GL_DEPTH_COMPONENT:
-  return GL_DEPTH_COMPONENT;
-   case GL_DEPTH_STENCIL:
-  return GL_DEPTH_STENCIL;
-   case GL_STENCIL_INDEX:
-  return GL_STENCIL_INDEX;
-   default:
-  return GL_RGBA;
-   }
-}
-
-
-/**
  * Return a texture internalFormat for drawing/copying an image
  * of the given format and type.
  */
@@ -999,7 +979,6 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
GLboolean write_stencil = GL_FALSE, write_depth = GL_FALSE;
struct pipe_sampler_view *sv[2];
int num_sampler_view = 1;
-   enum pipe_format stencil_format = PIPE_FORMAT_NONE;
struct st_fp_variant *fpv;
 
if (format == GL_DEPTH_STENCIL)
@@ -1014,28 +993,6 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
   /* can we write to stencil if not fallback */
   if (!pipe-screen-get_param(pipe-screen, 
PIPE_CAP_SHADER_STENCIL_EXPORT))
 goto stencil_fallback;
-
-  tex_format = st_choose_format(st-pipe-screen, base_format(format),
-GL_NONE, GL_NONE,
-PIPE_TEXTURE_2D,
-   0, PIPE_BIND_SAMPLER_VIEW);
-
-  switch (tex_format) {
-  case PIPE_FORMAT_Z24_UNORM_S8_USCALED:
- stencil_format = PIPE_FORMAT_X24S8_USCALED;
- break;
-  case PIPE_FORMAT_S8_USCALED_Z24_UNORM:
- stencil_format = PIPE_FORMAT_S8X24_USCALED;
- break;
-  case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
- stencil_format = PIPE_FORMAT_X32_S8X24_USCALED;
- break;
-  case PIPE_FORMAT_S8_USCALED:
- stencil_format = PIPE_FORMAT_S8_USCALED;
- break;
-  default:
- goto stencil_fallback;
-  }
}
 
/* Mesa state should be up to date by now */
@@ -1080,7 +1037,32 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
  sv[0] = st_create_texture_sampler_view(st-pipe, pt);
 
  if (sv[0]) {
-   if (write_stencil) {
+/* Create a second sampler view to read stencil.
+ * The stencil is written using the shader stencil export
+ * functionality. */
+if (write_stencil) {
+   enum pipe_format stencil_format = PIPE_FORMAT_NONE;
+
+   switch (pt-format) {
+   case PIPE_FORMAT_Z24_UNORM_S8_USCALED:
+   case PIPE_FORMAT_X24S8_USCALED:
+  stencil_format = PIPE_FORMAT_X24S8_USCALED;
+  break;
+   case PIPE_FORMAT_S8_USCALED_Z24_UNORM:
+   case PIPE_FORMAT_S8X24_USCALED:
+  stencil_format = PIPE_FORMAT_S8X24_USCALED;
+  break;
+   case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
+   case PIPE_FORMAT_X32_S8X24_USCALED:
+  stencil_format = PIPE_FORMAT_X32_S8X24_USCALED;
+  break;
+   case PIPE_FORMAT_S8_USCALED:
+  stencil_format = PIPE_FORMAT_S8_USCALED;
+  break;
+   default:
+  assert(0);
+   }
+
   sv[1] = st_create_texture_sampler_view_format(st-pipe, pt,
  stencil_format);
   num_sampler_view++;
-- 
1.7.4.1

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

[Mesa-dev] [PATCH 2/2] st/mesa: get rid of unnecessary 'goto' in DrawPixels

---
 src/mesa/state_tracker/st_cb_drawpixels.c |   16 ++--
 1 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index f25656a..d3e6aef 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -988,11 +988,12 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
else if (format == GL_DEPTH_COMPONENT)
   write_depth = GL_TRUE;
 
-   if (write_stencil) {
-  enum pipe_format tex_format;
-  /* can we write to stencil if not fallback */
-  if (!pipe-screen-get_param(pipe-screen, 
PIPE_CAP_SHADER_STENCIL_EXPORT))
-goto stencil_fallback;
+   if (write_stencil 
+   !pipe-screen-get_param(pipe-screen, PIPE_CAP_SHADER_STENCIL_EXPORT)) 
{
+  /* software fallback */
+  draw_stencil_pixels(ctx, x, y, width, height, format, type,
+  unpack, pixels);
+  return;
}
 
/* Mesa state should be up to date by now */
@@ -1083,11 +1084,6 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
  pipe_resource_reference(pt, NULL);
   }
}
-   return;
-
-stencil_fallback:
-   draw_stencil_pixels(ctx, x, y, width, height, format, type,
-  unpack, pixels);
 }
 
 
-- 
1.7.4.1

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

Re: [Mesa-dev] [PATCH 2/2] st/mesa: get rid of unnecessary 'goto' in DrawPixels


On 07/11/2011 02:33 PM, Marek Olšák wrote:

---
  src/mesa/state_tracker/st_cb_drawpixels.c |   16 ++--
  1 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index f25656a..d3e6aef 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -988,11 +988,12 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
 else if (format == GL_DEPTH_COMPONENT)
write_depth = GL_TRUE;

-   if (write_stencil) {
-  enum pipe_format tex_format;
-  /* can we write to stencil if not fallback */
-  if (!pipe-screen-get_param(pipe-screen, 
PIPE_CAP_SHADER_STENCIL_EXPORT))
-goto stencil_fallback;
+   if (write_stencil
+   !pipe-screen-get_param(pipe-screen, PIPE_CAP_SHADER_STENCIL_EXPORT)) 
{
+  /* software fallback */
+  draw_stencil_pixels(ctx, x, y, width, height, format, type,
+  unpack, pixels);
+  return;
 }

 /* Mesa state should be up to date by now */
@@ -1083,11 +1084,6 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
   pipe_resource_reference(pt, NULL);
}
 }
-   return;
-
-stencil_fallback:
-   draw_stencil_pixels(ctx, x, y, width, height, format, type,
-  unpack, pixels);
  }





Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] st/mesa: derive a stencil sampler format from the actual texture format


On 07/11/2011 02:33 PM, Marek Olšák wrote:

---
  src/mesa/state_tracker/st_cb_drawpixels.c |   70 +++--
  1 files changed, 26 insertions(+), 44 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index dca3324..f25656a 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -273,26 +273,6 @@ make_passthrough_vertex_shader(struct st_context *st,


  /**
- * Return a texture base format for drawing/copying an image
- * of the given format.
- */
-static GLenum
-base_format(GLenum format)
-{
-   switch (format) {
-   case GL_DEPTH_COMPONENT:
-  return GL_DEPTH_COMPONENT;
-   case GL_DEPTH_STENCIL:
-  return GL_DEPTH_STENCIL;
-   case GL_STENCIL_INDEX:
-  return GL_STENCIL_INDEX;
-   default:
-  return GL_RGBA;
-   }
-}
-
-
-/**
   * Return a texture internalFormat for drawing/copying an image
   * of the given format and type.
   */
@@ -999,7 +979,6 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
 GLboolean write_stencil = GL_FALSE, write_depth = GL_FALSE;
 struct pipe_sampler_view *sv[2];
 int num_sampler_view = 1;
-   enum pipe_format stencil_format = PIPE_FORMAT_NONE;
 struct st_fp_variant *fpv;

 if (format == GL_DEPTH_STENCIL)
@@ -1014,28 +993,6 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
/* can we write to stencil if not fallback */
if (!pipe-screen-get_param(pipe-screen, 
PIPE_CAP_SHADER_STENCIL_EXPORT))
 goto stencil_fallback;
-
-  tex_format = st_choose_format(st-pipe-screen, base_format(format),
-GL_NONE, GL_NONE,
-PIPE_TEXTURE_2D,
-   0, PIPE_BIND_SAMPLER_VIEW);
-
-  switch (tex_format) {
-  case PIPE_FORMAT_Z24_UNORM_S8_USCALED:
- stencil_format = PIPE_FORMAT_X24S8_USCALED;
- break;
-  case PIPE_FORMAT_S8_USCALED_Z24_UNORM:
- stencil_format = PIPE_FORMAT_S8X24_USCALED;
- break;
-  case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
- stencil_format = PIPE_FORMAT_X32_S8X24_USCALED;
- break;
-  case PIPE_FORMAT_S8_USCALED:
- stencil_format = PIPE_FORMAT_S8_USCALED;
- break;
-  default:
- goto stencil_fallback;
-  }
 }

 /* Mesa state should be up to date by now */
@@ -1080,7 +1037,32 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
   sv[0] = st_create_texture_sampler_view(st-pipe, pt);

   if (sv[0]) {
-   if (write_stencil) {
+/* Create a second sampler view to read stencil.
+ * The stencil is written using the shader stencil export
+ * functionality. */
+if (write_stencil) {
+   enum pipe_format stencil_format = PIPE_FORMAT_NONE;
+
+   switch (pt-format) {
+   case PIPE_FORMAT_Z24_UNORM_S8_USCALED:
+   case PIPE_FORMAT_X24S8_USCALED:
+  stencil_format = PIPE_FORMAT_X24S8_USCALED;
+  break;
+   case PIPE_FORMAT_S8_USCALED_Z24_UNORM:
+   case PIPE_FORMAT_S8X24_USCALED:
+  stencil_format = PIPE_FORMAT_S8X24_USCALED;
+  break;
+   case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
+   case PIPE_FORMAT_X32_S8X24_USCALED:
+  stencil_format = PIPE_FORMAT_X32_S8X24_USCALED;
+  break;
+   case PIPE_FORMAT_S8_USCALED:
+  stencil_format = PIPE_FORMAT_S8_USCALED;
+  break;
+   default:
+  assert(0);
+   }
+
   sv[1] = st_create_texture_sampler_view_format(st-pipe, pt,
   stencil_format);
   num_sampler_view++;



Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/mesa: choose a matching depth internal format for DrawPixels

This makes it easier to hit the fast path and get a float format
when we ask for it.
---
 src/mesa/state_tracker/st_cb_drawpixels.c |   29 +++--
 1 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index d3e6aef..1d908c0 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -281,11 +281,36 @@ internal_format(struct gl_context *ctx, GLenum format, 
GLenum type)
 {
switch (format) {
case GL_DEPTH_COMPONENT:
-  return GL_DEPTH_COMPONENT;
+  switch (type) {
+  case GL_UNSIGNED_SHORT:
+ return GL_DEPTH_COMPONENT16;
+
+  case GL_UNSIGNED_INT:
+ return GL_DEPTH_COMPONENT32;
+
+  case GL_FLOAT:
+ if (ctx-Extensions.ARB_depth_buffer_float)
+return GL_DEPTH_COMPONENT32F;
+ else
+return GL_DEPTH_COMPONENT;
+
+  default:
+ return GL_DEPTH_COMPONENT;
+  }
+
case GL_DEPTH_STENCIL:
-  return GL_DEPTH_STENCIL;
+  switch (type) {
+  case GL_FLOAT_32_UNSIGNED_INT_24_8_REV:
+ return GL_DEPTH32F_STENCIL8;
+
+  case GL_UNSIGNED_INT_24_8:
+  default:
+ return GL_DEPTH24_STENCIL8;
+  }
+
case GL_STENCIL_INDEX:
   return GL_STENCIL_INDEX;
+
default:
   if (_mesa_is_integer_format(format)) {
  switch (type) {
-- 
1.7.4.1

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

Re: [Mesa-dev] About merging pipe-video to master

2011-07-11 Thread Johannes Obermayr

Christian König schrieb:
Hi guys,

as the subject already indicates: I'm about to merge pipe-video to
master and just wanted to ask if anybody has still any objections?

Yes [I am a watchman of compile/build errors (I know I am an old bitcher but
code quality rules)]:

https://build.opensuse.org/package/rawlog?arch=x86_64package=Mesaproject=home%3Ajobermayr%3Atestrepository=openSUSE_11.4

Please merge things only when all new introduced things/switches compile/build
successfully.

Thanks.
Johannes

After following Jose and Younes discussion on mesa-dev about how to
design such an abstraction layer I took another round of cleaning up the
interface and moved some more parts into the state tracker.

So the interface between the state tracker and drivers only consist of
the following now:

1. two additional functions for the screen object: get_video_param and
is_video_format_supported. get_video_param gets a parameter for a
specified codec (like max width/height of decoding target, which could
be smaller than texture max width/height), and is_video_format_supported
which checks if a texture format is supported as a decoding target for a
codec.

2. create_video_decoder function in the pipe_context object, which
creates a decoder object for a given codec. The decoder object in turn
includes everything needed to decode a video stream of that codec and
uses pipe_video_decode_buffer objects to hold the input data of a single
frame of that video codec.

3. create_video_buffer function in the pipe_context object, which
creates a video_buffer object to store a decoded video frame. This
video_buffer object is then used for both rendering to the screen with
normal pipe_context functionality and also as the input for reference
frames back to the decoder.

The pipe_video_buffer object is there because I think hardware decoders
need some special memory layout of the different planes of a yuv buffer.
There is a standard implementation that just uses normal textures as the
different planes for yuv buffer, which can be used by a driver when
there is no need for a special memory layout or when the driver just
uses shader based decoding.

The other option would be adding a PIPE_BIND_VIDEO_BUFFER flag to the
resource creation functions, but I don't want to repeat functionality in
the different drivers and as far as I can see the current resource
functions (samplers/surfaces) can't be used to create a surface for just
one plane/component of a yuv buffer and we could still clean that up to
use the standard resource functions if the need arise.

Everything else, especially the vl_compositor functionality, is now part
of the state tracker instead of the driver. The interface was mostly
designed keeping two things in mind: First it should abstract the
functionality of hardware video decoding from the state tracker and
second it should be possible to implement a wide variety of different
video decoding apis with it. For the second part I checked that it's at
least possible to do XvMC,VDPAU,VAAPI and DXVA with it.

So what do you guys think about it?

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

Re: [Mesa-dev] [PATCH 2/3] intel: Fix height in stencil buffer region allocation

2011-07-11 Thread Chad Versace

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/11/2011 12:08 PM, Eric Anholt wrote:
 On Sat,  9 Jul 2011 09:01:07 -0700, Chad Versace c...@chad-versace.us wrote:
 If the height of the stencil buffer were odd, then we allocated a region
 whose height was too small --- `height / 2` rather than
 `height / 2 + height % 2`.
 
 Generally this is written (height + 1) / 2 or ALIGN(height, 2) / 2.

Ok. I'll change the patch to use the (height+1)/2 idiom.
 
 So, did the math end up working out so that Y tiling the W buffer was
 easier?

The math for decoding a W tile through a Y fence was slightly more complex than 
decoding an unfenced W tile. As far as arithmetic complexity is concerned, it 
doesn't matter which one we choose.

More importantly, I was absolutely unable to get the stencil buffer to work as 
non-tiled. I encountered bizarre behavior. However, if you really think that we 
should allocate the stencil buffer as non-tiled, then we can discuss on 
Wednesday possible interpretations of that bizarre behavior and the needed 
fixes.

- -- 
Chad Versace
c...@chad-versace.us
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOG3dbAAoJEAIvNt057x8iMugQAKbQcu7tg0wYGrbGB9DhhW4Y
zIQueR+d8dcEXB/C5hN2PdxHLAkVQrkUz7PXxPmbOn9nDH69CtBdTJhIpEJtiOH7
RtYgsfiIwqEu7YHs6y4+GgmwnmIokiIJMSOtLgx8hZgvO0wdxqITHcE+qZubDQQz
lMpxjKu7pM+B2sb3FooRCYO/EzzFaj4Iz27Eav3aQM7GceSp7aOtlMTUGrIs0a2q
XtIEOF7m04JtfVeLnkiqkLVIIfVFeSPP0FAXkgnJcmESIkWOUQ2fEOiWj4b4EgIe
iRDRJOLYuf20s8eT2WLK/Zck7JJajy6VKl+OemwJtzbTzZlhWD24dR/Tu5TReL9X
n/YSCyO+hzTEwcIgNaiIH5oY8dABEs702lT0xZlUicIlJFsrr2Bri3mj5B/OSdOG
hN+Vy2DF6+DuYbz8SkURMdHdbxVEtGJXXgX2m9RgJ8u64s24HywSRKDkLU/M2i0k
DWkScczFyr61BaPOWQjcbcL0hbstzpELGAzAZrTR2r2VLgMDmqmovd7TpnVrgZAw
kklB/nuM5wO8Mehs0ZOag6AALtclJJx0llUc2QZ3bWwWWJKpTgDBSLnTsL5vb86b
hEIa1qnEOlupCj9h1r0JHqzyOsS7J+PRf+dwlQn3gmb4hdUTVBBYkBCTaDvjmkoc
8LWR5N/RmsCh8OCbdLAd
=V3ci
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: choose a matching depth internal format for DrawPixels


On 07/11/2011 03:54 PM, Marek Olšák wrote:

This makes it easier to hit the fast path and get a float format
when we ask for it.
---
  src/mesa/state_tracker/st_cb_drawpixels.c |   29 +++--
  1 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index d3e6aef..1d908c0 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -281,11 +281,36 @@ internal_format(struct gl_context *ctx, GLenum format, 
GLenum type)
  {
 switch (format) {
 case GL_DEPTH_COMPONENT:
-  return GL_DEPTH_COMPONENT;
+  switch (type) {
+  case GL_UNSIGNED_SHORT:
+ return GL_DEPTH_COMPONENT16;
+
+  case GL_UNSIGNED_INT:
+ return GL_DEPTH_COMPONENT32;
+
+  case GL_FLOAT:
+ if (ctx-Extensions.ARB_depth_buffer_float)
+return GL_DEPTH_COMPONENT32F;
+ else
+return GL_DEPTH_COMPONENT;
+
+  default:
+ return GL_DEPTH_COMPONENT;
+  }
+
 case GL_DEPTH_STENCIL:
-  return GL_DEPTH_STENCIL;
+  switch (type) {
+  case GL_FLOAT_32_UNSIGNED_INT_24_8_REV:
+ return GL_DEPTH32F_STENCIL8;
+
+  case GL_UNSIGNED_INT_24_8:
+  default:
+ return GL_DEPTH24_STENCIL8;
+  }
+
 case GL_STENCIL_INDEX:
return GL_STENCIL_INDEX;
+
 default:
if (_mesa_is_integer_format(format)) {
   switch (type) {



Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] autoconf: Do not select Xlib when building DRI

Looks good, thanks. I have pushed it.

Marek

On Mon, Jul 11, 2011 at 4:58 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 As Chia-I Wu said 'There are two libGL providers, Xlib and DRI based
 they cannot coexist'

 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  configure.ac |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index dde13c9..19cc531 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -791,7 +791,7 @@ esac
  if test x$enable_dri = xyes; then
     DRIVER_DIRS=$DRIVER_DIRS dri

 -    GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/xlib sw/dri
 +    GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/dri
     GALLIUM_STATE_TRACKERS_DIRS=dri $GALLIUM_STATE_TRACKERS_DIRS
     HAVE_ST_DRI=yes
  fi
 --
 1.7.6

 ___
 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 1/3] intel: Fix span functions for stencil buffer

2011-07-11 Thread Dan McCabe


On 07/11/2011 04:03 PM, Chad Versace wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/11/2011 12:49 PM, Dan McCabe wrote:

On 07/09/2011 08:56 AM, Chad Versace wrote:

Up until this point, we incorrectly believed that the stencil buffer is
Y-tiled. In fact, it is W tiled. From PRM Vol 1 Part 2 Section 4.5.2.1
W-Major Tile Format:
  W-Major Tile Format is used for separate stencil.

Since the stencil buffer is allocated with I915_TILING_Y, the span
functions must decode W tiling through a Y tiled fence.

On gen5 with intel_screen.hw_must_use_separate_stencil enabled,
Fixes-Piglit-test: stencil-drawpixels
Fixes-Piglit-test: stencil-scissor-clear
Fixes-Piglit-test: readpixels-24_8

Note: This is a candidate for the 7.11 branch
Signed-off-by: Chad Versacec...@chad-versace.us
---
   src/mesa/drivers/dri/intel/intel_span.c |   52 
+--
   1 files changed, 35 insertions(+), 17 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_span.c 
b/src/mesa/drivers/dri/intel/intel_span.c
index 153803f..f39c008 100644
--- a/src/mesa/drivers/dri/intel/intel_span.c
+++ b/src/mesa/drivers/dri/intel/intel_span.c
@@ -141,28 +141,46 @@ intel_set_span_functions(struct intel_context *intel,
   /**
* \brief Get pointer offset into stencil buffer.
*
- * The stencil buffer interleaves two rows into one. Yay for crazy hardware.
- * The table below demonstrates how the pointer arithmetic behaves for a buffer
- * with positive stride (s=stride).
- *
- * x| y | byte offset
- * --
- * 0| 0 | 0
- * 0| 1 | 1
- * 1| 0 | 2
- * 1| 1 | 3
- * ...  | ...   | ...
- * 0| 2 | s
- * 0| 3 | s + 1
- * 1| 2 | s + 2
- * 1| 3 | s + 3
- *
+ * The stencil buffer is W-tiled, yet the drm buffer is allocated with
+ * I915_TILING_Y. So here we must decode the W tiling through a Y fence.
*
+ * From PRM Vol 1 Part 2 Section 4.5.2.1 W-Major Tile Format:
+ * W-Major Tile Format is used for separate stencil.
*/
   static inline intptr_t
   intel_offset_S8(int stride, GLint x, GLint y)
   {
-   return 2 * ((y / 2) * stride + x) + y % 2;
+   /* f: (x, y) -   (fx, fy) */
+   int fx = x / 8;
+   int fy = y / 4;
+
+   /* e: (x, y) -   (ex, 0) */
+   int ex = (x % 8) / 4;
+
+   /* d: (x, y) -   (dx, dy) */
+   int dx = (x % 4) / 2;
+   int dy = (y % 4) / 2;
+
+   /* c: (x, y) -   (cx, cy) */
+   int cx = x % 2;
+   int cy = y % 2;
+
+   int s = stride;
+   intptr_t o = 0;
+
+   if (s   0) {
+  /*f*/ o += 16 * fx + 4 * s * fy;
+  /*e*/ o += 2 * s * ex;
+  /*d*/ o += 4 * dx + 8 * dy;
+  /*c*/ o += cx + 2 * cy;
+   } else {
+  /*f*/ o += 16 * fx + 4 * s * fy;
+  /*e*/ o += 2 * s * (1 - ex);
+  /*d*/ o += 4 * dx + 8 * (1 - dy);
+  /*c*/ o += cx + 2 * (1 - cy);
+   }
+
+   return o;
   }

   #define WRITE_STENCIL(x, y, src)  buf[intel_offset_S8(stride, x, y)] = src;

Can stride ever be negative? If so, why?

Yes. The stride is negative for window-system renderbuffers.


If the app ever specified a negative stride, it could have fixed at buffer 
creation time (by also adjusting the buffer base address). No need to worry 
about that issue thereafter.

No-can-do. As far as I know, X demands that its buffers have negative stride.


On the other hand, negative strides could be considered evil :).

Yes, they are :)


Also, can x or y ever be negative?

No.

[snip]


Using *, / and % for bit manipulations of pixel addresses should be 
avoided. Shifts and masks are clearer for bit manipulation, IMO.

Regarding the offset computation, it might be useful to think of x,y addresses 
of the tile and then of x,y addresses within the tile to make the code more 
readable and perhaps simplify your computations.

Damn crazy hardware. Here we need to decode a W tile through a Y fence, so the x,y 
addresses of the tile and then of x,y addresses within the tile are non-existent. 
The fence mapping has carved up the W tile and made a mess of it. So, there are no tile 
addresses to compute.

Here is the little meaning that my equations possess:
 - (fx + ex, fy) is the address of a 4x4 block in which (x, y) resides.
 - Decompose that 4x4 block into 2x2 blocks. (dx, dy) is
   the address of that 2x2 block within the 4x4 block.
 - (cx, cy) is the address of (x, y) within that 2x2 block.


For example, if stride is a power of 2, tile size is 2x2 pixels, and your x and 
y address bits look like (upper case bits are tile bits and lower case letters 
are intra-tile bits):
 Xx
and
 Yy
then the offset for that pixel and a power of two stride has a bit pattern that 
looks like
 yx
But the devil is in the details and this might not be valid for our particular 
(crazy?) hardware. YMMV.

Can a similiar set of bit operations replicate intel_offset_S8()?


Yeah. I started working out the details, but stopped after concluding it

[Mesa-dev] [PATCH 1/6] intel: Use _mesa_tex_target_to_face() helper function instead of our own.

---
 src/mesa/drivers/dri/intel/intel_tex_image.c |   25 +++--
 1 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c 
b/src/mesa/drivers/dri/intel/intel_tex_image.c
index 269faef..1f8b885 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_image.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
@@ -120,25 +120,6 @@ intel_miptree_create_for_teximage(struct intel_context 
*intel,
   expect_accelerated_upload);
 }
 
-
-
-
-static GLuint
-target_to_face(GLenum target)
-{
-   switch (target) {
-   case GL_TEXTURE_CUBE_MAP_POSITIVE_X_ARB:
-   case GL_TEXTURE_CUBE_MAP_NEGATIVE_X_ARB:
-   case GL_TEXTURE_CUBE_MAP_POSITIVE_Y_ARB:
-   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB:
-   case GL_TEXTURE_CUBE_MAP_POSITIVE_Z_ARB:
-   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB:
-  return ((GLuint) target - (GLuint) GL_TEXTURE_CUBE_MAP_POSITIVE_X);
-   default:
-  return 0;
-   }
-}
-
 /* There are actually quite a few combinations this will work for,
  * more than what I've listed here.
  */
@@ -426,7 +407,7 @@ intelTexImage(struct gl_context * ctx,
DBG(%s target %s level %d %dx%dx%d border %d\n, __FUNCTION__,
_mesa_lookup_enum_by_nr(target), level, width, height, depth, border);
 
-   intelImage-face = target_to_face(target);
+   intelImage-face = _mesa_tex_target_to_face(target);
intelImage-level = level;
 
if (_mesa_is_format_compressed(texImage-TexFormat)) {
@@ -835,7 +816,7 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
  rb-region-width, rb-region-height, 1,
  0, internalFormat, texFormat);
 
-   intelImage-face = target_to_face(target);
+   intelImage-face = _mesa_tex_target_to_face(target);
intelImage-level = level;
texImage-RowStride = rb-region-pitch;
intel_miptree_reference(intelImage-mt, intelObj-mt);
@@ -893,7 +874,7 @@ intel_image_target_texture_2d(struct gl_context *ctx, 
GLenum target,
  image-region-width, image-region-height, 1,
  0, image-internal_format, image-format);
 
-   intelImage-face = target_to_face(target);
+   intelImage-face = _mesa_tex_target_to_face(target);
intelImage-level = 0;
texImage-RowStride = image-region-pitch;
intel_miptree_reference(intelImage-mt, intelObj-mt);
-- 
1.7.5.4

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

[Mesa-dev] [PATCH 5/6] mesa: Fix assertion failure in X8_Z24/Z24_X8 texfetch.

---
 src/mesa/main/texfetch_tmp.h |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/texfetch_tmp.h b/src/mesa/main/texfetch_tmp.h
index 3b1eedf..d170adf 100644
--- a/src/mesa/main/texfetch_tmp.h
+++ b/src/mesa/main/texfetch_tmp.h
@@ -2287,7 +2287,8 @@ static void FETCH(f_z24_s8)( const struct 
gl_texture_image *texImage,
const GLuint *src = TEXEL_ADDR(GLuint, texImage, i, j, k, 1);
const GLfloat scale = 1.0F / (GLfloat) 0xff;
texel[0] = ((*src)  8) * scale;
-   ASSERT(texImage-TexFormat == MESA_FORMAT_Z24_S8);
+   ASSERT(texImage-TexFormat == MESA_FORMAT_Z24_S8 ||
+ texImage-TexFormat == MESA_FORMAT_Z24_X8);
ASSERT(texel[0] = 0.0F);
ASSERT(texel[0] = 1.0F);
 }
@@ -2314,7 +2315,8 @@ static void FETCH(f_s8_z24)( const struct 
gl_texture_image *texImage,
const GLuint *src = TEXEL_ADDR(GLuint, texImage, i, j, k, 1);
const GLfloat scale = 1.0F / (GLfloat) 0xff;
texel[0] = ((*src)  0x00ff) * scale;
-   ASSERT(texImage-TexFormat == MESA_FORMAT_S8_Z24);
+   ASSERT(texImage-TexFormat == MESA_FORMAT_S8_Z24 ||
+ texImage-TexFormat == MESA_FORMAT_X8_Z24);
ASSERT(texel[0] = 0.0F);
ASSERT(texel[0] = 1.0F);
 }
-- 
1.7.5.4

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

[Mesa-dev] [PATCH 3/6] i915: Use _mesa_get_format_name to describe translate_tex_format() fail.

I don't want to go count up to what format number 29 is.
---
 src/mesa/drivers/dri/i915/i830_texstate.c |3 ++-
 src/mesa/drivers/dri/i915/i915_texstate.c |3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i830_texstate.c 
b/src/mesa/drivers/dri/i915/i830_texstate.c
index d4af5e5..71ce44f 100644
--- a/src/mesa/drivers/dri/i915/i830_texstate.c
+++ b/src/mesa/drivers/dri/i915/i830_texstate.c
@@ -76,7 +76,8 @@ translate_texture_format(GLuint mesa_format)
case MESA_FORMAT_RGBA_DXT5:
   return (MAPSURF_COMPRESSED | MT_COMPRESS_DXT4_5);
default:
-  fprintf(stderr, %s: bad image format %x\n, __FUNCTION__, mesa_format);
+  fprintf(stderr, %s: bad image format %s\n, __FUNCTION__,
+ _mesa_get_format_name(mesa_format));
   abort();
   return 0;
}
diff --git a/src/mesa/drivers/dri/i915/i915_texstate.c 
b/src/mesa/drivers/dri/i915/i915_texstate.c
index bcf42d5..90ebee3 100644
--- a/src/mesa/drivers/dri/i915/i915_texstate.c
+++ b/src/mesa/drivers/dri/i915/i915_texstate.c
@@ -89,7 +89,8 @@ translate_texture_format(gl_format mesa_format, GLenum 
DepthMode)
   else
 return (MAPSURF_32BIT | MT_32BIT_x8L24);
default:
-  fprintf(stderr, %s: bad image format %x\n, __FUNCTION__, mesa_format);
+  fprintf(stderr, %s: bad image format %s\n, __FUNCTION__,
+ _mesa_get_format_name(mesa_format));
   abort();
   return 0;
}
-- 
1.7.5.4

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

[Mesa-dev] [PATCH 4/6] i915: Fix depth texturing since 86e62b2357447b7c97f434be4834f4b50aa0764d

The 965 driver already had the X8_Z24 case, but 915 was missing it.
---
 src/mesa/drivers/dri/i915/i915_texstate.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_texstate.c 
b/src/mesa/drivers/dri/i915/i915_texstate.c
index 90ebee3..7cd6820 100644
--- a/src/mesa/drivers/dri/i915/i915_texstate.c
+++ b/src/mesa/drivers/dri/i915/i915_texstate.c
@@ -82,6 +82,7 @@ translate_texture_format(gl_format mesa_format, GLenum 
DepthMode)
case MESA_FORMAT_RGBA_DXT5:
   return (MAPSURF_COMPRESSED | MT_COMPRESS_DXT4_5);
case MESA_FORMAT_S8_Z24:
+   case MESA_FORMAT_X8_Z24:
   if (DepthMode == GL_ALPHA)
 return (MAPSURF_32BIT | MT_32BIT_x8A24);
   else if (DepthMode == GL_INTENSITY)
-- 
1.7.5.4

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

[Mesa-dev] [PATCH 2/6] i915: Fix map/unmap mismatches from leaving INTEL_FALLBACK during TNL.

The first rendering after context create didn't know of the color
buffer yet, triggering a sw fallback.  The intel_prepare_render() from
intelSpanRenderStart then found the buffer and turned off fallbacks,
but intelSpanRenderFinish was never called and things were left
mapped.  By checking buffers before making the call on whether to do
the fallback pipeline or not, we avoid the fallback change inside of
the rendering pipeline.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31561
---
 src/mesa/drivers/dri/i915/intel_tris.c |   13 +
 src/mesa/drivers/dri/intel/intel_context.h |1 +
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/intel_tris.c 
b/src/mesa/drivers/dri/i915/intel_tris.c
index 7bcb72f..941c435 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -1078,6 +1078,13 @@ intelRunPipeline(struct gl_context * ctx)
if (ctx-NewState)
   _mesa_update_state_locked(ctx);
 
+   /* We need to get this done before we start the pipeline, or a
+* change in the INTEL_FALLBACK() of its intel_draw_buffers() call
+* while the pipeline is running will result in mismatched swrast
+* map/unmaps, and later assertion failures.
+*/
+   intel_prepare_render(intel);
+
if (intel-NewGLState) {
   if (intel-NewGLState  _NEW_TEXTURE) {
  intel-vtbl.update_texture_state(intel);
@@ -1092,7 +1099,9 @@ intelRunPipeline(struct gl_context * ctx)
}
 
intel_map_vertex_shader_textures(ctx);
+   intel-tnl_pipeline_running = true;
_tnl_run_pipeline(ctx);
+   intel-tnl_pipeline_running = false;
intel_unmap_vertex_shader_textures(ctx);
 
_mesa_unlock_context_textures(ctx);
@@ -1228,6 +1237,8 @@ intelFallback(struct intel_context *intel, GLbitfield 
bit, GLboolean mode)
if (mode) {
   intel-Fallback |= bit;
   if (oldfallback == 0) {
+assert(!intel-tnl_pipeline_running);
+
  intel_flush(ctx);
  if (INTEL_DEBUG  DEBUG_FALLBACKS)
 fprintf(stderr, ENTER FALLBACK %x: %s\n,
@@ -1239,6 +1250,8 @@ intelFallback(struct intel_context *intel, GLbitfield 
bit, GLboolean mode)
else {
   intel-Fallback = ~bit;
   if (oldfallback == bit) {
+assert(!intel-tnl_pipeline_running);
+
  _swrast_flush(ctx);
  if (INTEL_DEBUG  DEBUG_FALLBACKS)
 fprintf(stderr, LEAVE FALLBACK %s\n, getFallbackString(bit));
diff --git a/src/mesa/drivers/dri/intel/intel_context.h 
b/src/mesa/drivers/dri/intel/intel_context.h
index 148fb0c..1727bad 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -199,6 +199,7 @@ struct intel_context
drm_intel_bo *first_post_swapbuffers_batch;
GLboolean need_throttle;
GLboolean no_batch_wrap;
+   bool tnl_pipeline_running; /** Set while i915's _tnl_run_pipeline. */
 
struct
{
-- 
1.7.5.4

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

[Mesa-dev] [PATCH 6/6] i915: Fix NPOT compressed textures on 915.