mesa3d-dev

Re: [Mesa3d-dev] [RFC] gallium-no-rhw-position branch merge

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

Hi Michal,

This branch breaks 2 piglit tests with r300g:

depthrange-clear
texdepth

However I haven't investigated these and won't get to them until the
weekend. I personally don't mind fixing the regressions after the merge (but
I'm not the maintainer of r300g). Anyway I'm glad to see
bypass_vs_clip_and_viewport dying.

-Marek

On Mon, Mar 1, 2010 at 5:08 PM, michal <mi...@vm...> wrote:

> Hi,
>
> This branch removes bypass_vs_clip_and_viewport flag from pipe
> rasterizer state. The benefits of having this bit around were dubious
> for everybody and burdensome for driver writers.
>
> All the utility code that relied on this flag have been rewritten to
> pass vertex positions in clip space and set clip and viewport state. I
> would like to ask the maintainers of u_blitter module to please test my
> changes and provide feedback.
>
> Please review.
>
> Thanks.
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>

[Mesa3d-dev] [PATCH] nouveau: another trivial extension enable

[<ran...@gm...>]

Re: [Mesa3d-dev] Build failure in glapi/glapi.c

[George S. <gsa...@gm...>]

On Tue, Mar 2, 2010 at 12:38 AM, Johannes Obermayr
<joh...@gm...> wrote:
> Latest mesa does not compile.
>
> Thanks.
> Johannes
>
>
> gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 state_tracker/st_texture.c -o state_tracker/st_texture.o
> gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 glapi/glapi.c -o glapi/glapi.o
> glapi/glapi.c: In function '_glapi_check_multithread':
> glapi/glapi.c:178: error: expected expression before 'void'
> glapi/glapi.c:178: error: too many arguments to function '_glapi_init_multithread'
> glapi/glapi.c:180: error: expected ';' before 'knownID'
> gmake[2]: *** [glapi/glapi.o] Error 1
> gmake[2]: *** Waiting for unfinished jobs....
> gmake[2]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/usr/src/packages/BUILD/Mesa/src'
> make: *** [default] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.IlpHA4 (%build)
>

Should be fixed in master.

Sorry for that and thanks to Jose for fixing it.

[Mesa3d-dev] Remove support for GCC version < 3.3.x

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

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

There are a few places in Mesa where we check the GCC version and have
alternate code paths.  It looks like almost all of the checks go away if
we require GCC version of at least 3.3.0.  The last 3.2 (or earlier)
release was in April of 2003.  It seems safe to remove support for a 7
year old version.  Opinions?

http://gcc.gnu.org/releases.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuMS5QACgkQX1gOwKyEAw+79wCeNQuMgY2doWc4D0ICnXpscnE8
JrwAoJ2un+hql7/g+D1HcnXAfOqXIoiL
=Aa2Q
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Joakim S. <ba...@zh...>]

On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
> Hi,
> 
> this branch turns vertex element into a cso, so instead of
> set_vertex_elements there's now the triad of
> create/bind/delete_vertex_elements_state. I have converted all the
> drivers except nouveau (I didn't do it because Christoph Bumiller
> already did nv50, but I can give the rest of them a shot), though that
> doesn't necessarily mean they are optimized for it (the idea is of
> course to precalculate state on create, not just copy the pipe structs
> and do everything on bind) - only i965g really does something close to
> it (though still emits the state always). Drivers doing both hw vertex
> shaders and using draw in some circumstances of course will have to
> store both representations on create.
> Also note that util_draw_vertex_buffer semantics have changed a bit
> (caller needs to set vertex element state, which is a bit odd).
> 
> Roland

Can I still do things like:
element 0: -> vbo 5
element 1: -> vbo 2
and then set_vertex_buffers() with an array { zeros, zeros, vbo 2, zeros
zeros, vbo 5 } ?

Re: [Mesa3d-dev] Build failure in glapi/glapi.c

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

