mesa3d-dev

Re: [Mesa3d-dev] Compiling Mesa from git (just build, not installed)

[STEVE555 <ste...@ho...>]

Brian Paul-4 wrote:
> 
> On Sun, May 8, 2011 at 3:01 AM, STEVE555 <ste...@ho...>
> wrote:
>>
>> Hi to all,
>>          I have been regularly been building the git version of mesa with
>> with the gallium-nouveau code enabled.
>>
>> I'm currently using Fedora Rawhide with the latest updates. I use the
>> following ./autogen.sh options to set mesa for the build: ./autogen.sh
>> --enable-debug --enable-glx-tls --enable-asm --with-dri-drivers=
>> --enable-gallium-nouveau --disable-gallium-i915 --disable-gallium-i965
>> --disable-egl --disable-gallium-r300  --disable-gallium-r600
>> --disable-gallium-svga --with-state-trackers=glx,dri(and I sometimes add
>> the
>> xorg-state-tracker at the end).
>>
>> The trouble I'm having is after I believe after some commits for GLX,
>> Mesa
>> keeps ending with this build error:
>>
>> DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE
>> -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
>> -DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\"
>> glxcmds.c -o glxcmds.o
>> gcc -c -I. -I../../include -I../../include/GL/internal -I../../src/mesa
>> -I../../src/mapi -I../../src/mapi/glapi -I/usr/include/libdrm      -g -O2
>> -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -g
>> -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
>> -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS
>> -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
>> -DGLX_DIRECT_RENDERING
>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE
>> -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
>> -DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\"
>> glxcurrent.c -o glxcurrent.o
>> gcc -c -I. -I../../include -I../../include/GL/internal -I../../src/mesa
>> -I../../src/mapi -I../../src/mapi/glapi -I/usr/include/libdrm      -g -O2
>> -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -g
>> -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
>> -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS
>> -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
>> -DGLX_DIRECT_RENDERING
>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE
>> -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
>> -DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\"
>> glxext.c -o glxext.o
>> glxext.c: In function ‘__glXWireToEvent’:
>> glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member named
>> ‘sbc_hi’
>> glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member named
>> ‘sbc_lo’
>> gmake[2]: *** [glxext.o] Error 1
>> gmake[2]: Leaving directory `/opt/mesa/src/glx'
>> gmake[1]: *** [subdirs] Error 1
>> gmake[1]: Leaving directory `/opt/mesa/src'
>> gmake: *** [default] Error 1
>>
>> I have waited for a few days to see if the problem had been solved after
>> some new commits, but I haven't noticed any, so I wanted to report my
>> problem here.
> 
> You might need new glproto header files.  I think there's been some
> protocol fixes recently.
> 
> -Brian
> 
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 
Hi Brian,
          I had updated
dri2proto,glproto,xcb-proto,resourceproto,scrnsaverproto,and X11proto from
the git reopositories. I had also re-compiled them with --prefix=/usr to be
installed on my system.

Sadly, it still fails to compile, the errors are still the same when I first
reported this problem.
Regards,
           STEVE555

-- 
View this message in context: http://old.nabble.com/Compiling-Mesa-from-git-%28just-build%2Cnot-installed%29-tp31569584p31621460.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] Compiling Mesa from git (just build, not installed)

[Brian P. <bri...@gm...>]

On Sun, May 8, 2011 at 3:01 AM, STEVE555 <ste...@ho...> wrote:
>
> Hi to all,
>          I have been regularly been building the git version of mesa with
> with the gallium-nouveau code enabled.
>
> I'm currently using Fedora Rawhide with the latest updates. I use the
> following ./autogen.sh options to set mesa for the build: ./autogen.sh
> --enable-debug --enable-glx-tls --enable-asm --with-dri-drivers=
> --enable-gallium-nouveau --disable-gallium-i915 --disable-gallium-i965
> --disable-egl --disable-gallium-r300  --disable-gallium-r600
> --disable-gallium-svga --with-state-trackers=glx,dri(and I sometimes add the
> xorg-state-tracker at the end).
>
> The trouble I'm having is after I believe after some commits for GLX, Mesa
> keeps ending with this build error:
>
> DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE
> -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
> -DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\"
> glxcmds.c -o glxcmds.o
> gcc -c -I. -I../../include -I../../include/GL/internal -I../../src/mesa
> -I../../src/mapi -I../../src/mapi/glapi -I/usr/include/libdrm      -g -O2
> -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -g
> -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
> -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS
> -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE
> -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
> -DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\"
> glxcurrent.c -o glxcurrent.o
> gcc -c -I. -I../../include -I../../include/GL/internal -I../../src/mesa
> -I../../src/mapi -I../../src/mapi/glapi -I/usr/include/libdrm      -g -O2
> -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -g
> -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
> -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS
> -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE
> -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
> -DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\"
> glxext.c -o glxext.o
> glxext.c: In function ‘__glXWireToEvent’:
> glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member named
> ‘sbc_hi’
> glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member named
> ‘sbc_lo’
> gmake[2]: *** [glxext.o] Error 1
> gmake[2]: Leaving directory `/opt/mesa/src/glx'
> gmake[1]: *** [subdirs] Error 1
> gmake[1]: Leaving directory `/opt/mesa/src'
> gmake: *** [default] Error 1
>
> I have waited for a few days to see if the problem had been solved after
> some new commits, but I haven't noticed any, so I wanted to report my
> problem here.

You might need new glproto header files.  I think there's been some
protocol fixes recently.

-Brian

[Mesa3d-dev] Compiling Mesa from git (just build,not installed)

[STEVE555 <ste...@ho...>]

Hi to all,
          I have been regularly been building the git version of mesa with
with the gallium-nouveau code enabled.

I'm currently using Fedora Rawhide with the latest updates. I use the
following ./autogen.sh options to set mesa for the build: ./autogen.sh
--enable-debug --enable-glx-tls --enable-asm --with-dri-drivers=
--enable-gallium-nouveau --disable-gallium-i915 --disable-gallium-i965
--disable-egl --disable-gallium-r300  --disable-gallium-r600
--disable-gallium-svga --with-state-trackers=glx,dri(and I sometimes add the
xorg-state-tracker at the end).

The trouble I'm having is after I believe after some commits for GLX, Mesa
keeps ending with this build error:

DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
-DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\"
glxcmds.c -o glxcmds.o
gcc -c -I. -I../../include -I../../include/GL/internal -I../../src/mesa
-I../../src/mapi -I../../src/mapi/glapi -I/usr/include/libdrm      -g -O2
-Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -g 
-fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
-DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\"
glxcurrent.c -o glxcurrent.o
gcc -c -I. -I../../include -I../../include/GL/internal -I../../src/mesa
-I../../src/mapi -I../../src/mapi/glapi -I/usr/include/libdrm      -g -O2
-Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -g 
-fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
-DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\"
glxext.c -o glxext.o
glxext.c: In function ‘__glXWireToEvent’:
glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member named
‘sbc_hi’
glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member named
‘sbc_lo’
gmake[2]: *** [glxext.o] Error 1
gmake[2]: Leaving directory `/opt/mesa/src/glx'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/opt/mesa/src'
gmake: *** [default] Error 1

I have waited for a few days to see if the problem had been solved after
some new commits, but I haven't noticed any, so I wanted to report my
problem here.

Regards,
           STEVE555 
-- 
View this message in context: http://old.nabble.com/Compiling-Mesa-from-git-%28just-build%2Cnot-installed%29-tp31569584p31569584.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72

[Brian P. <bri...@gm...>]

On Sat, Apr 23, 2011 at 5:15 PM, Dave Airlie <ai...@gm...> wrote:
> Hi Brian,
>
> st/mesa: check image size before copy_image_data_to_texture()
>
> This causes a regression with NPOT textures in fbo-generate-mipmaps on r600g.

You meant fbo-generate-mipmap-formats right?  fbo-generate-mipmaps works for me.

-Brian

Re: [Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72

[Dave A. <ai...@gm...>]

On Sun, Apr 24, 2011 at 10:08 AM, Marek Olšák <ma...@gm...> wrote:
>
> On Sun, Apr 24, 2011 at 1:15 AM, Dave Airlie <ai...@gm...> wrote:
>>
>> Hi Brian,
>>
>> st/mesa: check image size before copy_image_data_to_texture()
>>
>> This causes a regression with NPOT textures in fbo-generate-mipmaps on
>> r600g.
>
> FWIW r300g and softpipe are broken too. The issue seems to be
> driver-independent.
>

Testing 3 (NPOT)
wtf 293 277 1 vs 292 276 1
wtf 293 277 1 vs 292 276 1
wtf 293 277 1 vs 292 276 1

So the first set of values is from the stImage and the second set are
the minified values,
so we don't copy because they are off by one.

Dave.
> Marek
>

Re: [Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72

[Marek O. <ma...@gm...>]

On Sun, Apr 24, 2011 at 1:15 AM, Dave Airlie <ai...@gm...> wrote:

> Hi Brian,
>
> st/mesa: check image size before copy_image_data_to_texture()
>
> This causes a regression with NPOT textures in fbo-generate-mipmaps on
> r600g.
>

FWIW r300g and softpipe are broken too. The issue seems to be
driver-independent.

Marek

[Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72

[Dave A. <ai...@gm...>]

Hi Brian,

st/mesa: check image size before copy_image_data_to_texture()

This causes a regression with NPOT textures in fbo-generate-mipmaps on r600g.

Please don't put it into 7.10 until we can figure out why, but I'm
guessing the restrictions are too strict.

Dave.

[Mesa3d-dev] Fix infinite-recursion bug #32835

[Carl W. <cw...@cw...>]

Here's a patch to fix bug #32835 (and the corresponding
095-recursive-define test case in glsl/glcpp/tests).

I've tested this patch against all the tests in glsl/glcpp/tests. It
fixes the one bug and doesn't introduce any regressions caught by this
minimal test suite.

If someone could verify with piglit that this patch doesn't break
anything, then that would be helpful. And of course, any review would
be nice as well.

If the patch *does* break anything in piglit, then I'd love to see a
new test case added to glsl/glcpp/tests for that.

Thanks,

-Carl

[Mesa3d-dev] [PATCH] glcpp: Fix attempts to expand recursive macros infinitely (bug #32835).

[Carl W. <cw...@cw...>]

The 095-recursive-define test case was triggering infinite recursion
with the following test case:

	#define A(a, b) B(a, b)
	#define C A(0, C)
	C

Here's what as happening:

  1. "C" was pushed onto the active list to expand the C node

  2. While expanding the "0" argument, the active list would be
     emptied by the code at the end of _glcpp_parser_expand_token_list

  3. When expanding the "C" argument, the active list was now empty,
     so lather, rinse, repeat.

We fix this by adjusting the final popping at the end of
_glcpp_parser_expand_token_list to never pop more nodes then this
particular invocation had pushed itself. This is as simple as saving
the original state of the active list, and then interrupting the
popping when we reach this same state.

With this fix, all of the glcpp-test tests now pass.
---
 src/glsl/glcpp/glcpp-parse.y |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index fdc9467..6f15e85 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -1563,6 +1563,7 @@ _glcpp_parser_expand_token_list (glcpp_parser_t *parser,
 	token_node_t *node_prev;
 	token_node_t *node, *last = NULL;
 	token_list_t *expansion;
+	active_list_t *active_initial = parser->active;
 
 	if (list == NULL)
 		return;
@@ -1617,7 +1618,10 @@ _glcpp_parser_expand_token_list (glcpp_parser_t *parser,
 		node = node_prev ? node_prev->next : list->head;
 	}
 
-	while (parser->active)
+	/* Remove any lingering effects of this invocation on the
+	 * active list. That is, pop until the list looks like it did
+	 * at the beginning of this function. */
+	while (parser->active && parser->active != active_initial)
 		_parser_active_list_pop (parser);
 
 	list->non_space_tail = list->tail;
-- 
1.7.4.1

Re: [Mesa3d-dev] [Mesa-dev] [PATCH 0/6] ARB_texture_float

[Sven A. <sa...@wh...>]

On Fri, 2011-04-01 at 17:14 +0200, Philipp Klaus Krause wrote:
> Would there be a way to make this switch easier to flip by the user? As
> you state it this looks like a lot of work to users that want to have it
> enabled, at least when compared to the effort to get S3TC support.

According to this, an external library could be used for float textures,
but not for render targets:
http://www.x.org/wiki/Events/XDC2009/Notes#idr.3AOpenGL3andMesa

Most users (or at least the ones needing more than GL2) will probably
get binaries from some unofficial repository. Similar to how the
situation with H264 coders (and/or decoders) are handled today.

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22

Re: [Mesa3d-dev] [Mesa-dev] [PATCH 0/6] ARB_texture_float

[Marek O. <ma...@gm...>]

There won't be any other way. It should be the Linux distributors' decision
whether their users can use it or not.

Marek

On Fri, Apr 1, 2011 at 5:14 PM, Philipp Klaus Krause <pk...@sp...> wrote:

> Am 01.04.2011 15:56, schrieb Marek Olšák:
> > Hi,
> >
> > please read on.
> >
> > This patch series adds the last pieces of ARB_texture_float support
> > to Mesa and Gallium.
> >
> > The thing is Mesa and Gallium more or less already support float
> > textures and renderbuffers in master. Gallium has full floating-point
> > support in the interface and if it was a public API, people could
> > just expose it and not care. There is clearly a need for a configure
> > switch which can hide float renderbuffers from any interface, public
> > or private, and driver developers should use such a switch.
>
> Would there be a way to make this switch easier to flip by the user? As
> you state it this looks like a lot of work to users that want to have it
> enabled, at least when compared to the effort to get S3TC support.
>
> Philipp
>

Re: [Mesa3d-dev] [Mesa-dev] [PATCH 0/6] ARB_texture_float

[Philipp K. K. <pk...@sp...>]

Am 01.04.2011 15:56, schrieb Marek Olšák:
> Hi,
> 
> please read on.
> 
> This patch series adds the last pieces of ARB_texture_float support
> to Mesa and Gallium.
> 
> The thing is Mesa and Gallium more or less already support float
> textures and renderbuffers in master. Gallium has full floating-point
> support in the interface and if it was a public API, people could
> just expose it and not care. There is clearly a need for a configure
> switch which can hide float renderbuffers from any interface, public
> or private, and driver developers should use such a switch.

Would there be a way to make this switch easier to flip by the user? As
you state it this looks like a lot of work to users that want to have it
enabled, at least when compared to the effort to get S3TC support.

Philipp

Re: [Mesa3d-dev] Noise

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/21/2011 12:41 PM, Philipp Klaus Krause wrote:
> FYI, there now is a good (no textures or arrays) implementation of GLSL
> simplex noise. Unfortunately it's currently under the Artistic license,
> but if the author could be convinced to release it under a freer
> license, or someone reimplements it this could be useful in the free
> drivers.
> 
> Philipp
> 
> http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=293508&page=1

I posted a good implementation of noise to the mesa3d-dev mailing list
several years ago.  The existence of GLSL implementations isn't the
problem.  The problem is that any noise implementation generates a giant
pile of instructions.  This caused problems with the old Mesa GLSL
compiler for a couple of reasons, and the biggest was that it made the
register allocator very angry.  It wanted to use something like 200
temporaries just for the noise code.

In addition, if a program uses noise multiple times, you probably don't
want it to be inlined.  The new Mesa GLSL compiler doesn't handle
non-inlined functions very well.  Everything is inlined all the time.  I
made a post last week (or the week before?) about how the infrastructure
could be changed to enable fixing this.  Ken has done some work (in his
'fortran' branch) to implement a function calling convention that
matches the language and will work on a GPU.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2H1ooACgkQX1gOwKyEAw+pywCggS6K2FozsrN3uwapGfJa3tpg
qtYAoJy+J13w73l7zsC32X11ohcSxgrK
=6/2w
-----END PGP SIGNATURE-----

[Mesa3d-dev] Noise

[Philipp K. K. <pk...@sp...>]

FYI, there now is a good (no textures or arrays) implementation of GLSL
simplex noise. Unfortunately it's currently under the Artistic license,
but if the author could be convinced to release it under a freer
license, or someone reimplements it this could be useful in the free
drivers.

Philipp

http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=293508&page=1

[Mesa3d-dev] piglit: add test for depth-only array textures

[Christoph B. <e04...@st...>]

Patch attached.

Fails with current mesa because GL_DEPTH_COMPONENT is not accepted for
array and cube textures.
Passes on nvc0 if I allow it, but swrast fails somehow (even if the
output looks correct).

Re: [Mesa3d-dev] [mesa] master broken with "make -j3"

[Sedat D. <sed...@go...>]

On Fri, Feb 11, 2011 at 2:45 PM, Sedat Dilek <sed...@go...> wrote:
> Hi,
>
> yesterdays (aprrox 24hrs ago) mesa master was OK for building with
> "make -j3" on my IBM T41p (Pentium-M, 1G RAM, radeon RV250), now it's
> broken:
>
> gcc: ../../src/glsl/libglsl.a: No such file or directory
> make[2]: *** [glcpp/glcpp] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: Leaving directory `/home/sd/src/mesa/mesa/src/glsl'
>
> Building the "normal" way (aka "make -j1") runs fine, but parallel
> building seems to be f-up-ed.
>
> Tested with mesa master...
>
> commit 6ed0f2ac112d22278cf051c2cee9c2199a9025ea
> Author: José Fonseca <jfo...@vm...>
>
>    svga: Enable the draw pipeline for smooth lines.
>
> My autogen-line looks like this...
>
> ./autogen.sh --prefix=/usr --with-driver=dri
> --with-dri-driverdir=/usr/lib/dri --with-dri-drivers=r200
> --disable-gallium --disable-egl --disable-glu --disable-glut
> --disable-glw --enable-glx-tls --enable-debug
>
> I am just speculating on the commit of Kenneth:
>
> commit e0c1fc32832b66b52e6352ba563288ee48a1face
> "glsl/Makefile: glcpp doesn't need libglsl.a."
>
> I haven't tested by reverting from new to old:
>
> New: +glcpp/glcpp: $(GLCPP_OBJECTS)
> Old: -glcpp/glcpp: $(GLCPP_OBJECTS) libglsl.a
>
> Maybe someone can confirm the breakage.
>
> Regards,
> - Sedat -
>

