mesa3d-dev

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

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

On 07.03.2010 01:21, José Fonseca wrote:
> On Sat, 2010-03-06 at 05:44 -0800, Brian Paul wrote:
>> On Sat, Mar 6, 2010 at 5:44 AM, José Fonseca <jfo...@vm...> wrote:
>>> 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.
>>> It's not only implementation dependent and slow -- it is also buggy!
>>>
>>> gcc-4.4.3 is doing something very fishy to single bit fields.
>>>
>>> See the attached code. ff ff ff ff is expected, but ff ff ff 01 is
>>> printed with gcc-4.4.3. Even without any optimization. gcc-4.3.4 works
>>> fine.
>>>
>>> Am I missing something or is this effectively a bug?
>> Same result with gcc 4.4.1.
>>
>> If pixel.chan.a is put into a temporary int var followed by the
>> scaling arithmetic it comes out as expected.  Looks like a bug to me.
> 
> Thanks. I'll submit a bug report then.
> 
>> BTW, it looks like sizeof(union util_format_b5g5r5a1_unorm) == 4, not 2.
> 
> Yet another reason to stay away from bit fields..

Hmm, might be because the bitfields are of type unsigned, not uint16_t?

I've no idea though neither why it would return 01 and not ff.

Roland

Re: [Mesa3d-dev] [rfc] to SpanRenderStart to avoid texture mapping overheads

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

On Sat, 2010-03-06 at 00:30 -0800, Dave Airlie wrote:
> So in classic drivers we can hit swrast fallbacks for things like
> ReadPixels where we know we aren't going to have to want to touch
> textures at all. This would be useful for the r300 driver where Maciej
> is working on texture tiling will allow us to avoid the untiling
> overheads that mapping textures requires for most sw fallbacks.
> 
> There may be other operations where we can do this also. For render to
> texture scenarios the driver should still map the textures via the
> FBOs anyways.
> 
> Dave.

Looks like a reasonable idea to me. 

Keith

Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?

[Török E. <edw...@gm...>]

[Patch for piglit/tests/glean/tpbo.cpp attached]

On 03/08/2010 12:12 AM, Ian Romanick wrote:
> Török Edwin wrote:
> 
>> I've run the piglit tests using tests/r500.tests, with glean in quick mode.
> 
>> With patch: 620/686 pass
>> Without patch: 614/679 pass (I opened a bugreport about these failures
>> here: https://bugs.freedesktop.org/show_bug.cgi?id=26933)
> 
>> The pbo tests results are:
>> glean/pbo: fail
>> general/pbo-teximage-tiling: pass
>> general/pbo-read-argb8888: pass
>> general/pbo-teximage-tiling-2: pass
>> general/pbo-drawpixels: pass
>> general/pbo-readpixels-small: pass
>> general/object_purgeable-api-pbo: skip
>> general/pbo-teximage: pass
>> fbo/fbo-pbo-readpixels-small: pass
> 
> Okay.  I'm convinced.  I'll leave it up to the r600 maintainers to make
> the final call.  However, they really need to do it before RC1 (March 12th).

Thanks!

> 
>> The glean/fbo fail looks like some FP tolerance being too strict (1.0 vs
>> 1.00000). Is there a way to accept 1.00000 for 1.0 in the piglit tests?
> 
>> pbo test: Test OpenGL Extension GL_ARB_pixel_buffer_object
> 
>> FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028)
>> (1, 0) = [1.000000, 1.000000, 1.000000], should be [1.0, 1.0, 1.0]
>> pbo:  NOTE perf[0] = 372.891 MB/s, which is in normal mode
>> pbo:  NOTE perf[1] = 261.088 MB/s, which is using PBO
>> pbo:  FAIL rgba8, db, z24, s8, win+pmap, id 33
>> 	9 tests passed, 1 tests failed.
> 
> That's pretty weird.  I was pretty sure that glean checked for equality
> by making sure the difference was below some threshold.  As far as I can
> tell, fabs(1.000000 - 1.0) should be below any reasonable threshold.
> There's clearly something else going wrong.

Yeah, I looked at the code: it is checking one thing and reporting
another :)