Bugzilla from joh...@gm... wrote:
> 
> Latest mesa does not compile.
> 
> Thanks.
> Johannes
> 
> 
> gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
> -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_ASM
> -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
> -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
> -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
> -DHAVE_XEXTPROTO_71 state_tracker/st_texture.c -o
> state_tracker/st_texture.o
> gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
> -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_ASM
> -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
> -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
> -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
> -DHAVE_XEXTPROTO_71 glapi/glapi.c -o glapi/glapi.o
> glapi/glapi.c: In function '_glapi_check_multithread':
> glapi/glapi.c:178: error: expected expression before 'void'
> glapi/glapi.c:178: error: too many arguments to function
> '_glapi_init_multithread'
> glapi/glapi.c:180: error: expected ';' before 'knownID'
> gmake[2]: *** [glapi/glapi.o] Error 1
> gmake[2]: *** Waiting for unfinished jobs....
> gmake[2]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/usr/src/packages/BUILD/Mesa/src'
> make: *** [default] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.IlpHA4 (%build)
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 
I experienced the same error while building Mesa from git earlier on tonight
as well.I just waited to see if it was going to be fixed later.
Regards,
            STEVE555
-- 
View this message in context: http://old.nabble.com/Build-failure-in-glapi-glapi.c-tp27750029p27750183.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

[Mesa3d-dev] Build failure in glapi/glapi.c

[Johannes O. <joh...@gm...>]

Latest mesa does not compile.

Thanks.
Johannes


gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 state_tracker/st_texture.c -o state_tracker/st_texture.o
gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 glapi/glapi.c -o glapi/glapi.o
glapi/glapi.c: In function '_glapi_check_multithread':
glapi/glapi.c:178: error: expected expression before 'void'
glapi/glapi.c:178: error: too many arguments to function '_glapi_init_multithread'
glapi/glapi.c:180: error: expected ';' before 'knownID'
gmake[2]: *** [glapi/glapi.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/Mesa/src'
make: *** [default] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.IlpHA4 (%build)

Re: [Mesa3d-dev] [PATCH] Nouveau_vieux "fixes"

[<ran...@gm...>]

Another trivial patch: nouveau classic driver has everything needed for 
GL_NV_blend_square, just expose extension. Tested with tests/blendsquare

В сообщении от Monday 01 March 2010 02:25:01 вы написали:
> ran...@gm... writes:
> > Hello all!
> >
> > After unsuccesfull battle with git-send-email I just  send these two
> > patches  from Kmail. Botch as attachments and inlin, but inline version
> > probably will be damaged in process.....
>
> Thanks, both patches pushed (after some minor reformatting: please, use
> git-format-patch next time).
>
> > Patch 1: add XRGB8888 into nouveau_fbo.c, makes xmoto actually display
> > its demo, not abort
> >
> > diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> > b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c index 1db8c5d..8464786
> > 100644
> > --- a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> > +++ b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> > @@ -215,6 +215,8 @@ get_tex_format(struct gl_texture_image *ti)
> >         switch (ti->TexFormat) {
> >         case MESA_FORMAT_ARGB8888:
> >                 return GL_RGBA8;
> > +       case MESA_FORMAT_XRGB8888:
> > +               return GL_RGB8;
> >         case MESA_FORMAT_RGB565:
> >                 return GL_RGB5;
> >         default:
> >
> >
> > Patch 2: add two stencil operation cases in nv04_state_raster.c, allow
> > demos/reflect and demos/dinoshade actually work. Dinoshade still visible
> > broken. Not sure about redbook/stencil, it looks very same on my modified
> > driver with TNT2 and with swrast. But tests/stencil definitely wrong ....
> > So, all cases are in, one just need to figure out  correct assignment.
> >
> > diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
> > b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c index 5e3788d..6d0b262
> > 100644
> > --- a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
> > +++ b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
> > @@ -61,6 +61,10 @@ get_stencil_op(unsigned op)
> >         switch (op) {
> >         case GL_KEEP:
> >                 return 0x1;
> > +       case GL_ZERO:
> > +               return 0x2;
> > +       case GL_REPLACE:
> > +               return 0x3;
> >         case GL_INCR:
> >                 return 0x4;
> >         case GL_DECR:
> >
> > -----
> >
> > Tested-off-by: Andrew Randrianasulu <ran...@gm...>

[Mesa3d-dev] i855GME + eagle + linux 2.6.33-rc8 + textures => kernel panic

[Данилко И. <lo...@ya...>]

Hi.
I've got motherboard with Intel i855GME card.

I've build eagle (from krh's repository, commit 5af77e7525f42d7c5fa4429a633cf844d6b935f2) using:
1. drm-2.4.18
2. Mesa-7.7
3. linux kernel 2.6.33-rc8

And I was able to run demos fine (but gears with flicker sometimes).

After that I've started porting demos from Mesa-7.7/progs/demos to eagle.
Gearbox and bounce run just fine.

But this demo (using glTexCoord2f) provokes kernel panic or PC hang
while calling drmModePageFlip in eagle/test/setup.c.


Can anyone help me with this? What info do I need to provide?

Thanks in advance!

Re: [Mesa3d-dev] [PATCH] Nouveau_vieux "fixes"

[<ran...@gm...>]

В сообщении от Monday 01 March 2010 02:25:01 Francisco Jerez написал(а):
> ran...@gm... writes:
> > Hello all!
> >
> > After unsuccesfull battle with git-send-email I just  send these two
> > patches  from Kmail. Botch as attachments and inlin, but inline version
> > probably will be damaged in process.....
>
> Thanks, both patches pushed (after some minor reformatting: please, use
> git-format-patch next time).

Like this?


>
> > Patch 1: add XRGB8888 into nouveau_fbo.c, makes xmoto actually display
> > its demo, not abort
> >
> > diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> > b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c index 1db8c5d..8464786
> > 100644
> > --- a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> > +++ b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> > @@ -215,6 +215,8 @@ get_tex_format(struct gl_texture_image *ti)
> >         switch (ti->TexFormat) {
> >         case MESA_FORMAT_ARGB8888:
> >                 return GL_RGBA8;
> > +       case MESA_FORMAT_XRGB8888:
> > +               return GL_RGB8;
> >         case MESA_FORMAT_RGB565:
> >                 return GL_RGB5;
> >         default:
> >
> >
> > Patch 2: add two stencil operation cases in nv04_state_raster.c, allow
> > demos/reflect and demos/dinoshade actually work. Dinoshade still visible
> > broken. Not sure about redbook/stencil, it looks very same on my modified
> > driver with TNT2 and with swrast. But tests/stencil definitely wrong ....
> > So, all cases are in, one just need to figure out  correct assignment.
> >
> > diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
> > b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c index 5e3788d..6d0b262
> > 100644
> > --- a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
> > +++ b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
> > @@ -61,6 +61,10 @@ get_stencil_op(unsigned op)
> >         switch (op) {
> >         case GL_KEEP:
> >                 return 0x1;
> > +       case GL_ZERO:
> > +               return 0x2;
> > +       case GL_REPLACE:
> > +               return 0x3;
> >         case GL_INCR:
> >                 return 0x4;
> >         case GL_DECR:
> >
> > -----
> >
> > Tested-off-by: Andrew Randrianasulu <ran...@gm...>

[Mesa3d-dev] [Bug 26820] Sharing contexts crashes on Windows

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26820


Karl Schultz <Kar...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Kar...@gm...




--- Comment #2 from Karl Schultz <Kar...@gm...>  2010-03-01 12:06:14 PST ---
This was reported on 7.6.  The OP sent me a sample program, and it works OK for
me on tip of tree.  On 7.6, it crashes on app exit.  Both these tests were with
the non-gallium GDI driver.

The OP should probably attach the testcase, as I do not have his permission to
do so.  


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Corbin S. <mos...@gm...>]

R300 could benefit. I will push a patch to make it more useful after the
merge.

Posting from a mobile, pardon my terseness. ~ C.

On Mar 1, 2010 11:32 AM, "Roland Scheidegger" <sr...@vm...> wrote:

On 01.03.2010 19:02, Roland Scheidegger wrote:
> Hi,
>
> this branch turns vertex element into a cs...
Ok, I've converted nv30/nv40 too. Not that they'd precalculate any hw
state...


Roland

------------------------------------------------------------------------------
Download Int...

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Roland S. <sr...@vm...>]

On 01.03.2010 19:02, Roland Scheidegger wrote:
> Hi,
> 
> this branch turns vertex element into a cso, so instead of
> set_vertex_elements there's now the triad of
> create/bind/delete_vertex_elements_state. I have converted all the
> drivers except nouveau (I didn't do it because Christoph Bumiller
> already did nv50, but I can give the rest of them a shot), though that
> doesn't necessarily mean they are optimized for it (the idea is of
> course to precalculate state on create, not just copy the pipe structs
> and do everything on bind) - only i965g really does something close to
> it (though still emits the state always). Drivers doing both hw vertex
> shaders and using draw in some circumstances of course will have to
> store both representations on create.
> Also note that util_draw_vertex_buffer semantics have changed a bit
> (caller needs to set vertex element state, which is a bit odd).

Ok, I've converted nv30/nv40 too. Not that they'd precalculate any hw
state...

Roland

[Mesa3d-dev] PK/UP* and NV_[vertex|fragment]_program* support in Gallium?

[Luca B. <lu...@lu...>]

I see that PK2US and friends are being removed.
These would be necessary to implement NV_fragment_program_option,
NV_fragment_program2 and NV_gpu_program4.

Currently the no drivers (including Nouveau) support them, but since
we already have some support in Mesa (even parsers for the nVidia
syntax), it would be nice to support them in Gallium eventually.

Not sure about STR/SFL though: they can be encoded/decoded as MOV x,
0/1, but they "complete" the SETcond instruction set.

How about keeping them and adding a capability bit for them?

[Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Roland S. <sr...@vm...>]

Hi,

this branch turns vertex element into a cso, so instead of
set_vertex_elements there's now the triad of
create/bind/delete_vertex_elements_state. I have converted all the
drivers except nouveau (I didn't do it because Christoph Bumiller
already did nv50, but I can give the rest of them a shot), though that
doesn't necessarily mean they are optimized for it (the idea is of
course to precalculate state on create, not just copy the pipe structs
and do everything on bind) - only i965g really does something close to
it (though still emits the state always). Drivers doing both hw vertex
shaders and using draw in some circumstances of course will have to
store both representations on create.
Also note that util_draw_vertex_buffer semantics have changed a bit
(caller needs to set vertex element state, which is a bit odd).