With attached revert-patch (revert commit by Kenneth, see above)
parallel-build is OK, again.

- Sedat -

[Mesa3d-dev] [mesa] master broken with "make -j3"

[Sedat D. <sed...@go...>]

Hi,

yesterdays (aprrox 24hrs ago) mesa master was OK for building with
"make -j3" on my IBM T41p (Pentium-M, 1G RAM, radeon RV250), now it's
broken:

gcc: ../../src/glsl/libglsl.a: No such file or directory
make[2]: *** [glcpp/glcpp] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/sd/src/mesa/mesa/src/glsl'

Building the "normal" way (aka "make -j1") runs fine, but parallel
building seems to be f-up-ed.

Tested with mesa master...

commit 6ed0f2ac112d22278cf051c2cee9c2199a9025ea
Author: José Fonseca <jfo...@vm...>

    svga: Enable the draw pipeline for smooth lines.

My autogen-line looks like this...

./autogen.sh --prefix=/usr --with-driver=dri
--with-dri-driverdir=/usr/lib/dri --with-dri-drivers=r200
--disable-gallium --disable-egl --disable-glu --disable-glut
--disable-glw --enable-glx-tls --enable-debug

I am just speculating on the commit of Kenneth:

commit e0c1fc32832b66b52e6352ba563288ee48a1face
"glsl/Makefile: glcpp doesn't need libglsl.a."

I haven't tested by reverting from new to old:

New: +glcpp/glcpp: $(GLCPP_OBJECTS)
Old: -glcpp/glcpp: $(GLCPP_OBJECTS) libglsl.a

Maybe someone can confirm the breakage.

Regards,
- Sedat -

[Mesa3d-dev] A Question of Display Lists

[Dee S. <dem...@ne...>]

 From an implementation standpoint, is there a sure-fire way to know if an OGL function  is a client-state function? Is there a list somewhere that's broken down into which commands are client-state vs server-state?

 

Dee Sharpe

People deserve more,
from themselves & from each other!

Re: [Mesa3d-dev] [RFC] Draw module optimizations

[Brian P. <br...@vm...>]

On 01/23/2011 10:30 PM, Jakob Bornecrantz wrote:
> Hi all
>
> I have pushed some draw module changes here
> http://cgit.freedesktop.org/~wallbraker/mesa/log/?h=i915g-speed&showmsg=1
> which improves speed in the draw module by avoiding unneeded flushing
> and setup on draw calls.
>
> The first two commits (starting from the bottom, right after master)
> doesn't yield much improvements especially after the last commit.
>
> Remove_reduce_prim is required as any call to draw_do_flush would
> result in the following call draw_vbo would be called with
> STATE_CHANGE, which with the last commit would call into prepare when
> it is not needed.
>
> The last commit is the one that does the biggest difference. As it is
> the one that stops prepare from being called on every draw_vbo call.
> And as a side effect removes the last draw_do_flush call, enabling at
> last the pipeline to gather up vertices from several draw_vbo calls
> into a single draw_elements. The paste below shows the difference,
> first column are from the test application (tests/step that I just
> pushed), the rest are either from i915g or draw, it should be obvious
> which is which.
>
> http://pastebin.com/5i3BejgJ
>
> A follow up to these changes would be try to unify draw_pipe_vbuf and
> draw_pt_emit into a single file or to refractor code into a single
> vbuf primitive collector that would allow draw_arrays calls to be
> grouped into a single vbuf_render->draw_arrays call (provided
> primitive can be combined). This would improve draw_pt_emit_run_linear
> performance on draw heavy applications. I guess one could also look
> into merging draw_elements with each other by manipulating indices
> (between draw_pt_emit and the pipeline). As well as draw_arrays and
> draw_elements by doing the same.
>
> Comments please.

Jakob,

I pulled your branch and tested with piglit with llvmpipe.  Looks like 
there's a number of regressions in the "general" catagory:

general/bgra-sec-color-pointer
general/bgra-vert-attrib-pointer
general/draw-batch
general/draw-elements
general/draw-vertices
general/primitive-restart
etc.

You can run this group of tests with:

./piglit-run.py -t ^general tests/all.tests results/new

I suspect that either the reduced prim removal or one of the new 
conditionals put around the flushing code is at fault.

Otherwise, this patch series looks like good stuff.

-Brian

[Mesa3d-dev] [RFC] Draw module optimizations

[Jakob B. <wal...@gm...>]

Hi all

I have pushed some draw module changes here
http://cgit.freedesktop.org/~wallbraker/mesa/log/?h=i915g-speed&showmsg=1
which improves speed in the draw module by avoiding unneeded flushing
and setup on draw calls.

The first two commits (starting from the bottom, right after master)
doesn't yield much improvements especially after the last commit.

Remove_reduce_prim is required as any call to draw_do_flush would
result in the following call draw_vbo would be called with
STATE_CHANGE, which with the last commit would call into prepare when
it is not needed.

The last commit is the one that does the biggest difference. As it is
the one that stops prepare from being called on every draw_vbo call.
And as a side effect removes the last draw_do_flush call, enabling at
last the pipeline to gather up vertices from several draw_vbo calls
into a single draw_elements. The paste below shows the difference,
first column are from the test application (tests/step that I just
pushed), the rest are either from i915g or draw, it should be obvious
which is which.

http://pastebin.com/5i3BejgJ