exp is black/white alternatively for every 2nd iteration:
               if (i & 1)
                  exp = black;
               else
                  exp = white;
               if (i < 10 && j < 10) {
                  if (!equalColors(&buf[(j * windowSize + i) * 3], exp)) {
                     REPORT_FAILURE("glGetPolygonStipple failed");
                     printf("(%d, %d) = [%f, %f, %f], ", i, j,
                            buf[(j * windowSize + i) * 3],
                            buf[(j * windowSize + i) * 3 + 1],
                            buf[(j * windowSize + i) * 3 + 2]);
                     printf("should be [1.0, 1.0, 1.0]\n");
^However the message reports 1.0 always.

Attached patch fixes error reporting in piglit, and then I get this message:

FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028)
(1, 0) = [1.000000, 1.000000, 1.000000], should be [0.000000, 0.000000,
0.000000]
pbo:  NOTE perf[0] = 372.431 MB/s, which is in normal mode
pbo:  NOTE perf[1] = 262.693 MB/s, which is using PBO
pbo:  FAIL rgba8, db, z24, s8, win+pmap, id 33
	9 tests passed, 1 tests failed.

Best regards,
--Edwin

Re: [Mesa3d-dev] gallium cached bufmgr busy change

[Jose F. <jfo...@vm...>]

Dave,

I don't oppose this new method -- it shouldn't be necessary to add fencing just to use pb_cache --,  but this method adds a new way of doing the same thing.

Does the underlying buffer support PIPE_BUFFER_USAGE_DONT_BLOCK? If so what about doing:

boolean
pb_cache_is_buffer_compat()
{
     void map;

     map = pb_map(buf->buffer, PIPE_BUFFER_USAGE_DONT_BLOCK | PIPE_BUFFER); 
     if (map) {
        /* TODO: cache the map value for the first map */
        pb_unmap(buf->buffer);
        return TRUE;
     }

     return FALSE;
}

Jose

________________________________________
From: Dave Airlie [ai...@gm...]
Sent: Sunday, March 07, 2010 20:36
To: Luca Barbieri
Cc: mesa
Subject: Re: [Mesa3d-dev] gallium cached bufmgr busy change

On Sun, Mar 7, 2010 at 9:44 PM, Luca Barbieri <luc...@gm...> wrote:
> I think you are supposed to do this using the fenced bufmgr over
> cached along with a (ideally userspace) fencing mechanism.
> If you can implement pb_busy, you should be able to implement
> fence_signalled in exactly the same way (making the fence handle a
> pointer to buffers should work for this purpose, if standalone fences
> are hard to do).
> The fenced bufmgr will only pass destruction requests to the wrapped
> bufmgr once the fences are signalled.
>

It just seemed a bit heavyweight, I don't want userspace fences, so why
do I have to jump though abstraction hoops?

The fencing solution isn't near as efficent from what I can see, as it
is designed around fences not buffer busy, I'll see if I can give it a try,
but I suspect it look and smell like a hack.

Dave.

------------------------------------------------------------------------------
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] Compile error in radeon_texture.c

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

Hi,

There is a compile error in radeon_texture.c.

Thanks.
Johannes


gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/drm    -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 -DHAVE_LIBDRM_RADEON=1 -I/usr/include/drm   -DRADEON_R200 radeon_texture.c -o radeon_texture.o
In file included from radeon_mipmap_tree.c:39:
radeon_tile.h:1: error: expected identifier or '(' before '.' token
radeon_mipmap_tree.c: In function 'get_texture_image_size':
radeon_mipmap_tree.c:90: warning: implicit declaration of function 'get_tile_size'
radeon_mipmap_tree.c: In function 'get_texture_image_row_stride':
radeon_mipmap_tree.c:102: warning: implicit declaration of function 'get_aligned_compressed_row_stride'
gmake[6]: *** [radeon_mipmap_tree.o] Error 1
gmake[6]: *** Waiting for unfinished jobs....
gmake[6]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/r200'
gmake[5]: *** [lib] Error 2
gmake[5]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/r200'
gmake[4]: *** [subdirs] Error 1
gmake[4]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers'
gmake[2]: *** [driver_subdirs] Error 2
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.OTEkCI (%build)

Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?

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

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

Corbin Simpson wrote:
> 2010/3/8 Ian Romanick <id...@fr...>:
>> Okay.  I'm convinced.  I'll leave it up to the r600 maintainers to make
>> the final call.  However, they really need to do it before RC1 (March 12th).
> 
> Thread hijack! Are docs changes okay? I'd like to note that r300g

As long as they don't cause regressions. ;)

> works for the simpler things in life, that bugs may be filed against
> it, and that it's been taken off the all-kitten diet.

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

iEYEARECAAYFAkuULXkACgkQX1gOwKyEAw/eNwCeMWtmKVFrsP3Xszv7lQ2qsfDB
y4EAniZo3oVtGOOmoeU686yzCrnRYDZi
=dtmN
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?

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

2010/3/8 Ian Romanick <id...@fr...>:
> Okay.  I'm convinced.  I'll leave it up to the r600 maintainers to make
> the final call.  However, they really need to do it before RC1 (March 12th).

Thread hijack! Are docs changes okay? I'd like to note that r300g
works for the simpler things in life, that bugs may be filed against
it, and that it's been taken off the all-kitten diet.

~ C.

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

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

Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?

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

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

Török Edwin wrote:

> I've run the piglit tests using tests/r500.tests, with glean in quick mode.
> 
> With patch: 620/686 pass
> Without patch: 614/679 pass (I opened a bugreport about these failures
> here: https://bugs.freedesktop.org/show_bug.cgi?id=26933)
> 
> The pbo tests results are:
> glean/pbo: fail
> general/pbo-teximage-tiling: pass
> general/pbo-read-argb8888: pass
> general/pbo-teximage-tiling-2: pass
> general/pbo-drawpixels: pass
> general/pbo-readpixels-small: pass
> general/object_purgeable-api-pbo: skip
> general/pbo-teximage: pass
> fbo/fbo-pbo-readpixels-small: pass

Okay.  I'm convinced.  I'll leave it up to the r600 maintainers to make
the final call.  However, they really need to do it before RC1 (March 12th).

> The glean/fbo fail looks like some FP tolerance being too strict (1.0 vs
> 1.00000). Is there a way to accept 1.00000 for 1.0 in the piglit tests?
> 
> pbo test: Test OpenGL Extension GL_ARB_pixel_buffer_object
> 
> FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028)
> (1, 0) = [1.000000, 1.000000, 1.000000], should be [1.0, 1.0, 1.0]
> pbo:  NOTE perf[0] = 372.891 MB/s, which is in normal mode
> pbo:  NOTE perf[1] = 261.088 MB/s, which is using PBO
> pbo:  FAIL rgba8, db, z24, s8, win+pmap, id 33
> 	9 tests passed, 1 tests failed.

That's pretty weird.  I was pretty sure that glean checked for equality
by making sure the difference was below some threshold.  As far as I can
tell, fabs(1.000000 - 1.0) should be below any reasonable threshold.
There's clearly something else going wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuUJLYACgkQX1gOwKyEAw/MPQCfZ8b/sSBRR8yN8z9u6tQrlY7J
+4sAnRKvgpboQ8D3ObcNwW5lEUKudPPv
=5D6f
-----END PGP SIGNATURE-----

[Mesa3d-dev] Summer of Code ideas

[Stephane M. <ste...@gm...>]

Hey guys,

Summer of code is coming on us. I need you to help fill/correct the
ideas page at
http://wiki.x.org/wiki/SummerOfCodeIdeas

I moved some 2009 ideas which are still relevant into 2010. But I
don't really know about the state of subsystems I don't follow, for
example I know nothing about xcb or input.

So I'd be grateful if you could update it and move the relevant ideas
to 2010, or add new ideas.

Thanks,
Stephane

Re: [Mesa3d-dev] gallium cached bufmgr busy change

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

On Sun, Mar 7, 2010 at 9:44 PM, Luca Barbieri <luc...@gm...> wrote:
> I think you are supposed to do this using the fenced bufmgr over
> cached along with a (ideally userspace) fencing mechanism.
> If you can implement pb_busy, you should be able to implement
> fence_signalled in exactly the same way (making the fence handle a
> pointer to buffers should work for this purpose, if standalone fences
> are hard to do).
> The fenced bufmgr will only pass destruction requests to the wrapped
> bufmgr once the fences are signalled.
>

It just seemed a bit heavyweight, I don't want userspace fences, so why
do I have to jump though abstraction hoops?

The fencing solution isn't near as efficent from what I can see, as it
is designed around fences not buffer busy, I'll see if I can give it a try,
but I suspect it look and smell like a hack.

Dave.

Re: [Mesa3d-dev] Probably, i monkeyed in wrong direction .....

[Mike K. <mik...@gm...>]