Roland

Re: [Mesa3d-dev] Mesa (master): util: Code generate functions to pack and unpack a single pixel.

[José F. <jfo...@vm...>]

On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
> On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote: 
> > Module: Mesa
> > Branch: master
> > Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
> > URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
> > 
> > Author: José Fonseca <jfo...@vm...>
> > Date:   Fri Feb 26 16:45:22 2010 +0000
> > 
> > util: Code generate functions to pack and unpack a single pixel.
> > 
> > Should work correctly for all pixel formats except SRGB formats.
> > 
> > Generated code made much simpler by defining the pixel format as
> > a C structure. For example this is the generated structure for
> > PIPE_FORMAT_B6UG5SR5S_NORM:
> > 
> > union util_format_b6ug5sr5s_norm {
> >    uint16_t value;
> >    struct {
> >       int r:5;
> >       int g:5;
> >       unsigned b:6;
> >    } chan;
> > };
> 
> José, are you aware that the memory layout of bitfields is mostly
> implementation dependent? IME this makes them mostly unusable for
> modelling hardware in a portable manner.

No, I wasn't! I'm surprised -- they're used quite a lot.

> > Not used everywhere yet because it seems compiled code is slower than
> > bitshift arithmetic by some misterious reason. So we should generate
> > bitshift arithmetic at least for the simple UNORM pixel formats.
> 
> Due to above I'd recommend always using bitshift arithmetic rather than
> bitfields anyway. :)