A follow up to these changes would be try to unify draw_pipe_vbuf and
draw_pt_emit into a single file or to refractor code into a single
vbuf primitive collector that would allow draw_arrays calls to be
grouped into a single vbuf_render->draw_arrays call (provided
primitive can be combined). This would improve draw_pt_emit_run_linear
performance on draw heavy applications. I guess one could also look
into merging draw_elements with each other by manipulating indices
(between draw_pt_emit and the pipeline). As well as draw_arrays and
draw_elements by doing the same.

Comments please.

Cheers Jakob.

Re: [Mesa3d-dev] [PATCH] invalidate dri2 buffers more often/pageflip related screen flickering

[Jesse B. <jb...@vi...>]

On Sat,  8 Jan 2011 16:02:09 +0100
Daniel Vetter <dan...@ff...> wrote:

> Hi all,
> 
> I've been tracking down an annoying flickering problem on intel hw
> that completely disappears with vblank_mode=0. Some add-hoc tracing
> all over the stack shows that the pageflip and the render stalling on
> the new backbuffer all happen correctly. But rendering always happens
> to the _same_ buffer, with the obvious effects of garbage (often just
> black) on every second frame and flickering on the other frames due
> to frontbuffer rendering.
> 
> Attached is the minimal (and likely incorrect) patch that fixes this
> for me.
> 
> Software stack: Everything latest git, safe for the X server, that's
> 1.9.3 as provided by Fedora 14. Problem also exists on 1.9.2 from
> debian experimental.  Problem reproducible on all my intel hw,
> irrespective of DE and composition manager.
> 
> Some enlightenment preferably in the form of a proper fix highly
> appreciated ;)

I've seen this too, but last time it was due to me building with old
dri2proto and/or glproto, so Mesa and the server weren't doing the
right thing...

Re: [Mesa3d-dev] [PATCH 0/6] [RFC] Formalization of the Gallium shader semantics linkage model

[Christoph B. <e04...@st...>]

On 17.12.2010 17:54, Marek Olšák wrote:
> On Fri, Dec 17, 2010 at 4:32 PM, Brian Paul <br...@vm...
> <mailto:br...@vm...>> wrote:
>
>     Christoph,
>
>     I don't see a patch for the st/mesa program translation code to check
>     that we don't exceed the limit.  Were you going to take care of
>     that too?
>
I didn't plan to for now, at least nothing beyond making the state
tracker return an error if possible, and removing/modifying a certain
comment mentioned below.

>     I guess we're assuming that the max number of generic inputs == max
>     number of generic outputs.  I think that's OK until a counter case
>     appears.
>
>
> The way I understand it is that the max number of generic outputs is
> equal to the max number of generic inputs in the next shader stage
> (the same logic applies to some other shader caps too). I guess we
> need to use get_param to determine which shader stages are supported
> by the driver to know which one is next. The name
The problem is that (apart from the linked GL program case) you cannot
know which stage is next until validation time.
You have the same problem with the existing
PIPE_SHADER_CAP_MAX_INPUTS/OUTPUTS - nv50's vertex shaders can output
more variables to geometry shaders than they can to vertex shaders.

Maybe MAX_GENERIC_INDEX should be a non-shader specific cap - for nvc0
the value is the same everywhere, and for hardware that only has VP and
FP as well.

> *PIPE_SHADER_CAP_MAX_GENERIC_INPUT_INDEX* would be less ambiguous
> (still not perfect though).
>
I thought about using something even more verbose, like
PIPE_SHADER_CAP_MAX_GENERIC_INPUT_SEMANTIC_INDEX.

> However I don't believe in usefulness of this new cap, at least not
> without some serious state tracker work. I don't consider failing to
> translate a shader if some CAP is too low particularly useful.
>
The use of the cap is to prevent state tracker writers from thinking
they're free to use GENERIC[0,96,8911] or whatever random numbers they
like and rely on pipe drivers to ensure at all costs that linkage will
be correct.

In mesa/st I see the comment
/* Actually, let's try and zero-base this just for
 * readability of the generated TGSI.
 */
So I guess someone thought it would be ok to start at some unspecified
high index. Such random behaviour makes it really hard to get
ARB_separate_shader_objects features (which galliums assumed pipe
drivers would be able to do anyway from the start) sanely.

---

So, maybe we can do without this cap. Maybe it would be better to just
mandate that the GENERIC index be less than
PIPE_SHADER_CAP_MAX_INPUTS/OUTPUTS after all.

Christoph