2010/3/6  <ran...@gm...>:
> В сообщении от Friday 05 March 2010 23:49:03 Stephane Marchesin написал(а):
>> 2010/3/5  <ran...@gm...>:
>> > В сообщении от Friday 05 March 2010 16:55:20 Jesse Barnes написал(а):
>> >> make realclean and configure and make again.
>> >
>> > Removing all new functions and reverting to mainstream mesa works OK,
>> > even without realclean ... So, it is purely my fault, as coder. But what
>> > exactly I forgot? Init current_primitive = -1 on context creation?  State
>> > management in nouveau changed since first dri1 attempt ....
>> >
>> > As far as i understand this code - you  plug in not just fev line
>> > functions but two big function tables, filled with many functions
>> > (pointers at functions). This way one can plug in much more optimized
>> > (for different OpenGL cases) render functions, if hw permits this. So,
>> > you plug inly one "Chooser" function into mesa's TNL module, and  keep
>> > current primitive type somewhere in your context data .....
>> >
>> > Ideally, various fixups (like polygonOffset) will be layred on top of
>> > this, making nv04.render.c a bit hard for reading ...
>> >
>> > Thanks Jesse and Francisco for your time, you spended reading my mails
>> > and trying to figure out what was my fault ....
>>
>> As discussed on irc, and for posterity:
>>
>> 00:35 < marcheu> you have a 16 or 8 (with multitexture) vertex cache
>> 00:35 < marcheu> these number you see (0xFEDCBA) are not magic
>> 00:35 < marcheu> these are the index of the vertices we want to emit
>> 00:36 < marcheu> so FEDCBA emits vertices 15,14,13,12,11 and 10
>> 00:36 < marcheu> but that means you have to actually place data at
>> these locations
>> 00:37 < marcheu> which means that if you want to do a single-pass
>> emission you have to place the first vertex at spot 10
>> 00:37 < marcheu> so basically the layout of the nv4 3D object is like that:
>> 00:37 < marcheu> - vertex 0
>> 00:37 < marcheu> - vertex 1
>> 00:37 < marcheu> ...
>> 00:37 < marcheu> - vertex 15
>> 00:38 < marcheu> - vertex indices that we want fired
>> 00:38 < marcheu> so if you want to do a 1-swoop submission, you have
>> to start from 10 or so
>> 00:38 < marcheu> that also means you _place_ vertex data at the right
>> spot. right now you place it at 0
>> 00:39 < marcheu> also you reserve one too little places on the fifo (6
>> instead of 7 on line 206)
>> 00:39 < marcheu> becuase you need one spot for the FEDCBA
>> 00:39 < marcheu> so you need 3 things:
>> 00:39 < marcheu> - start emitting at the right place, which probably
>> means an extra argument to BEGIN_PRIMITIVE to tell which place
>> 00:40 < marcheu> - increase the size of the BEGIN_PRIMITIVE
>> 00:40 < marcheu> - that was only two things :)
>>
>> Stephane
>
> New patch is here, tested with trivial/tri, DANGEROUS, may lock up your
> machine hard with anything else!
>
> Strange thing about code - in function swtnl_render_triangles_verts it was
> going on and on, causing segfault, until i added
>
> if (count == 3)
>        {
>        swtnl_triangle(ctx, i+0,i+1,i+2);
>        return;
>        }
>
>
> Was found under gdb
>
> =======
>
> swtnl_render_triangles_verts (ctx=0x950ca88, start=0, count=3, flags=52)
>    at nv04_render.c:285
> 285             for(i=start;i<count-5;i+=6)
> (gdb) print i
> $1 = 18
>
> =======
>
> Please, someone, enlight me on this small C secret, what was wrong in this
> for() ?
>

count is GLuint, i.e. unsigned. If count < 5, count-5 ~ around 4
billion due to overflow. Changing the check to i+5 < count should make
it work.

Mike.

[Mesa3d-dev] dri-extension branch - clean up advertising extensions in Gallium

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

This branch is aimed to address the following issues:
* Extensions are advertised in both st/mesa and st/dri, doing the same thing
in two places.
* The inability to disable extensions in pipe_screen::get_param because
st/dri overrides the decisions of st/mesa.

Here's the branch:
http://cgit.freedesktop.org/~mareko/mesa/log/?h=dri-extensions

The first commit moves the differences between st/dri and st/mesa to the
latter and removes dri_init_extensions from st/dri. It doesn't remove any
extensions from the list except for those not advertised by pipe_screen.

The second commit enables texture_rectangle by default in Gallium. To my
knowledge any Gallium hardware can do this and I suspect it was dependent on
NPOT textures by accident.

All this is of course tested with piglit and glean.

Please review. In case it's not OK, please let me know what needs to be
done.

-Marek

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[The F. <fu...@yu...>]

On Sun, Mar 07, 2010 at 05:18:04PM +0100, Florian Mickler wrote:
[...]
> i could manage it somewhat... one problem i had, was that after a
> while the screen-saver would disable my displays and then glxgears
> wouldnt hang anymore...  (where to disable that?)
[...]

Some combination of:

xset -dpms

xset s off

xset s noblank