Yeah. I think I'll do just that. bitfields made generated code cleaner,
but if I have to implement bitshift arith for performance then might as
well do it for all formats that apply.

Thanks for the feedback.

Jose

[Mesa3d-dev] [Bug 26820] Sharing contexts crashes on Windows

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26820


José Fonseca <jfo...@vm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jfo...@vm...




--- Comment #1 from José Fonseca <jfo...@vm...>  2010-03-01 09:10:29 PST ---
I'm pretty sure this is working correctly on the gallium driver. 

Could you provide a sample app?

Does wglthreads work there?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] Mesa (master): util: Code generate functions to pack and unpack a single pixel.

[Michel D. <mi...@da...>]

On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote: 
> Module: Mesa
> Branch: master
> Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
> 
> Author: José Fonseca <jfo...@vm...>
> Date:   Fri Feb 26 16:45:22 2010 +0000
> 
> util: Code generate functions to pack and unpack a single pixel.
> 
> Should work correctly for all pixel formats except SRGB formats.
> 
> Generated code made much simpler by defining the pixel format as
> a C structure. For example this is the generated structure for
> PIPE_FORMAT_B6UG5SR5S_NORM:
> 
> union util_format_b6ug5sr5s_norm {
>    uint16_t value;
>    struct {
>       int r:5;
>       int g:5;
>       unsigned b:6;
>    } chan;
> };

José, are you aware that the memory layout of bitfields is mostly
implementation dependent? IME this makes them mostly unusable for
modelling hardware in a portable manner.

> Not used everywhere yet because it seems compiled code is slower than
> bitshift arithmetic by some misterious reason. So we should generate
> bitshift arithmetic at least for the simple UNORM pixel formats.

Due to above I'd recommend always using bitshift arithmetic rather than
bitfields anyway. :)


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] [RFC] gallium-winsys-handle branch merge

[Jakob B. <ja...@vm...>]

On 1 mar 2010, at 13.45, Jakob Bornecrantz wrote:
> On 1 mar 2010, at 13.05, Keith Whitwell wrote:
>> On Thu, 2010-02-25 at 20:46 -0800, Jakob Bornecrantz wrote:
>>> Howdy
>>>
>>> I'm hoping to merge the gallium-winsys-handle branch to master this
>>> weekend or early next week. The branch adds two new pipe screen
>>> functions to be used by the co state tracker (state tracker manger  
>>> in
>>> new st_api.h speak). The branch also adds a new
>>> PIPE_TEXTURE_USAGE_SHARABLE flag telling the driver that the driver
>>> that the texture might be used for sharing. Even more so it also
>>> renames PIPE_TEXTURE_USAGE_PRIMARY to PIPE_TEXTURE_USAGE_SCANOUT  
>>> just
>>> to make things clear. I also ported the egl,xorg,dri state trackers
>>> to
>>> the new interface and removing unneeded functions from drm_api  
>>> making
>>> it even smaller, however I only ported i915g, i965 and svga to the
>>> new
>>> API. Looking at the commits where I port the other drivers it should
>>> be pretty clear what to do.
>>
>> Jakob,
>>
>> I think it's probably best if you make an attempt at the changes to
>> the
>> other drivers and then ask people to test your changes.  This is how
>> we've been doing other interface changes and it seems to be a good
>> balance.
>
> Ok I'll take a stab at it.