> (posting to mesa-dev as well)
>
> Marek
>
>
>     -Brian
>
>
>     On 12/17/2010 05:28 AM, Keith Whitwell wrote:
>     > Christoph,
>     >
>     > This looks good.  Thanks for bringing this back to life.
>     >
>     > Keith
>     >
>     > On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller wrote:
>     >> On 12/14/2010 12:36 PM, Keith Whitwell wrote:
>     >>> On Mon, 2010-12-13 at 12:01 -0800, Christoph Bumiller wrote:
>     >>>> I want to warm this up again adding nvc0 and
>     >>>> GL_ARB_separate_shader_objects to the picture.
>     >>>>
>     >>>> The latter extends GL_EXT_separate_shader_objects to support user
>     >>>> defined varyings and guarantees well defined behaviour only if
>     >>>> - varyings are declared inside the
>     gl_PerVertex/gl_PerFragment block the
>     >>>> blocks match exactly in name, type, qualification, and (most
>     >>>> significantly) declaration order.
>     >>>> - varyings are assigned matching location qualifiers:
>     >>>> like: layout(location = 3) in vec4 normal
>     >>>> "The number of input locations available to a shader is limited."
>     >>>>
>     >>>> So, I propose to (loosely) identify GENERIC semantic indices
>     with these
>     >>>> location qualifiers and let the pipe driver set a limit on
>     the allowed
>     >>>> maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS, and not demand to at
>     least
>     >>>> support 219 of them - nvc0 offsers 0x200 bytes for generic
>     inputs/outputs).
>     >>>
>     >>> This sounds fine actually.  We kicked this around before&  I was
>     >>> basically ok with the last iteration of the proposal, but this
>     seems ok
>     >>> too.
>     >>>
>     >>> As far as I can tell from a gallium perspective you're really just
>     >>> proposing a new pipe cap _MAX_INPUTS (actually
>     _MAX_GENERIC_INDEX would
>     >>> be clearer), which the state tracker thereafter has to respect?
>     >>>
>     >>> That would be fine with me.
>     >> First attempt at a patch introducing such a cap attached.
>     >>
>     >>>
>     >>>> My motivation is mostly that the hardware routing table for
>     shader
>     >>>> varyings that was present on nv50 has been removed with nvc0
>     (Fermi).
>     >>>> And I'm glad, because filling 4 routing tables (since we have
>     5 shader
>     >>>> types now) is somewhat annoying. And so applying relocations
>     to shaders
>     >>>> - it can be done, it's probably not too time consuming, but
>     it's just
>     >>>> plain *unnecessary* (and thus stupid) for OpenGL.
>     >>>>
>     >>>> Now about d3d9 ...
>     >>>> 1. don't care, I don't see a d3d9 state tracker
>     >>>> 2.
>     http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx
>     >>>> says "n is an optional integer between 0 and the number of
>     resources
>     >>>> supported" - what "supported" means here isn't clear to me,
>     but, I
>     >>>> didn't find any example where someone used something OpenGL
>     doesn't have
>     >>>> (like COLOR2).
>     >>>> 3.
>     >>>>
>     http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics
>     >>>> says "Input semantics are similar to the values in the
>     D3DDECLUSAGE."
>     >>>> and
>     >>>> DECLUSAGE sounds like you're limited to sane values.
>     >>>
>     >>> I think you're on the right track with (1)...  It's fairly
>     pointless
>     >>> trying to discuss code here which isn't public&  I don't think
>     people
>     >>> need to be worrying about what may or may not be important for
>     code they
>     >>> can't see.
>     >>>
>     >>> I know this idea previously got tied up with speculation about
>     what a
>     >>> DX9 state tracker might or might not require, but in
>     retrospect I wish
>     >>> I'd been able to steer conversation away from that.
>     >>>
>     >>> The work on closed components may drive a lot of the feature
>     development
>     >>> and new interfaces, but there's usually enough flexibility
>     that this
>     >>> sort of cleanup isn't a big deal.
>     >>>
>     >>>
>     >>> Keith
>     >>>
>     >>>> Not sure if anyone wants to think about this issue at this
>     time (since
>     >>>> implementation of ARB_separate_shader_objects is probably far
>     in the GL4
>     >>>> future), but I'd be happy about any comments.
>     >>>>
>     >>>> Regards,
>     >>>> Christoph
>     >>>>
>     >>>> On 04/13/2010 12:55 PM, Luca Barbieri wrote:
>     >>>>> This patch series is intended to resolve the issue of
>     semantic-based shader linkage in Gallium.
>     >>>>> It can also be found in the RFC-gallium-semantics branch.
>     >>>>>
>     >>>>> It does not change the current Gallium design, but rather
>     formalizes some limitations to it, and provides infrastructure to
>     implement this model more easily in drivers, along with a full
>     nv30/nv40 implementation.
>     >>>>>
>     >>>>> These limitations are added to allow an efficient
>     implementation for both hardware lacking special support and
>     hardware having support but also special constraints.
>     >>>>>
>     >>>>> Note that this does NOT resolve all issues, and there are
>     quite a bit left to future refinement.
>     >>>>>
>     >>>>> In particular, the following issues are still open:
>     >>>>> 1. COLOR clamping (and floating point framebuffers)
>     >>>>> 2. A linkage table CSO allowing to specify non-identity linkage
>     >>>>> 3. BCOLOR/FACE-related issues
>     >>>>> 4. Adding a cap to inform the state tracker that more than
>     219 generic indices are provided
>     >>>>>
>     >>>>> This topic was already very extensively discussed.
>     >>>>> See
>     http://www.mail-archive.com/mes...@li.../msg10865.html
>     for some early inconclusive discussion around an early
>     implementation that modified the GLSL linker (which is NOT being
>     proposed here)
>     >>>>> See
>     http://www.mail-archive.com/mes...@li.../msg12016.html
>     for some more discussion that seemed to mostly reach a consensus
>     over the approach proposed here.
>     >>>>> See in particular
>     http://www.mail-archive.com/mes...@li.../msg12041.html
>     .
>     >>>>>
>     >>>>> That said, I'm going to try to repeat all information here,
>     partially by copy&pasting from earlier messages.
>     >>>>> This message should probably be adapted into gallium/docs
>     if/when this is accepted.
>     >>>>>
>     >>>>> Here is the short summary; the long rationale follows after it.
>     >>>>>
>     >>>>> The proposal here is to add the following limitations to
>     Gallium, for the intermediate semantics:
>     >>>>> 1. TGSI_SEMANTIC_NORMAL is removed, using a commit by Michal
>     Krol that was never merged
>     >>>>> 2. Every semantic except GENERIC, COLOR and BCOLOR can only
>     be used with semantic index 0
>     >>>>> 3. COLOR and BCOLOR can only be used with semantic index 0-1
>     (note that this doesn't apply to fragment outputs)
>     >>>>> 4. GENERIC can be used with semantic indices 0-218 on any
>     driver, if BCOLOR is not used
>     >>>>> 5. GENERIC can be used with semantic indices 0-216 on any
>     driver, if BCOLOR IS used
>     >>>>> 6. GENERIC can be used with semantic indices 0-255 on almost
>     all drivers (those that don't need the 0-218 limitation)
>     >>>>> 7. Some drivers may also choose to support GENERIC with
>     arbitrary indices, but that should generally not happen
>     >>>>>
>     >>>>> The reason of this, in short, is that this maps directly to
>     DirectX 9 SM3, which is the most problematic interface of all.
>     >>>>>
>     >>>>> The peculiar problem we have here is that we have two
>     competing constraints that force us into choosing the exact SM3 value:
>     >>>>> 1. The VMware SVGA driver must deal with an SM3 host
>     interface and would ideally want to directly feed the Gallium
>     semantics to the host
>     >>>>> 2. An hypotetical DirectX 9 state tracker needs to support
>     SM3 and would ideally want to directly feed the SM3 semantics to
>     Gallium
>     >>>>>
>     >>>>> Note that this is not a reference to the VMware DirectX 9
>     state tracker, since its authors haven't provided details about
>     its handling of shader semantics.
>     >>>>>
>     >>>>> SM3 ends up supporting 219 generic indices: 16 indices in 14
>     classes, minus POSITION0, PSIZE0, COLOR0, COLOR1 and FOG0 which
>     are the only ones that wouldn't be mapped to GENERIC.
>     >>>>> However, Gallium drivers that don't benefit from having
>     specific contraints (like svga and r600) are supposed to support
>     256 indices, and my nv30/nv40 work does that.
>     >>>>>
>     >>>>> The expected implementation, if no hardware support exists,
>     is to build a list of relocations to apply to either the fragment
>     or the vertex shader, and patch one of them at validation time to
>     match the other.
>     >>>>> Data structures are provided in gallium/auxiliary to ease
>     this, and try to minimize the number of times where this needs to
>     be performed.
>     >>>>>
>     >>>>> Let's now proceed to the discussion and detailed rationale,
>     mostly constructed by copy&pasting older messages.
>     >>>>> ...
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Lotusphere 2011
>     > Register now for Lotusphere 2011 and learn how
>     > to connect the dots, take your collaborative environment
>     > to the next level, and enter the era of Social Business.
>     > http://p.sf.net/sfu/lotusphere-d2d
>     > _______________________________________________
>     > Mesa3d-dev mailing list
>     > Mes...@li...
>     <mailto:Mes...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>     > .
>     >
>
>
>     ------------------------------------------------------------------------------
>     Lotusphere 2011
>     Register now for Lotusphere 2011 and learn how
>     to connect the dots, take your collaborative environment
>     to the next level, and enter the era of Social Business.
>     http://p.sf.net/sfu/lotusphere-d2d
>     _______________________________________________
>     Mesa3d-dev mailing list
>     Mes...@li...
>     <mailto:Mes...@li...>
>     https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>

Re: [Mesa3d-dev] [PATCH 0/6] [RFC] Formalization of the Gallium shader semantics linkage model

[Marek O. <ma...@gm...>]

On Fri, Dec 17, 2010 at 4:32 PM, Brian Paul <br...@vm...> wrote:

> Christoph,
>
> I don't see a patch for the st/mesa program translation code to check
> that we don't exceed the limit.  Were you doing to take care of that too?
>
> I guess we're assuming that the max number of generic inputs == max
> number of generic outputs.  I think that's OK until a counter case
> appears.
>

The way I understand it is that the max number of generic outputs is equal
to the max number of generic inputs in the next shader stage (the same logic
applies to some other shader caps too). I guess we need to use get_param to
determine which shader stages are supported by the driver to know which one
is next. The name *PIPE_SHADER_CAP_MAX_GENERIC_INPUT_INDEX* would be less
ambiguous (still not perfect though).

However I don't believe in usefulness of this new cap, at least not without
some serious state tracker work. I don't consider failing to translate a
shader if some CAP is too low particularly useful.

(posting to mesa-dev as well)

Marek


> -Brian
>
>
> On 12/17/2010 05:28 AM, Keith Whitwell wrote:
> > Christoph,
> >
> > This looks good.  Thanks for bringing this back to life.
> >
> > Keith
> >
> > On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller wrote:
> >> On 12/14/2010 12:36 PM, Keith Whitwell wrote:
> >>> On Mon, 2010-12-13 at 12:01 -0800, Christoph Bumiller wrote:
> >>>> I want to warm this up again adding nvc0 and
> >>>> GL_ARB_separate_shader_objects to the picture.
> >>>>
> >>>> The latter extends GL_EXT_separate_shader_objects to support user
> >>>> defined varyings and guarantees well defined behaviour only if
> >>>> - varyings are declared inside the gl_PerVertex/gl_PerFragment block
> the
> >>>> blocks match exactly in name, type, qualification, and (most
> >>>> significantly) declaration order.
> >>>> - varyings are assigned matching location qualifiers:
> >>>> like: layout(location = 3) in vec4 normal
> >>>> "The number of input locations available to a shader is limited."
> >>>>
> >>>> So, I propose to (loosely) identify GENERIC semantic indices with
> these
> >>>> location qualifiers and let the pipe driver set a limit on the allowed
> >>>> maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS, and not demand to at least
> >>>> support 219 of them - nvc0 offsers 0x200 bytes for generic
> inputs/outputs).
> >>>
> >>> This sounds fine actually.  We kicked this around before&  I was
> >>> basically ok with the last iteration of the proposal, but this seems ok
> >>> too.
> >>>
> >>> As far as I can tell from a gallium perspective you're really just
> >>> proposing a new pipe cap _MAX_INPUTS (actually _MAX_GENERIC_INDEX would
> >>> be clearer), which the state tracker thereafter has to respect?
> >>>
> >>> That would be fine with me.
> >> First attempt at a patch introducing such a cap attached.
> >>
> >>>
> >>>> My motivation is mostly that the hardware routing table for shader
> >>>> varyings that was present on nv50 has been removed with nvc0 (Fermi).
> >>>> And I'm glad, because filling 4 routing tables (since we have 5 shader
> >>>> types now) is somewhat annoying. And so applying relocations to
> shaders
> >>>> - it can be done, it's probably not too time consuming, but it's just
> >>>> plain *unnecessary* (and thus stupid) for OpenGL.
> >>>>
> >>>> Now about d3d9 ...
> >>>> 1. don't care, I don't see a d3d9 state tracker
> >>>> 2. http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx
> >>>> says "n is an optional integer between 0 and the number of resources
> >>>> supported" - what "supported" means here isn't clear to me, but, I
> >>>> didn't find any example where someone used something OpenGL doesn't
> have
> >>>> (like COLOR2).
> >>>> 3.
> >>>>
> http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics
> >>>> says "Input semantics are similar to the values in the D3DDECLUSAGE."
> >>>> and
> >>>> DECLUSAGE sounds like you're limited to sane values.
> >>>
> >>> I think you're on the right track with (1)...  It's fairly pointless
> >>> trying to discuss code here which isn't public&  I don't think people
> >>> need to be worrying about what may or may not be important for code
> they
> >>> can't see.
> >>>
> >>> I know this idea previously got tied up with speculation about what a
> >>> DX9 state tracker might or might not require, but in retrospect I wish
> >>> I'd been able to steer conversation away from that.
> >>>
> >>> The work on closed components may drive a lot of the feature
> development
> >>> and new interfaces, but there's usually enough flexibility that this
> >>> sort of cleanup isn't a big deal.
> >>>
> >>>
> >>> Keith
> >>>
> >>>> Not sure if anyone wants to think about this issue at this time (since
> >>>> implementation of ARB_separate_shader_objects is probably far in the
> GL4
> >>>> future), but I'd be happy about any comments.
> >>>>
> >>>> Regards,
> >>>> Christoph
> >>>>
> >>>> On 04/13/2010 12:55 PM, Luca Barbieri wrote:
> >>>>> This patch series is intended to resolve the issue of semantic-based
> shader linkage in Gallium.
> >>>>> It can also be found in the RFC-gallium-semantics branch.
> >>>>>
> >>>>> It does not change the current Gallium design, but rather formalizes
> some limitations to it, and provides infrastructure to implement this model
> more easily in drivers, along with a full nv30/nv40 implementation.
> >>>>>
> >>>>> These limitations are added to allow an efficient implementation for
> both hardware lacking special support and hardware having support but also
> special constraints.
> >>>>>
> >>>>> Note that this does NOT resolve all issues, and there are quite a bit
> left to future refinement.
> >>>>>
> >>>>> In particular, the following issues are still open:
> >>>>> 1. COLOR clamping (and floating point framebuffers)
> >>>>> 2. A linkage table CSO allowing to specify non-identity linkage
> >>>>> 3. BCOLOR/FACE-related issues
> >>>>> 4. Adding a cap to inform the state tracker that more than 219
> generic indices are provided
> >>>>>
> >>>>> This topic was already very extensively discussed.
> >>>>> See
> http://www.mail-archive.com/mes...@li.../msg10865.htmlfor some early inconclusive discussion around an early implementation that
> modified the GLSL linker (which is NOT being proposed here)
> >>>>> See
> http://www.mail-archive.com/mes...@li.../msg12016.htmlfor some more discussion that seemed to mostly reach a consensus over the
> approach proposed here.
> >>>>> See in particular
> http://www.mail-archive.com/mes...@li.../msg12041.html.
> >>>>>
> >>>>> That said, I'm going to try to repeat all information here, partially
> by copy&pasting from earlier messages.
> >>>>> This message should probably be adapted into gallium/docs if/when
> this is accepted.
> >>>>>
> >>>>> Here is the short summary; the long rationale follows after it.
> >>>>>
> >>>>> The proposal here is to add the following limitations to Gallium, for
> the intermediate semantics:
> >>>>> 1. TGSI_SEMANTIC_NORMAL is removed, using a commit by Michal Krol
> that was never merged
> >>>>> 2. Every semantic except GENERIC, COLOR and BCOLOR can only be used
> with semantic index 0
> >>>>> 3. COLOR and BCOLOR can only be used with semantic index 0-1 (note
> that this doesn't apply to fragment outputs)
> >>>>> 4. GENERIC can be used with semantic indices 0-218 on any driver, if
> BCOLOR is not used
> >>>>> 5. GENERIC can be used with semantic indices 0-216 on any driver, if
> BCOLOR IS used
> >>>>> 6. GENERIC can be used with semantic indices 0-255 on almost all
> drivers (those that don't need the 0-218 limitation)
> >>>>> 7. Some drivers may also choose to support GENERIC with arbitrary
> indices, but that should generally not happen
> >>>>>
> >>>>> The reason of this, in short, is that this maps directly to DirectX 9
> SM3, which is the most problematic interface of all.
> >>>>>
> >>>>> The peculiar problem we have here is that we have two competing
> constraints that force us into choosing the exact SM3 value:
> >>>>> 1. The VMware SVGA driver must deal with an SM3 host interface and
> would ideally want to directly feed the Gallium semantics to the host
> >>>>> 2. An hypotetical DirectX 9 state tracker needs to support SM3 and
> would ideally want to directly feed the SM3 semantics to Gallium
> >>>>>
> >>>>> Note that this is not a reference to the VMware DirectX 9 state
> tracker, since its authors haven't provided details about its handling of
> shader semantics.
> >>>>>
> >>>>> SM3 ends up supporting 219 generic indices: 16 indices in 14 classes,
> minus POSITION0, PSIZE0, COLOR0, COLOR1 and FOG0 which are the only ones
> that wouldn't be mapped to GENERIC.
> >>>>> However, Gallium drivers that don't benefit from having specific
> contraints (like svga and r600) are supposed to support 256 indices, and my
> nv30/nv40 work does that.
> >>>>>
> >>>>> The expected implementation, if no hardware support exists, is to
> build a list of relocations to apply to either the fragment or the vertex
> shader, and patch one of them at validation time to match the other.
> >>>>> Data structures are provided in gallium/auxiliary to ease this, and
> try to minimize the number of times where this needs to be performed.
> >>>>>
> >>>>> Let's now proceed to the discussion and detailed rationale, mostly
> constructed by copy&pasting older messages.
> >>>>> ...
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Lotusphere 2011
> > Register now for Lotusphere 2011 and learn how
> > to connect the dots, take your collaborative environment
> > to the next level, and enter the era of Social Business.
> > http://p.sf.net/sfu/lotusphere-d2d
> > _______________________________________________
> > Mesa3d-dev mailing list
> > Mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> > .
> >
>
>
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>

Re: [Mesa3d-dev] [PATCH 0/6] [RFC] Formalization of the Gallium shader semantics linkage model

[Brian P. <br...@vm...>]

Christoph,

I don't see a patch for the st/mesa program translation code to check 
that we don't exceed the limit.  Were you doing to take care of that too?

I guess we're assuming that the max number of generic inputs == max 
number of generic outputs.  I think that's OK until a counter case 
appears.

-Brian


On 12/17/2010 05:28 AM, Keith Whitwell wrote:
> Christoph,
>
> This looks good.  Thanks for bringing this back to life.
>
> Keith
>
> On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller wrote:
>> On 12/14/2010 12:36 PM, Keith Whitwell wrote:
>>> On Mon, 2010-12-13 at 12:01 -0800, Christoph Bumiller wrote:
>>>> I want to warm this up again adding nvc0 and
>>>> GL_ARB_separate_shader_objects to the picture.
>>>>
>>>> The latter extends GL_EXT_separate_shader_objects to support user
>>>> defined varyings and guarantees well defined behaviour only if
>>>> - varyings are declared inside the gl_PerVertex/gl_PerFragment block the
>>>> blocks match exactly in name, type, qualification, and (most
>>>> significantly) declaration order.
>>>> - varyings are assigned matching location qualifiers:
>>>> like: layout(location = 3) in vec4 normal
>>>> "The number of input locations available to a shader is limited."
>>>>
>>>> So, I propose to (loosely) identify GENERIC semantic indices with these
>>>> location qualifiers and let the pipe driver set a limit on the allowed
>>>> maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS, and not demand to at least
>>>> support 219 of them - nvc0 offsers 0x200 bytes for generic inputs/outputs).
>>>
>>> This sounds fine actually.  We kicked this around before&  I was
>>> basically ok with the last iteration of the proposal, but this seems ok
>>> too.
>>>
>>> As far as I can tell from a gallium perspective you're really just
>>> proposing a new pipe cap _MAX_INPUTS (actually _MAX_GENERIC_INDEX would
>>> be clearer), which the state tracker thereafter has to respect?
>>>
>>> That would be fine with me.
>> First attempt at a patch introducing such a cap attached.
>>
>>>
>>>> My motivation is mostly that the hardware routing table for shader
>>>> varyings that was present on nv50 has been removed with nvc0 (Fermi).
>>>> And I'm glad, because filling 4 routing tables (since we have 5 shader
>>>> types now) is somewhat annoying. And so applying relocations to shaders
>>>> - it can be done, it's probably not too time consuming, but it's just
>>>> plain *unnecessary* (and thus stupid) for OpenGL.
>>>>
>>>> Now about d3d9 ...
>>>> 1. don't care, I don't see a d3d9 state tracker
>>>> 2. http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx
>>>> says "n is an optional integer between 0 and the number of resources
>>>> supported" - what "supported" means here isn't clear to me, but, I
>>>> didn't find any example where someone used something OpenGL doesn't have
>>>> (like COLOR2).
>>>> 3.
>>>> http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics
>>>> says "Input semantics are similar to the values in the D3DDECLUSAGE."
>>>> and
>>>> DECLUSAGE sounds like you're limited to sane values.
>>>
>>> I think you're on the right track with (1)...  It's fairly pointless
>>> trying to discuss code here which isn't public&  I don't think people
>>> need to be worrying about what may or may not be important for code they
>>> can't see.
>>>
>>> I know this idea previously got tied up with speculation about what a
>>> DX9 state tracker might or might not require, but in retrospect I wish
>>> I'd been able to steer conversation away from that.
>>>
>>> The work on closed components may drive a lot of the feature development
>>> and new interfaces, but there's usually enough flexibility that this
>>> sort of cleanup isn't a big deal.
>>>
>>>
>>> Keith
>>>
>>>> Not sure if anyone wants to think about this issue at this time (since
>>>> implementation of ARB_separate_shader_objects is probably far in the GL4
>>>> future), but I'd be happy about any comments.
>>>>
>>>> Regards,
>>>> Christoph
>>>>
>>>> On 04/13/2010 12:55 PM, Luca Barbieri wrote:
>>>>> This patch series is intended to resolve the issue of semantic-based shader linkage in Gallium.
>>>>> It can also be found in the RFC-gallium-semantics branch.
>>>>>
>>>>> It does not change the current Gallium design, but rather formalizes some limitations to it, and provides infrastructure to implement this model more easily in drivers, along with a full nv30/nv40 implementation.
>>>>>
>>>>> These limitations are added to allow an efficient implementation for both hardware lacking special support and hardware having support but also special constraints.
>>>>>
>>>>> Note that this does NOT resolve all issues, and there are quite a bit left to future refinement.
>>>>>
>>>>> In particular, the following issues are still open:
>>>>> 1. COLOR clamping (and floating point framebuffers)
>>>>> 2. A linkage table CSO allowing to specify non-identity linkage
>>>>> 3. BCOLOR/FACE-related issues
>>>>> 4. Adding a cap to inform the state tracker that more than 219 generic indices are provided
>>>>>
>>>>> This topic was already very extensively discussed.
>>>>> See http://www.mail-archive.com/mes...@li.../msg10865.html for some early inconclusive discussion around an early implementation that modified the GLSL linker (which is NOT being proposed here)
>>>>> See http://www.mail-archive.com/mes...@li.../msg12016.html for some more discussion that seemed to mostly reach a consensus over the approach proposed here.
>>>>> See in particular http://www.mail-archive.com/mes...@li.../msg12041.html .
>>>>>
>>>>> That said, I'm going to try to repeat all information here, partially by copy&pasting from earlier messages.
>>>>> This message should probably be adapted into gallium/docs if/when this is accepted.
>>>>>
>>>>> Here is the short summary; the long rationale follows after it.
>>>>>
>>>>> The proposal here is to add the following limitations to Gallium, for the intermediate semantics:
>>>>> 1. TGSI_SEMANTIC_NORMAL is removed, using a commit by Michal Krol that was never merged
>>>>> 2. Every semantic except GENERIC, COLOR and BCOLOR can only be used with semantic index 0
>>>>> 3. COLOR and BCOLOR can only be used with semantic index 0-1 (note that this doesn't apply to fragment outputs)
>>>>> 4. GENERIC can be used with semantic indices 0-218 on any driver, if BCOLOR is not used
>>>>> 5. GENERIC can be used with semantic indices 0-216 on any driver, if BCOLOR IS used
>>>>> 6. GENERIC can be used with semantic indices 0-255 on almost all drivers (those that don't need the 0-218 limitation)
>>>>> 7. Some drivers may also choose to support GENERIC with arbitrary indices, but that should generally not happen
>>>>>
>>>>> The reason of this, in short, is that this maps directly to DirectX 9 SM3, which is the most problematic interface of all.
>>>>>
>>>>> The peculiar problem we have here is that we have two competing constraints that force us into choosing the exact SM3 value:
>>>>> 1. The VMware SVGA driver must deal with an SM3 host interface and would ideally want to directly feed the Gallium semantics to the host
>>>>> 2. An hypotetical DirectX 9 state tracker needs to support SM3 and would ideally want to directly feed the SM3 semantics to Gallium
>>>>>
>>>>> Note that this is not a reference to the VMware DirectX 9 state tracker, since its authors haven't provided details about its handling of shader semantics.
>>>>>
>>>>> SM3 ends up supporting 219 generic indices: 16 indices in 14 classes, minus POSITION0, PSIZE0, COLOR0, COLOR1 and FOG0 which are the only ones that wouldn't be mapped to GENERIC.
>>>>> However, Gallium drivers that don't benefit from having specific contraints (like svga and r600) are supposed to support 256 indices, and my nv30/nv40 work does that.
>>>>>
>>>>> The expected implementation, if no hardware support exists, is to build a list of relocations to apply to either the fragment or the vertex shader, and patch one of them at validation time to match the other.
>>>>> Data structures are provided in gallium/auxiliary to ease this, and try to minimize the number of times where this needs to be performed.
>>>>>
>>>>> Let's now proceed to the discussion and detailed rationale, mostly constructed by copy&pasting older messages.
>>>>> ...
>
>
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> .
>

Re: [Mesa3d-dev] [PATCH 0/6] [RFC] Formalization of the Gallium shader semantics linkage model

[Keith W. <ke...@vm...>]

Christoph,

This looks good.  Thanks for bringing this back to life.

Keith

On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller wrote:
> On 12/14/2010 12:36 PM, Keith Whitwell wrote:
> > On Mon, 2010-12-13 at 12:01 -0800, Christoph Bumiller wrote:
> >> I want to warm this up again adding nvc0 and
> >> GL_ARB_separate_shader_objects to the picture.
> >>
> >> The latter extends GL_EXT_separate_shader_objects to support user
> >> defined varyings and guarantees well defined behaviour only if
> >> - varyings are declared inside the gl_PerVertex/gl_PerFragment block the
> >> blocks match exactly in name, type, qualification, and (most
> >> significantly) declaration order.
> >> - varyings are assigned matching location qualifiers:
> >> like: layout(location = 3) in vec4 normal
> >> "The number of input locations available to a shader is limited."
> >>
> >> So, I propose to (loosely) identify GENERIC semantic indices with these
> >> location qualifiers and let the pipe driver set a limit on the allowed
> >> maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS, and not demand to at least
> >> support 219 of them - nvc0 offsers 0x200 bytes for generic inputs/outputs).
> > 
> > This sounds fine actually.  We kicked this around before & I was
> > basically ok with the last iteration of the proposal, but this seems ok
> > too.
> > 
> > As far as I can tell from a gallium perspective you're really just
> > proposing a new pipe cap _MAX_INPUTS (actually _MAX_GENERIC_INDEX would
> > be clearer), which the state tracker thereafter has to respect?
> > 
> > That would be fine with me.
> First attempt at a patch introducing such a cap attached.
> 
> > 
> >> My motivation is mostly that the hardware routing table for shader
> >> varyings that was present on nv50 has been removed with nvc0 (Fermi).
> >> And I'm glad, because filling 4 routing tables (since we have 5 shader
> >> types now) is somewhat annoying. And so applying relocations to shaders
> >> - it can be done, it's probably not too time consuming, but it's just
> >> plain *unnecessary* (and thus stupid) for OpenGL.
> >>
> >> Now about d3d9 ...
> >> 1. don't care, I don't see a d3d9 state tracker
> >> 2. http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx
> >> says "n is an optional integer between 0 and the number of resources
> >> supported" - what "supported" means here isn't clear to me, but, I
> >> didn't find any example where someone used something OpenGL doesn't have
> >> (like COLOR2).
> >> 3.
> >> http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics
> >> says "Input semantics are similar to the values in the D3DDECLUSAGE."
> >> and
> >> DECLUSAGE sounds like you're limited to sane values.
> > 
> > I think you're on the right track with (1)...  It's fairly pointless
> > trying to discuss code here which isn't public & I don't think people
> > need to be worrying about what may or may not be important for code they
> > can't see.
> > 
> > I know this idea previously got tied up with speculation about what a
> > DX9 state tracker might or might not require, but in retrospect I wish
> > I'd been able to steer conversation away from that.
> > 
> > The work on closed components may drive a lot of the feature development
> > and new interfaces, but there's usually enough flexibility that this
> > sort of cleanup isn't a big deal.
> > 
> > 
> > Keith
> > 
> >> Not sure if anyone wants to think about this issue at this time (since
> >> implementation of ARB_separate_shader_objects is probably far in the GL4
> >> future), but I'd be happy about any comments.
> >>
> >> Regards,
> >> Christoph
> >>
> >> On 04/13/2010 12:55 PM, Luca Barbieri wrote:
> >>> This patch series is intended to resolve the issue of semantic-based shader linkage in Gallium.
> >>> It can also be found in the RFC-gallium-semantics branch.
> >>>
> >>> It does not change the current Gallium design, but rather formalizes some limitations to it, and provides infrastructure to implement this model more easily in drivers, along with a full nv30/nv40 implementation.
> >>>
> >>> These limitations are added to allow an efficient implementation for both hardware lacking special support and hardware having support but also special constraints.
> >>>
> >>> Note that this does NOT resolve all issues, and there are quite a bit left to future refinement.
> >>>
> >>> In particular, the following issues are still open:
> >>> 1. COLOR clamping (and floating point framebuffers)
> >>> 2. A linkage table CSO allowing to specify non-identity linkage
> >>> 3. BCOLOR/FACE-related issues
> >>> 4. Adding a cap to inform the state tracker that more than 219 generic indices are provided
> >>>
> >>> This topic was already very extensively discussed.
> >>> See http://www.mail-archive.com/mes...@li.../msg10865.html for some early inconclusive discussion around an early implementation that modified the GLSL linker (which is NOT being proposed here)
> >>> See http://www.mail-archive.com/mes...@li.../msg12016.html for some more discussion that seemed to mostly reach a consensus over the approach proposed here.
> >>> See in particular http://www.mail-archive.com/mes...@li.../msg12041.html .
> >>>
> >>> That said, I'm going to try to repeat all information here, partially by copy&pasting from earlier messages.
> >>> This message should probably be adapted into gallium/docs if/when this is accepted.
> >>>
> >>> Here is the short summary; the long rationale follows after it.
> >>>
> >>> The proposal here is to add the following limitations to Gallium, for the intermediate semantics:
> >>> 1. TGSI_SEMANTIC_NORMAL is removed, using a commit by Michal Krol that was never merged
> >>> 2. Every semantic except GENERIC, COLOR and BCOLOR can only be used with semantic index 0
> >>> 3. COLOR and BCOLOR can only be used with semantic index 0-1 (note that this doesn't apply to fragment outputs)
> >>> 4. GENERIC can be used with semantic indices 0-218 on any driver, if BCOLOR is not used
> >>> 5. GENERIC can be used with semantic indices 0-216 on any driver, if BCOLOR IS used
> >>> 6. GENERIC can be used with semantic indices 0-255 on almost all drivers (those that don't need the 0-218 limitation)
> >>> 7. Some drivers may also choose to support GENERIC with arbitrary indices, but that should generally not happen
> >>>
> >>> The reason of this, in short, is that this maps directly to DirectX 9 SM3, which is the most problematic interface of all.
> >>>
> >>> The peculiar problem we have here is that we have two competing constraints that force us into choosing the exact SM3 value:
> >>> 1. The VMware SVGA driver must deal with an SM3 host interface and would ideally want to directly feed the Gallium semantics to the host
> >>> 2. An hypotetical DirectX 9 state tracker needs to support SM3 and would ideally want to directly feed the SM3 semantics to Gallium
> >>>
> >>> Note that this is not a reference to the VMware DirectX 9 state tracker, since its authors haven't provided details about its handling of shader semantics.
> >>>
> >>> SM3 ends up supporting 219 generic indices: 16 indices in 14 classes, minus POSITION0, PSIZE0, COLOR0, COLOR1 and FOG0 which are the only ones that wouldn't be mapped to GENERIC.
> >>> However, Gallium drivers that don't benefit from having specific contraints (like svga and r600) are supposed to support 256 indices, and my nv30/nv40 work does that.
> >>>
> >>> The expected implementation, if no hardware support exists, is to build a list of relocations to apply to either the fragment or the vertex shader, and patch one of them at validation time to match the other.
> >>> Data structures are provided in gallium/auxiliary to ease this, and try to minimize the number of times where this needs to be performed.
> >>>
> >>> Let's now proceed to the discussion and detailed rationale, mostly constructed by copy&pasting older messages.
> >>> ...