The first one is probably sufficient to keep X from powering down
the display, however.
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yu...); IRC(fu...@ir...#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yu...);
MUD(fu...@ka...:6669); WWW(http://fungi.yuggoth.org/); }

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Maxim L. <max...@gm...>]

On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote:
> On Sat, 06 Mar 2010 16:40:27 +0200
> Maxim Levitsky <max...@gm...> wrote:
> 
> > On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: 
> > > On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
> > > > On Fri, 05 Mar 2010 23:48:48 +0200
> > > > Maxim Levitsky <max...@gm...> wrote:
> > > > 
> > > > > On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote:
> > > > > > On Fri, 05 Mar 2010 23:18:07 +0200
> > > > > > Maxim Levitsky <max...@gm...> wrote:
> > > > > > 
> > > > > > > On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote:
> > > > > > > > On Fri, 05 Mar 2010 22:42:21 +0200
> > > > > > > > Maxim Levitsky <max...@gm...> wrote:
> > > > > > > > 
> > > > > > > > > After quite long period of inactivity, I updated graphical stack on my
> > > > > > > > > desktop/server.
> > > > > > > > > 
> > > > > > > > > To say the truth, I did such update about month ago, but found out that
> > > > > > > > > X refuses flatly to use DRI modules. I assumed that it was my mistake in
> > > > > > > > > compilation process (although it is automated).
> > > > > > > > 
> > > > > > > > That generally indicates a build or config problem of some kind.  Did
> > > > > > > > you ever narrow it down?
> > > > > > > Because the same compile process works now, I suspect that wasn't build
> > > > > > > failure.
> > > > > > 
> > > > > > Well something weird is going on; maybe you didn't build X after Mesa
> > > > > > or with the right Mesa includes?
> > > > > I am very sure that this issue isn't relevant now.
> > > > > 
> > > > > I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in
> > > > > that order, compiling everything from scratch (doing git clean -dfx in
> > > > > all directories)
> > > > 
> > > > if you just want a working setup, perhaps you should try using
> > > > something that got (probably) tested by at least some people:
> > > >  	http://intellinuxgraphics.org/2009Q4.html
> > > > cheers,
> > > > Flo
> > > 
> > > Well, I now have a working setup with mesa 
> > > ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5
> > > 
> > > The problem is that I hoped that once all heavy work in regard to KMS
> > > was done, there will be no serious regressions in 3D stack, but only bug
> > > fixes, because it is very hard to track and fix bugs there.
> > > 
> > > However, once again 3D stack is in bad shape, and this is not good.
> > 
> > 
> > More testing shows the following behaviour:
> > 
> > 
> > 
> > Full screen mode is completely busted. As soon as any 3D application
> > switches to full screen mode, even without changing the resolution, it
> > hangs (note that I didn't see GPU hangs due to that)
> > 
> > Compiz is broken (its also a full screen app...). As soon as it starts,
> > it draws few windows, and then stalls.
> > 
> > In window mode all applications do work.
> > 
> > 
> > Now I guess this is worth a bugzilla entry.
> > (If this isn't there yet...)
> 
> I'm not seeing this on GM45.  I just installed a totally fresh stack on
> a new F12 installation and compiz and games work well.  But please file
> a bug and include everything needed (see intellinuxgraphics.org for the
> list); hope we can find the issue.
> 


Done:

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

I also opened a bug for other very annoying problem that was present for
long time.

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

Best regards,
	Maxim Levitsky 

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Florian M. <fl...@mi...>]

On Sat, 6 Mar 2010 15:11:59 -0800
Jesse Barnes <jb...@vi...> wrote:

> It would help to know what the server is doing at this point with the
> client.  It may be that it put the client to sleep and hasn't woken it
> up yet, or there could be something wrong with our getbuffers code in
> the new scheme.
> 
> Jesse
> 

i played a little with parallel debugging of glxgears and X ...

i could manage it somewhat... one problem i had, was that after a
while the screen-saver would disable my displays and then glxgears
wouldnt hang anymore...  (where to disable that?)

the other problem i faced was, that i could
happily step through the dispatch loop in the xserver and could also
break in the dri2GetBuffersWithFormat, but i didn't know what to look
at... what datastructures hold the xserver-side state of the client? 

hm.. i think i have to give that another go... 

cheers,
Flo

[Mesa3d-dev] [PATCH] nouveau/nv04: GL_EXT_secondary_color (v2)

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

git  apply has automatic whitespace fixup mode ...... 

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Stephan R. <mai...@op...>]

Hi Jesse,

Am 07.03.2010 00:11, schrieb Jesse Barnes:
> It would help to know what the server is doing at this point with the
> client.  It may be that it put the client to sleep and hasn't woken it
> up yet, or there could be something wrong with our getbuffers code in
> the new scheme.
>
>    
dont know if this help:

strace output from Xorg (1.1MB):
http://sources.openelec.tv/tmp/logfile/xbmc/Xorg.strace

strace output from my Application (1.4MB):
http://sources.openelec.tv/tmp/logfile/xbmc/xbmc.strace

i have only strace and gdb installed for debugging, let me know if i 
need other programs for debugging.

Stephan
> Jesse
>
> On Sat, 06 Mar 2010 18:02:51 +0100
> Stephan Raue<mai...@op...>  wrote:
>
>    
>> looks this like my problems that i have reported some days ago with
>> Subject "Problem using an Mesa based App with recent
>> xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
>>
>> i have still this issue, but i dont know what you need for informations
>> to fix the issues?
>>
>> with ati driver i dont have problems, only here with intel driver on my
>> Thinkpad X200t with intel HDA Graphics card
>>
>> Stephan
>>
>> Am 06.03.2010 17:46, schrieb Maxim Levitsky:
>>      
>>> On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote:
>>>
>>>        
>>>> On Sat, 06 Mar 2010 16:40:27 +0200
>>>> Maxim Levitsky<max...@gm...>   wrote:
>>>>
>>>>
>>>>          
>>>>> On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote:
>>>>>
>>>>>            
>>>>>> On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
>>>>>>
>>>>>>              
>>>>>>> On Fri, 05 Mar 2010 23:48:48 +0200
>>>>>>> Maxim Levitsky<max...@gm...>   wrote:
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>>> On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote:
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> On Fri, 05 Mar 2010 23:18:07 +0200
>>>>>>>>> Maxim Levitsky<max...@gm...>   wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>>>> On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote:
>>>>>>>>>>
>>>>>>>>>>                      
>>>>>>>>>>> On Fri, 05 Mar 2010 22:42:21 +0200
>>>>>>>>>>> Maxim Levitsky<max...@gm...>   wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                        
>>>>>>>>>>>> After quite long period of inactivity, I updated graphical stack on my
>>>>>>>>>>>> desktop/server.
>>>>>>>>>>>>
>>>>>>>>>>>> To say the truth, I did such update about month ago, but found out that
>>>>>>>>>>>> X refuses flatly to use DRI modules. I assumed that it was my mistake in
>>>>>>>>>>>> compilation process (although it is automated).
>>>>>>>>>>>>
>>>>>>>>>>>>                          
>>>>>>>>>>> That generally indicates a build or config problem of some kind.  Did
>>>>>>>>>>> you ever narrow it down?
>>>>>>>>>>>
>>>>>>>>>>>                        
>>>>>>>>>> Because the same compile process works now, I suspect that wasn't build
>>>>>>>>>> failure.
>>>>>>>>>>
>>>>>>>>>>                      
>>>>>>>>> Well something weird is going on; maybe you didn't build X after Mesa
>>>>>>>>> or with the right Mesa includes?
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> I am very sure that this issue isn't relevant now.
>>>>>>>>
>>>>>>>> I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in
>>>>>>>> that order, compiling everything from scratch (doing git clean -dfx in
>>>>>>>> all directories)
>>>>>>>>
>>>>>>>>                  
>>>>>>> if you just want a working setup, perhaps you should try using
>>>>>>> something that got (probably) tested by at least some people:
>>>>>>>    	http://intellinuxgraphics.org/2009Q4.html
>>>>>>> cheers,
>>>>>>> Flo
>>>>>>>
>>>>>>>                
>>>>>> Well, I now have a working setup with mesa
>>>>>> ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5
>>>>>>
>>>>>> The problem is that I hoped that once all heavy work in regard to KMS
>>>>>> was done, there will be no serious regressions in 3D stack, but only bug
>>>>>> fixes, because it is very hard to track and fix bugs there.
>>>>>>
>>>>>> However, once again 3D stack is in bad shape, and this is not good.
>>>>>>
>>>>>>              
>>>>> More testing shows the following behaviour:
>>>>>
>>>>>
>>>>>
>>>>> Full screen mode is completely busted. As soon as any 3D application
>>>>> switches to full screen mode, even without changing the resolution, it
>>>>> hangs (note that I didn't see GPU hangs due to that)
>>>>>
>>>>> Compiz is broken (its also a full screen app...). As soon as it starts,
>>>>> it draws few windows, and then stalls.
>>>>>
>>>>> In window mode all applications do work.
>>>>>
>>>>>
>>>>> Now I guess this is worth a bugzilla entry.
>>>>> (If this isn't there yet...)
>>>>>
>>>>>            
>>>> I'm not seeing this on GM45.  I just installed a totally fresh stack on
>>>> a new F12 installation and compiz and games work well.  But please file
>>>> a bug and include everything needed (see intellinuxgraphics.org for the
>>>> list); hope we can find the issue.
>>>>
>>>>          
>>> Here, gdb backtrace while running sauerbraten full screen:
>>>
>>>
>>> #2  0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1
>>> #3  0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
>>> #4  0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454
>>> #5  0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2,
>>>       outCount=0xbfc6a608) at dri2.c:428
>>> #6  0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608,
>>>       loaderPrivate=0x93eecb0) at dri2_glx.c:435
>>> #7  0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253
>>> #8  0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395
>>> #9  0xb657a423 in brw_try_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
>>>       min_index=0, max_index=3) at brw_draw.c:340
>>> #10 brw_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3)
>>>       at brw_draw.c:441
>>> #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384
>>> #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfffffdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872
>>> #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906
>>> #14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 '\001') at main/enable.c:283
>>> #15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007
>>> #16 0x080abf08 in ?? ()
>>> #17 0x080ad3fc in ?? ()
>>> #18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, rtld_fini=0xb789cd20<_dl_fini>,
>>>
>>>
>>> Best regards,
>>> 	Maxim Levitsky
>>>
>>> _______________________________________________
>>> Intel-gfx mailing list
>>> Int...@li...
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>
>>>
>>>        
>>
>>      
>
>    