Okay, I have done r300g as well, only nouveau, softpipe and llvmpipe  
are missing. Now both softpipe and llvmpipe are going to go to massive  
winsys changes as per your branch Keith, so I don't really see the  
point in trying to fix them. For softpipe adding winsys handle would  
require adding a proper winsys. For llvmpipe any change I do would be  
wasted since its going to switch to the new software winsys and also I  
can not build llvmpipe.

And last for nouveau I'm hoping that the other 4 driver conversions I  
did can serve as a good guide, I have to admit that I am quite busy  
and I'm sorry for leaving them with the change. I have how ever made  
sure that the pipe usage change was applied to all drivers including  
{llvm|soft}pipe and nouveau.

Anywho, I have pushed gallium-winsys-handle-rebased thats rebased on  
master and cleaned up was well.

Cheers Jakob.

[Mesa3d-dev] [RFC] gallium-no-rhw-position branch merge

[michal <mi...@vm...>]

Hi,

This branch removes bypass_vs_clip_and_viewport flag from pipe 
rasterizer state. The benefits of having this bit around were dubious 
for everybody and burdensome for driver writers.
 
All the utility code that relied on this flag have been rewritten to 
pass vertex positions in clip space and set clip and viewport state. I 
would like to ask the maintainers of u_blitter module to please test my 
changes and provide feedback.

Please review.

Thanks.

Re: [Mesa3d-dev] Mesa (gallium-format-cleanup): gallium: Remove inexisting formats.

[José F. <jfo...@vm...>]

On Mon, 2010-03-01 at 07:32 -0800, Jakob Bornecrantz wrote:
> On 1 mar 2010, at 15.23, Jose Fonseca wrote:
> > Module: Mesa
> > Branch: gallium-format-cleanup
> > Commit: 4c3bfc9778d9a0a75bf93b15303a4839f971f695
> > URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=4c3bfc9778d9a0a75bf93b15303a4839f971f695
> >
> > Author: José Fonseca <jfo...@vm...>
> > Date:   Mon Mar  1 15:17:41 2010 +0000
> >
> > gallium: Remove inexisting formats.
> >
> > Can't find these formats used in any state tracker or any API.
> >
> > For some of these probably the reverse notation was meant, for which
> > formats already exist.
> 
> src/gallium/state_trackers/xorg/xorg_exa.c:62

> currently they aren't translated to Gallium formats and I wonder if  
> the new swizzle state on the sampler views will solve this instead.

hmm... There's a bunch of PICT_* formats there that could be translated
to existing gallium formats and aren't. Is it even imperative that all
formats are supported? It looks like some can't be supported by 3d
hardware, even with swizzles. Also if swizlling is necessary it can and
should be performed in the fragment shaders generated by the xorg state
tracker. 

Anyway, this bears no relation with my change above, as all formats I
removed were signed, and xorg makes no use of SNORM or SSCALED formats
AFAICT.

Jose

Re: [Mesa3d-dev] Gallium software fallback/draw command failure

[Corbin S. <mos...@gm...>]

Wow, this really got a lot of discussion.

I don't really care *where* the sanity code is, but it just seems
horribly wrong that it's got to be duplicated between per-hook
per-driver in a library that purports simplified drivers with reduced
LOCs. I suppose it's unavoidable to a degree as long as driver setup
is bare, though.

There are alternatives to every single bad draw case, but handling
them correctly needs to be required and documented, and that means we
probably have to agree on them. Examples:
- Oversized colorbufs are forbidden; if you absolutely need them, I
could cook up a u_shatter but it's going to be hilariously slow due to
CPU blits
- While not all textures can fit into VRAM, find the biggest texture
and shrink it
- Too many verts or too many indices are handled by multiple draw calls
- If the bound pipeline is incomplete (at least one state bound to
NULL or unset), results are undefined

Async errors make sense, or at least more sense than no error reporting at all.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<Mos...@gm...>

Re: [Mesa3d-dev] Gallium software fallback/draw command failure

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