-- 
               ### OpenELEC.tv ###
The free and open Mediacenter Distribution 4 you
              http://www.openelec.tv

Re: [Mesa3d-dev] gallium-winsys-handle-rebased branch

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

Dear Keith,
I've tried out your gallium-winsys-handle-rebased branch.I downloaded it as
a .tar.gz file instead of from git,as I couldn't download it that way.I
compiled and installed it with the same ./configure options I use for Mesa
git master,and I use the latest git versions of DRM,Linux-2.6/nouveau kernel
modules,and the xf86-video-nouveau driver.I'm currently using Fedora 13,and
my video card is:
01:00.0 VGA compatible controller: nVidia Corporation NV40 [GeForce 6800 GT]
(rev a1) (prog-if 00 [VGA controller])
After a re-boot there didn't seem to be any ill effects.
Regards,
             STEVE555
 

Keith Whitwell-3 wrote:
> 
> This branch is hopefully ready for broader testing ahead of a merge.
> 
> Can people, especially nv people, pull this down and try it out.  Jakob
> has made a best effort to get this right, but neither of us have
> hardware.
> 
> The branch itself is the start of a significant cleanup of some of the
> uglier bits of gallium, particularly the integration with cross-process
> shared surfaces, swapbuffers, etc.
> 
> Keith
> 
> 
> ------------------------------------------------------------------------------
> 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
> 
> 

-- 
View this message in context: http://old.nabble.com/gallium-winsys-handle-rebased-branch-tp27781621p27811209.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] gallium cached bufmgr busy change

[Luca B. <luc...@gm...>]

I think you are supposed to do this using the fenced bufmgr over
cached along with a (ideally userspace) fencing mechanism.
If you can implement pb_busy, you should be able to implement
fence_signalled in exactly the same way (making the fence handle a
pointer to buffers should work for this purpose, if standalone fences
are hard to do).
The fenced bufmgr will only pass destruction requests to the wrapped
bufmgr once the fences are signalled.

Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?

[Török E. <edw...@gm...>]

On 03/07/2010 01:00 AM, Ian Romanick wrote:
> Török Edwin wrote:
>> Hi Andre,
> 
>> I've been using your patch that enables pbo on r600:
>> http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7
> 
>> Are you considering enabling it in Mesa 7.8?
> 
> At this point the 7.8 branch is open for bug fixes *only*.  The
> announcement that the 7.8 branch would be created on March 5th went out
> on February 23th, and the release plan was discussed quite a few times
> before that.  That was plenty of time to nominate patches for inclusion.
> 
> It's probably okay to just enable ARB_pixel_buffer_object, but I'd be a
> bit nervous about the rest.  OpenGL 2.1 is more than just PBOs and GLSL
> 1.20.  Do the piglit and glean PBO tests pass on r600 with this patch?


I've run the piglit tests using tests/r500.tests, with glean in quick mode.

With patch: 620/686 pass
Without patch: 614/679 pass (I opened a bugreport about these failures
here: https://bugs.freedesktop.org/show_bug.cgi?id=26933)

The pbo tests results are:
glean/pbo: fail
general/pbo-teximage-tiling: pass
general/pbo-read-argb8888: pass
general/pbo-teximage-tiling-2: pass
general/pbo-drawpixels: pass
general/pbo-readpixels-small: pass
general/object_purgeable-api-pbo: skip
general/pbo-teximage: pass
fbo/fbo-pbo-readpixels-small: pass

The glean/fbo fail looks like some FP tolerance being too strict (1.0 vs
1.00000). Is there a way to accept 1.00000 for 1.0 in the piglit tests?

pbo test: Test OpenGL Extension GL_ARB_pixel_buffer_object

FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028)
(1, 0) = [1.000000, 1.000000, 1.000000], should be [1.0, 1.0, 1.0]
pbo:  NOTE perf[0] = 372.891 MB/s, which is in normal mode
pbo:  NOTE perf[1] = 261.088 MB/s, which is using PBO
pbo:  FAIL rgba8, db, z24, s8, win+pmap, id 33
	9 tests passed, 1 tests failed.


I've also run piglit w/o the patch applied, the pbo test were the only
ones that changed to skip (except for glean/pbo which was pass due to
extension not present).
So the rest of the piglit tests are unaffected by this patch (they
pass/fail the same way).

> 
>> Some games won't even start without pbo support (for example Heroes of
>> Newerth).
> 
>> Even if gameplay isn't perfect (there are some rendering artifacts[1],
>> and some effects are slow [2]) at least the game starts with that patch.
> 
>> [1] which is not related to your pbo patch, I see artifacts w/o it too
>> in other games, and blender:
>> https://bugs.freedesktop.org/show_bug.cgi?id=26735
>> [2] which can be turned off, like refraction

Best regards,
--Edwin

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Maxim L. <max...@gm...>]