On Mon, 2010-03-01 at 07:33 -0800, Olivier Galibert wrote:
> On Mon, Mar 01, 2010 at 04:08:32PM +0100, Jerome Glisse wrote:
> > Do you have solution/proposal/idea on how to handle the situation
> > i am describing ?
> 
> I've been looking at gallium from far away, but it seems to me you
> have two independant issues:
> - informing the caller of errors in atomic draw() calls
> - deciding what to do when the error is due to resource exhaustion
> 
> For the first issue, if the api doesn't allow for returning errors,
> then the api is crap and has to be fixed.  No two ways about it.

Thanks for your comments.

To reiterate what has already been said, the approach we're taking is:
a) the driver makes a best effort to render under all circumstances
b) we'll add an error notification path to generate GL_OUT_OF_MEMORY,
but the state tracker will not be doing any fallbacks based on this.

Keith

Re: [Mesa3d-dev] Gallium software fallback/draw command failure

[José F. <jfo...@vm...>]

On Mon, 2010-03-01 at 06:24 -0800, Olivier Galibert wrote:
> On Mon, Mar 01, 2010 at 02:57:08PM +0100, Jerome Glisse wrote:
> > validate function i have in mind as virtualy a zero cost (it will
> > boil down to a bunch of add followed by a test) and what validate
> > would do would be done by draw operation anyway.
> 
> Not "would", "will".  You have no way to be sure nothing changed
> between validate and draw, 

pipe_contexts are not re-entrant.

> unless you're happy with an interface that
> will always be unusable for multithreading.  So you'll do it twice for
> something that will always tell "yes" except once in a blue moon.

The current procedure is:

   pipe->bind_this_state();
   pipe->bind_that_state();
   pipe->set_this_state();
   pipe->set_that_state();

   pipe->draw();

Making it 

   pipe->bind_this_state();
   pipe->bind_that_state();
   pipe->set_this_state();
   pipe->set_that_state();

   if(pipe->validate() == PIPE_OUT_OF_MEMORY)
      return GL_OUT_OF_MEMORY;

   pipe->draw();

Makes it no better, no worse in terms of race conditions.

Jose

Re: [Mesa3d-dev] Gallium software fallback/draw command failure

[Olivier G. <gal...@po...>]

On Mon, Mar 01, 2010 at 04:08:32PM +0100, Jerome Glisse wrote:
> Do you have solution/proposal/idea on how to handle the situation
> i am describing ?

I've been looking at gallium from far away, but it seems to me you
have two independant issues:
- informing the caller of errors in atomic draw() calls
- deciding what to do when the error is due to resource exhaustion

For the first issue, if the api doesn't allow for returning errors,
then the api is crap and has to be fixed.  No two ways about it.

For the second issue, you can have a generic way, a per-driver (call
them state trackers if you want) specific way, both, or neither (also
known as the "fuck it" solution).

The generic way is to, when you get an "out of whatever" error, drop
down to software in the caller.  That requires having enough state
available to be able to apply software to the specific operations in
the first place.  Potentially slow, but otoh all drivers would benefit
from it.  It would happen only on error, so outside of the fast path.

The specific way is to handle all you can in the driver, for instance
splitting as you proposed, and punt in error only if you really can't
do anything accelerated.

Both allows you in case of punting to still be able to do the
requested render.  Belt and suspenders :-)

Neither "just" means ensuring errors go up all the way in the chain to
the application.  Personally I'd start by that, but that's just me.
Ensure that the application has enough information, even if
after-the-fact, to do its own tuning.  A polygon not drawing silently
is an atrocity to debug.  An out of resources error is something
obvious (debug-wise) you can throw money or code at.

Having "neither", i.e. correctness in error handling, does not prevent
you to play with the generic or specific ways afterwards.  But I
suspect you'll find more interesting to work on enabling access to
currently unavailable hardware features and tell people that if they
want 16 8192^3 textures they can go full software explicitely or buy a
card capable of it.  Reasonableness has limits.

  OG.