On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote:
> On Sun, 07 Mar 2010 00:24:24 +0200
> Maxim Levitsky <max...@gm...> wrote:
> 
> > On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote:
> > > On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote:
> > > > On Sat, 06 Mar 2010 18:02:51 +0100
> > > > Stephan Raue <mai...@op...> wrote:
> > > > 
> > > > > looks this like my problems that i have reported some days ago with 
> > > > > Subject "Problem using an Mesa based App with recent 
> > > > > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> > > > > 
> > > > > i have still this issue, but i dont know what you need for informations 
> > > > > to fix the issues?
> > > > > 
> > > > > with ati driver i dont have problems, only here with intel driver on my 
> > > > > Thinkpad X200t with intel HDA Graphics card
> > > > > 
> > > 
> > > I now see that compiz hangs in same way.
> > > 
> > > Attached are backtrace of the compiz, and backtrace of etracer which did
> > > start full screen but became hung on resolution change.
> > > 
> > > Best regards,
> > > 	Maxim Levitsky
> > 
> > Other info that might help:
> > 
> > I took a look at X and found that it was in normal waiting state
> > sleeping waiting for input.
> > 
> > Also, I found when 'unstable' mesa would appear to work when I start the
> > X while 'stable' one is used. It was compiz. When compiz is running
> > using stable mesa, an game does change the resolution 'usualy' without
> > hang even if uses unstable mesa.
> > 
> > Best regards,
> > 	Maxim Levitsky
> 
> i found that the kernel updates for 2.6.34-rc1 did make the hang time
> out... this has to be some vblank issue, i assume...


Note that I did try git master of linus tree, and that didn't help with
the hang at all (now pulled it again, but don't see any  changes in drm
code)

Best regards,
	Maxim Levisky

[Mesa3d-dev] gallium cached bufmgr busy change

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

I've been playing with strategies to get r300 buffer management a bit
more efficient,

I've reworked the r300g screen/winsys and create a pb_bufmgr compliant
buffer class,
and stacked the cached buffer manager on top of it.

Now I've hit a problem in that we expose buffer busy state, but the
cached bufmgr
doesn't know to check if the buffer is busy before reusing it.

The attached patch adds a query for buffer busy to pb_bufmgr.h.

I've wondered if I can do this with some hacked up fences but it seems
like a lot
more work for not much gain.

Dave.

Re: [Mesa3d-dev] [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.

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

The attached patches change softpipe and llvmpipe so that they never provoke
the first vertex for quads. Please review. I think that these and the
Corbin's one could be pushed by now, couldn't they?

-Marek

On Thu, Feb 11, 2010 at 4:03 PM, Brian Paul <br...@vm...> wrote:

> Corbin Simpson wrote:
> >>From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001
> > From: Corbin Simpson <Mos...@gm...>
> > Date: Wed, 10 Feb 2010 10:39:18 -0800
> > Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking
> vertex.
> >
> > Fixes glean/clipFlat. Softpipe might be broken; I haven't figured out
> > how to test it in this new API world. :T
> > ---
> >  src/mesa/state_tracker/st_extensions.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/mesa/state_tracker/st_extensions.c
> > b/src/mesa/state_tracker/st_extensions.c
> > index d5f5854..e2d871b 100644
> > --- a/src/mesa/state_tracker/st_extensions.c
> > +++ b/src/mesa/state_tracker/st_extensions.c
> > @@ -137,6 +137,9 @@ void st_init_limits(struct st_context *st)
> >     /* XXX separate query for early function return? */
> >     st->ctx->Shader.EmitContReturn =
> >        screen->get_param(screen, PIPE_CAP_TGSI_CONT_SUPPORTED);
> > +
> > +   /* Quads always follow GL provoking rules. */
> > +   c->QuadsFollowProvokingVertexConvention = GL_FALSE;
> >  }
>
> This causes the glean clipFlat test to fail with softpipe.  The
> gallium softpipe driver _does_ implement the "quad follows provoking
> vertex" convention.
>
> I don't have time right now to update the softpipe driver so this
> patch will have to wait a while.  Maybe someone else can look at it
> sooner.
>
> -Brian
>
>
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>

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

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

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





--- Comment #4 from José Fonseca <jfo...@vm...>  2010-03-06 16:57:43 PST ---
You sample works fine here with the Gallium version. Since the error was in the
shared Mesa code I expect it should be working with the non-gallium driver too.


-- 
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.

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

On Sat, 2010-03-06 at 05:44 -0800, Brian Paul wrote:
> On Sat, Mar 6, 2010 at 5:44 AM, José Fonseca <jfo...@vm...> wrote:
> > 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.
> >
> > It's not only implementation dependent and slow -- it is also buggy!
> >
> > gcc-4.4.3 is doing something very fishy to single bit fields.
> >
> > See the attached code. ff ff ff ff is expected, but ff ff ff 01 is
> > printed with gcc-4.4.3. Even without any optimization. gcc-4.3.4 works
> > fine.
> >
> > Am I missing something or is this effectively a bug?
> 
> Same result with gcc 4.4.1.
> 
> If pixel.chan.a is put into a temporary int var followed by the
> scaling arithmetic it comes out as expected.  Looks like a bug to me.

Thanks. I'll submit a bug report then.

> BTW, it looks like sizeof(union util_format_b5g5r5a1_unorm) == 4, not 2.

Yet another reason to stay away from bit fields..

Jose