mesa3d-dev

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Nicolai H. <nha...@gm...>]

Reply to all this time...

On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák <ma...@gm...> wrote:
>> > 1) Branching and looping
>> >
>> > This is the most important one and there are 3 things which need to be
>> > done.
>> > * Unrolling loops and converting conditionals to multiplications. This
>> > is
>> > crucial for R3xx-R4xx GLSL support. I don't say it will work in all
>> > cases
>> > but should be fine for the most common ones. This is kind of a standard
>> > in
>> > all proprietary drivers supporting shaders 2.0. It would be nice have it
>> > work with pure TGSI shaders so that drivers like nvfx can reuse it too
>> > and I
>> > personally prefer to have this feature first before going on.
>>
>> Would you be able to provide a small example of how to convert the
>> conditionals to multiplications?  I understand the basic idea is to mask
>> values based on the result of the conditional, but it would help me to see
>> an example.  On IRC, eosie mentioned an alternate technique for emulating
>> conditionals: Save the values of variables that might be affected by
>> the conditional statement.  Then, after executing both the if and the else
>> branches, roll back the variables that were affected by the branch that
>> was not supposed to be taken. Would this technique work as well?
>
> Well, I am eosie, thanks for the info, it's always cool to be reminded what
> I've written on IRC. ;)
>
> Another idea was to convert TGSI to a SSA form. That would make unrolling
> branches much easier as the Phi function would basically become a linear
> interpolation, loops and subroutines with conditional return statements
> might be trickier. The r300 compiler already uses SSA for its optimization
> passes so maybe you wouldn't need to mess with TGSI that much...

Note that my Git repository already contains an implementation of
branch emulation and some additional optimizations, see here:
http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glsl

Shame on me for abandoning it - I should really get around to make
sure it fits in with recent changes and merge it to master. The main
problem is that it produces "somewhat" inefficient code. Adding and
improving peephole and similar optimizations should help tremendously.

<snip>
>> > 2) Derivatives instructions fix
>> >
>> > It's implemented but broken. From docs: "If src0 is computed in the
>> > previous
>> > instruction, then a NOP needs to be inserted between the two
>> > instructions.
>> > Do this by setting the NOP flag in the previous instruction. This is not
>> > required if the previous instruction is a texture lookup." .. and that
>> > should be the fix.
>>
>> Is the only problem here that NOP is being inserted after texture
>> lookups when it shouldn't be?
>
> Well the derivatives don't work and NOP is not being inserted anywhere. The
> quoted statement from the docs was supposed to give you a clue. NOP after a
> texture lookup is *not required*, that means it would be just silly to put
> it there but it shouldn't break anything.

I seem to recall that there is a bit in the opcodes to have a NOP
cycle without actually inserting a NOP instruction. This might be more
inefficient. I've never actually tested it.

cu,
Nicolai

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

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

On Tue, Mar 30, 2010 at 7:09 AM, Tom Stellard <tst...@gm...> wrote:

> On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote:
> >
> > From the driver point of view, we don't have to work on the GLSL compiler
> > itself. The Mesa state tracker compiles GLSL to an assembler-like
> language
> > called TGSI which is then translated ([1]) to the R300 compiler ([2])
> shader
> > representation. The more TGSI we handle, the more GLSL support we get.
> >
>
> Is adding support for the TGSI opcodes that are currently ignored by
> r300_tgsi_to_rc.c something that needs to be done?  If so, are there
> some opcodes you would prefer to see done first?
>

One of the goals might be to pass all relevant piglit tests including
glean/glsl1 which exercises various opcodes but it's not so important and
I'd be surprised if you would make it in your timeframe. You may use it for
testing though.


> > So now the status. r300g GLSL is missing the following features:
> >
> > 1) Branching and looping
> >
> > This is the most important one and there are 3 things which need to be
> done.
> > * Unrolling loops and converting conditionals to multiplications. This is
> > crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases
> > but should be fine for the most common ones. This is kind of a standard
> in
> > all proprietary drivers supporting shaders 2.0. It would be nice have it
> > work with pure TGSI shaders so that drivers like nvfx can reuse it too
> and I
> > personally prefer to have this feature first before going on.
>
> Would you be able to provide a small example of how to convert the
> conditionals to multiplications?  I understand the basic idea is to mask
> values based on the result of the conditional, but it would help me to see
> an example.  On IRC, eosie mentioned an alternate technique for emulating
> conditionals: Save the values of variables that might be affected by
> the conditional statement.  Then, after executing both the if and the else
> branches, roll back the variables that were affected by the branch that
> was not supposed to be taken. Would this technique work as well?
>

Well, I am eosie, thanks for the info, it's always cool to be reminded what
I've written on IRC. ;)

Another idea was to convert TGSI to a SSA form. That would make unrolling
branches much easier as the Phi function would basically become a linear
interpolation, loops and subroutines with conditional return statements
might be trickier. The r300 compiler already uses SSA for its optimization
passes so maybe you wouldn't need to mess with TGSI that much...


> Is the conditional translation something that only needs to be done
> in the Gallium drivers, or would it be useful to apply the translation
> before the Mesa IR is converted into TGSI?  Are any of the other drivers
> (Gallium or Mesa) currently doing this kind of translation?
>

Not that I know of. You may do it wherever you want theoretically, even in
the r300 compiler and leaving TGSI untouched, but I think most people would
appreciate if these translation were done in TGSI.


> > * Teaching the R300 compiler loops and conditionals for R500 fragment
> > shaders. Note that R500 supports the jump instruction so besides adding
> new
> > opcodes, the compiler optimization passes should be updated too (I think
> > they haven't been designed with loops in mind).
> > * The same but for R500 vertex shaders. The difference is conditionals
> must
> > be implemented using predication opcodes and predication writes (stuff
> gets
> > masked out). I think this only affects the conversion to machine code at
> the
> > end of the pipeline.
> >
> > 2) Derivatives instructions fix
> >
> > It's implemented but broken. From docs: "If src0 is computed in the
> previous
> > instruction, then a NOP needs to be inserted between the two
> instructions.
> > Do this by setting the NOP flag in the previous instruction. This is not
> > required if the previous instruction is a texture lookup." .. and that
> > should be the fix.
>
> Is the only problem here that NOP is being inserted after texture
> lookups when it shouldn't be?
>

Well the derivatives don't work and NOP is not being inserted anywhere. The
quoted statement from the docs was supposed to give you a clue. NOP after a
texture lookup is *not required*, that means it would be just silly to put
it there but it shouldn't break anything.

-Marek

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

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

Corbin Simpson schrieb:
> On Mon, Mar 29, 2010 at 5:50 PM, Ian Romanick <id...@fr...> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Philipp Klaus Krause wrote:
>>
>>> Well, there is TexSubImage2D. Assuming we have a compressed texture
>>> stored internally as some S3TC format and then the application replaces
>>> part of it using TexSubImage2D. According to ARB_texture_compression we
>>> may not go to uncompressed ("the allocation and chosen compressed image
>>> format must not be a function of any other state and cannot be changed
>>> once they are established". And while ARB_texture_compression does not
>>> require TexSubImage2D support, EXT_texture_compression_s3tc does.
>> Ah.  Good catch.  My best guess is that there are few, if any, apps that
>> do that.  Such apps would be easy to detect.  We could enable the
>> non-conformant behavior by default, and provide a driconf switch to
>> disable it.  We'd then need to blacklist apps that use unsupported
>> cases.  Since we can detect these cases, we can log a message when the
>> occur.
>>
>> Does that seem like a reasonable compromise?
> 
> We don't have to compromise at all. If the image is already compressed
> internally, then updating it with TexSubImage or CompressedTexSubImage
> must be done along the block boundaries,

Yes.

> and must be done with
> pre-compressed blocks,

Why?

> so we are never decompressing and recompressing
> the texture.

Philipp

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

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

On Mon, Mar 29, 2010 at 10:09 PM, Tom Stellard <tst...@gm...> wrote:
> On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote:
>>
>> From the driver point of view, we don't have to work on the GLSL compiler
>> itself. The Mesa state tracker compiles GLSL to an assembler-like language
>> called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader
>> representation. The more TGSI we handle, the more GLSL support we get.
>>
>
> Is adding support for the TGSI opcodes that are currently ignored by
> r300_tgsi_to_rc.c something that needs to be done?  If so, are there
> some opcodes you would prefer to see done first?
>
>> So now the status. r300g GLSL is missing the following features:
>>
>> 1) Branching and looping
>>
>> This is the most important one and there are 3 things which need to be done.
>> * Unrolling loops and converting conditionals to multiplications. This is
>> crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases
>> but should be fine for the most common ones. This is kind of a standard in
>> all proprietary drivers supporting shaders 2.0. It would be nice have it
>> work with pure TGSI shaders so that drivers like nvfx can reuse it too and I
>> personally prefer to have this feature first before going on.
>
> Would you be able to provide a small example of how to convert the
> conditionals to multiplications?  I understand the basic idea is to mask
> values based on the result of the conditional, but it would help me to see
> an example.  On IRC, eosie mentioned an alternate technique for emulating
> conditionals: Save the values of variables that might be affected by
> the conditional statement.  Then, after executing both the if and the else
> branches, roll back the variables that were affected by the branch that
> was not supposed to be taken. Would this technique work as well?
>
> Is the conditional translation something that only needs to be done
> in the Gallium drivers, or would it be useful to apply the translation
> before the Mesa IR is converted into TGSI?  Are any of the other drivers
> (Gallium or Mesa) currently doing this kind of translation?
>
>> * Teaching the R300 compiler loops and conditionals for R500 fragment
>> shaders. Note that R500 supports the jump instruction so besides adding new
>> opcodes, the compiler optimization passes should be updated too (I think
>> they haven't been designed with loops in mind).
>> * The same but for R500 vertex shaders. The difference is conditionals must
>> be implemented using predication opcodes and predication writes (stuff gets
>> masked out). I think this only affects the conversion to machine code at the
>> end of the pipeline.
>>
>> 2) Derivatives instructions fix
>>
>> It's implemented but broken. From docs: "If src0 is computed in the previous
>> instruction, then a NOP needs to be inserted between the two instructions.
>> Do this by setting the NOP flag in the previous instruction. This is not
>> required if the previous instruction is a texture lookup." .. and that
>> should be the fix.
>
> Is the only problem here that NOP is being inserted after texture
> lookups when it shouldn't be?
>
>> 3) Perspective, flat, and centroid varying modifiers, gl_FrontFacing
>>
>> I think this is specific to the rasterizer (RS) block in hw ([3]).
>>
>
> For my proposal, I am thinking about a schedule that looks
> something like this (in this order):
>
> 1) Branching and looping - 4 to 6 weeks
> 2) Derivatives instructions fix - 1 to 2 weeks
> 3) Adding support for priority TGSI_OPCODES - 3 to 4 weeks
> 4) Perspective, flat, and centroid varying modifiers, gl_FrontFacing
>        and Adding support for more TGSI_OPCODES - (if there is time left)*
>
> *GSOC lasts for 12 weeks.
>
> I would appreciate feedback on the order or the time estimates in this
> schedule.  I am sure some of the developers will have a better idea
> how long some of these tasks might take.  Also, if there is something
> important that I am leaving out or something not important that I have
> included let me know.

This seems reasonable. The missing opcodes are all related to branches
and loops, AFAIR, so you'll be working with those. Go ahead and set up
your proposal on the GSoC site; we'll let you know if it needs tuning
or tweaking.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

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

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Tom S. <tst...@gm...>]

On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote:
> 
> From the driver point of view, we don't have to work on the GLSL compiler
> itself. The Mesa state tracker compiles GLSL to an assembler-like language
> called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader
> representation. The more TGSI we handle, the more GLSL support we get.
> 

Is adding support for the TGSI opcodes that are currently ignored by
r300_tgsi_to_rc.c something that needs to be done?  If so, are there
some opcodes you would prefer to see done first?

> So now the status. r300g GLSL is missing the following features:
> 
> 1) Branching and looping
> 
> This is the most important one and there are 3 things which need to be done.
> * Unrolling loops and converting conditionals to multiplications. This is
> crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases
> but should be fine for the most common ones. This is kind of a standard in
> all proprietary drivers supporting shaders 2.0. It would be nice have it
> work with pure TGSI shaders so that drivers like nvfx can reuse it too and I
> personally prefer to have this feature first before going on.

Would you be able to provide a small example of how to convert the
conditionals to multiplications?  I understand the basic idea is to mask
values based on the result of the conditional, but it would help me to see
an example.  On IRC, eosie mentioned an alternate technique for emulating
conditionals: Save the values of variables that might be affected by
the conditional statement.  Then, after executing both the if and the else
branches, roll back the variables that were affected by the branch that
was not supposed to be taken. Would this technique work as well?

Is the conditional translation something that only needs to be done
in the Gallium drivers, or would it be useful to apply the translation
before the Mesa IR is converted into TGSI?  Are any of the other drivers
(Gallium or Mesa) currently doing this kind of translation?

> * Teaching the R300 compiler loops and conditionals for R500 fragment
> shaders. Note that R500 supports the jump instruction so besides adding new
> opcodes, the compiler optimization passes should be updated too (I think
> they haven't been designed with loops in mind).
> * The same but for R500 vertex shaders. The difference is conditionals must
> be implemented using predication opcodes and predication writes (stuff gets
> masked out). I think this only affects the conversion to machine code at the
> end of the pipeline.
> 
> 2) Derivatives instructions fix
> 
> It's implemented but broken. From docs: "If src0 is computed in the previous
> instruction, then a NOP needs to be inserted between the two instructions.
> Do this by setting the NOP flag in the previous instruction. This is not
> required if the previous instruction is a texture lookup." .. and that
> should be the fix.

Is the only problem here that NOP is being inserted after texture
lookups when it shouldn't be?

> 3) Perspective, flat, and centroid varying modifiers, gl_FrontFacing
> 
> I think this is specific to the rasterizer (RS) block in hw ([3]).
> 

For my proposal, I am thinking about a schedule that looks
something like this (in this order):

1) Branching and looping - 4 to 6 weeks
2) Derivatives instructions fix - 1 to 2 weeks
3) Adding support for priority TGSI_OPCODES - 3 to 4 weeks
4) Perspective, flat, and centroid varying modifiers, gl_FrontFacing
	and Adding support for more TGSI_OPCODES - (if there is time left)*

*GSOC lasts for 12 weeks.

I would appreciate feedback on the order or the time estimates in this
schedule.  I am sure some of the developers will have a better idea
how long some of these tasks might take.  Also, if there is something
important that I am leaving out or something not important that I have
included let me know.

Thanks.

-Tom Stellard

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

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

On Mon, Mar 29, 2010 at 5:50 PM, Ian Romanick <id...@fr...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Philipp Klaus Krause wrote:
>
>> Well, there is TexSubImage2D. Assuming we have a compressed texture
>> stored internally as some S3TC format and then the application replaces
>> part of it using TexSubImage2D. According to ARB_texture_compression we
>> may not go to uncompressed ("the allocation and chosen compressed image
>> format must not be a function of any other state and cannot be changed
>> once they are established". And while ARB_texture_compression does not
>> require TexSubImage2D support, EXT_texture_compression_s3tc does.
>
> Ah.  Good catch.  My best guess is that there are few, if any, apps that
> do that.  Such apps would be easy to detect.  We could enable the
> non-conformant behavior by default, and provide a driconf switch to
> disable it.  We'd then need to blacklist apps that use unsupported
> cases.  Since we can detect these cases, we can log a message when the
> occur.
>
> Does that seem like a reasonable compromise?

We don't have to compromise at all. If the image is already compressed
internally, then updating it with TexSubImage or CompressedTexSubImage
must be done along the block boundaries, and must be done with
pre-compressed blocks, so we are never decompressing and recompressing
the texture.

I've pushed a branch, s3tc-by-the-book, to my personal repo
(http://cgit.freedesktop.org/~csimpson/mesa/?h=s3tc-by-the-book), that
changes to this newer behavior. I haven't written up test cases for
these delightful corners and edges we're finding, but they shouldn't
be too hard to handle. The basic idea behind this branch is that if
the internal format request indicates that GL should compress the
texture with S3TC, but we don't have libdxtn present, we just change
the internal format to something more sensible and refuse to compress.

Comments and flames welcome.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

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

Re: [Mesa3d-dev] Merging gallium-st-api

[Chia-I Wu <ol...@gm...>]

On Tue, Mar 30, 2010 at 5:53 AM, José Fonseca <jfo...@vm...> wrote:
> This is visinfo:
>
>  {visual = 0x617588, visualid = 37, screen = 0, depth = 16, class = 4,
> red_mask = 63, green_mask = 1984, blue_mask = 63488, colormap_size =
> 64,
>  bits_per_rgb = 8}
>
> The problem is that {red,green,blue,alpha}_bits are {6, 5, 5, 0}, but
> Gallium only supports {5, 6, 5, 0}, i.e. PIPE_FORMAT_B5G6R5_UNORM.
>
> Somewhere before we should be marking this visual as unsupported, but we don't.
Thanks.  This should be fixed by commit c1a392.  Unsupported visuals are now
ignored.

-- 
ol...@Lu...

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

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

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

Philipp Klaus Krause wrote:

> Well, there is TexSubImage2D. Assuming we have a compressed texture
> stored internally as some S3TC format and then the application replaces
> part of it using TexSubImage2D. According to ARB_texture_compression we
> may not go to uncompressed ("the allocation and chosen compressed image
> format must not be a function of any other state and cannot be changed
> once they are established". And while ARB_texture_compression does not
> require TexSubImage2D support, EXT_texture_compression_s3tc does.

Ah.  Good catch.  My best guess is that there are few, if any, apps that
do that.  Such apps would be easy to detect.  We could enable the
non-conformant behavior by default, and provide a driconf switch to
disable it.  We'd then need to blacklist apps that use unsupported
cases.  Since we can detect these cases, we can log a message when the
occur.

Does that seem like a reasonable compromise?

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

iEYEARECAAYFAkuxSscACgkQX1gOwKyEAw99AwCdHYd9V9UYoQjCIKWKEwHOwKYf
8foAnAzeWMIRlKWasWxiqxEmIxE4sXa1
=W4xK
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.7.1 and Mesa 7.8 released!

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

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

Dan Nicholson wrote:
> On Mon, Mar 29, 2010 at 11:03 AM, Brian Paul <br...@vm...> wrote:
>> Brian Paul wrote:
>>> Ian Romanick wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Brian Paul wrote:
>>>>> Ian Romanick wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Final versions of both Mesa 7.8 and 7.7.1 have been released.  Links on
>>>>>> the Mesa website will still need to be updated, but I think Brian has to
>>>>>> do that.
>>>>> I'll do that soon.
>>>>>
>>>>>
>>>>>> The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'.  I had
>>>>>> originally intended to just use 7.8, but having a tag and a branch with
>>>>>> the same name makes GIT angry (i.e., you get "warning: refname '7.8' is
>>>>>> ambiguous.").
>>>>> Yeah, that's what I'm getting now - and I can't seem to update my 7.8
>>>>> branch to the latest commit:
>>>>>
>>>>> $ git rebase origin/7.8
>>>>> warning: refname '7.8' is ambiguous.
>>>>> Current branch 7.8 is up to date.
>>>>>
>>>>> I'm stuck at commit 59258498dc6fa51573b176d071644bd3e750b5ac now.  Help?
>>>> Hmm... I did 'git tag -d 7.8' and that fixed the problem locally.  I
>>>> thought pushing tags afterwards would delete the remote tag, but
>>>> apparently not.  I'll try to solve that today.
>>> OK, "git tag -d 7.8" fixed the problem here.
>> Grrr, the 7.8 tag comes back after a git-fetch though.
> 
> You might just have to go on annarchy and do "git --git-dir=$the_repo
> tag -d 7.8". You might also be able to push an empty source to the
> remote with "git push origin :refs/tags/7.8".

It looks like airlied fixed this for us.  Thanks Dave!

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

iEYEARECAAYFAkuxScIACgkQX1gOwKyEAw/+nwCZARUvIojvbGeao5EGTXOhmH+v
b/AAn0ck1D2wnvlTLlDEEoHMOy8XcEJI
=zg1N
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Merging gallium-st-api

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

On Tue, 2010-03-16 at 08:36 -0700, Chia-I Wu wrote:
> On Tue, Mar 16, 2010 at 9:45 PM, José Fonseca <jfo...@vm...> wrote:
> > On Tue, 2010-03-16 at 01:41 -0700, Chia-I Wu wrote:
> >> On Tue, Mar 16, 2010 at 9:40 AM, Chia-I Wu <ol...@gm...> wrote:
> >> > On Mon, Mar 15, 2010 at 8:04 PM, Keith Whitwell <ke...@vm...> wrote:
> >> >> I'm very happy to see it merged - it's a nice cleanup of the
> >> >> state-tracker behaviours.
> >> > Great!  I would like to do the merge later today.
> >> Done.
> >>
> >> I will go on to convert the remaining co state trackers, i.e. st/dri and
> >> st/wgl, and hopefully drop st_public.h support soon.
> > I'm seeing an assertion failure with a softpipe/llvmpipe libGL.so
> > together with vncserver, running any GL application. (It appears to work
> > fine with a regular Xorg server).
> > I can't look into this immediately. Can you tell what's the problem?
> >
> > Jose
> >
> > Core was generated by `./glean --run results --overwrite --quick --tests
> > basic --visuals id == 33'.
> > Program terminated with signal 5, Trace/breakpoint trap.
> > #0  0x00007fefb746b59a in _debug_assert_fail (expr=0x7fefb7b30157 "0",
> >    file=0x7fefb7b30110 "src/gallium/state_trackers/glx/xlib/xm_api.c",
> >    line=308, function=0x7fefb7b30430 "choose_pixel_format")
> >    at src/gallium/auxiliary/util/u_debug.c:201
> >        in src/gallium/auxiliary/util/u_debug.c
> > #0  0x00007fefb746b59a in _debug_assert_fail (expr=0x7fefb7b30157 "0",
> >    file=0x7fefb7b30110 "src/gallium/state_trackers/glx/xlib/xm_api.c",
> >    line=308, function=0x7fefb7b30430 "choose_pixel_format")
> >    at src/gallium/auxiliary/util/u_debug.c:201
> > No locals.
> > #1  0x00007fefb7249adf in choose_pixel_format (v=0x2279fb0)
> >    at src/gallium/state_trackers/glx/xlib/xm_api.c:308
> >        native_byte_order = 1 '\001'
> >        __FUNCTION__ = "choose_pixel_format"
> > #2  0x00007fefb724a3a9 in XMesaCreateVisual (display=0x222ecb0,
> >    visinfo=0x2238dd0, rgb_flag=1 '\001', alpha_flag=0 '\000',
> >    db_flag=1 '\001', stereo_flag=0 '\000', ximage_flag=1 '\001',
> >    depth_size=24, stencil_size=8, accum_red_size=16, accum_green_size=16,
> >    accum_blue_size=16, accum_alpha_size=16, num_samples=0, level=0,
> >    visualCaveat=32768) at src/gallium/state_trackers/glx/xlib/xm_api.c:712
> >        xmdpy = 0x7fefb80473e0
> >        v = 0x2279fb0
> >        red_bits = 6
> >        green_bits = 5
> >        blue_bits = 5
> >        alpha_bits = 0
> >        __FUNCTION__ = "XMesaCreateVisual"
> I cannot reproduce the assertion failure here.  Can you print the contents of
> visinfo in this stack frame so help me diagnose the issue?

This is visinfo:

  {visual = 0x617588, visualid = 37, screen = 0, depth = 16, class = 4,
red_mask = 63, green_mask = 1984, blue_mask = 63488, colormap_size =
64, 
  bits_per_rgb = 8}

The problem is that {red,green,blue,alpha}_bits are {6, 5, 5, 0}, but
Gallium only supports {5, 6, 5, 0}, i.e. PIPE_FORMAT_B5G6R5_UNORM.

Somewhere before we should be marking this visual as unsupported, but we don't.

Jose

Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.7.1 and Mesa 7.8 released!

[Dan N. <dbn...@gm...>]

On Mon, Mar 29, 2010 at 11:03 AM, Brian Paul <br...@vm...> wrote:
> Brian Paul wrote:
>> Ian Romanick wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Brian Paul wrote:
>>>> Ian Romanick wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Final versions of both Mesa 7.8 and 7.7.1 have been released.  Links on
>>>>> the Mesa website will still need to be updated, but I think Brian has to
>>>>> do that.
>>>> I'll do that soon.
>>>>
>>>>
>>>>> The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'.  I had
>>>>> originally intended to just use 7.8, but having a tag and a branch with
>>>>> the same name makes GIT angry (i.e., you get "warning: refname '7.8' is
>>>>> ambiguous.").
>>>> Yeah, that's what I'm getting now - and I can't seem to update my 7.8
>>>> branch to the latest commit:
>>>>
>>>> $ git rebase origin/7.8
>>>> warning: refname '7.8' is ambiguous.
>>>> Current branch 7.8 is up to date.
>>>>
>>>> I'm stuck at commit 59258498dc6fa51573b176d071644bd3e750b5ac now.  Help?
>>> Hmm... I did 'git tag -d 7.8' and that fixed the problem locally.  I
>>> thought pushing tags afterwards would delete the remote tag, but
>>> apparently not.  I'll try to solve that today.
>>
>> OK, "git tag -d 7.8" fixed the problem here.
>
> Grrr, the 7.8 tag comes back after a git-fetch though.

You might just have to go on annarchy and do "git --git-dir=$the_repo
tag -d 7.8". You might also be able to push an empty source to the
remote with "git push origin :refs/tags/7.8".

--
Dan

[Mesa3d-dev] [Bug 17659] driver_configs never deallocated

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

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





--- Comment #4 from Kristof Ralovich <kri...@gm...>  2010-03-29 12:57:15 PST ---
http://cgit.freedesktop.org/mesa/mesa/commit/?id=45f4e8842e3dae9d8be2a38769a57a524fdc335f


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

[Mesa3d-dev] [Bug 17659] driver_configs never deallocated

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

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





--- Comment #3 from Kristof Ralovich <kri...@gm...>  2010-03-29 12:56:10 PST ---
Also have a look at:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=ce0ad53281f236424a72ae021f293a3a5ca69217

and

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


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

[Mesa3d-dev] [Bug 17659] driver_configs never deallocated

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

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





--- Comment #2 from Kristof Ralovich <kri...@gm...>  2010-03-29 12:54:52 PST ---
(In reply to comment #1)
> (In reply to comment #0)
> > Created an attachment (id=19010)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=19010) [details] [details]
> > half-hearted demo patch which makes valgrind shutup
> > 
> > in src/glx/x11/drisw_glx.c 
> > 
> > const __DRIconfig **driver_configs;
> > 
> > psc->swrast->createNewScreen(screen,
> >     loader_extensions, &driver_configs, psc);
> > 
> > allocates space for the driver_configs which never get released afaics
> > 
> 
> You are right that they are not freed. The problem exists for actual DRI
> drivers also and for other loaders (xserver/glx ...).
> 
> So unless the configs are used by the loader after screen destruction time, I
> think that they should be freed by the common dri code under
> src/mesa/drivers/dri/common in the .DestroyScreen hook.
> 

I don't have the time to look into the code right now, but I had this patch
merged once
http://cgit.freedesktop.org/mesa/mesa/commit/?id=fa5b0364f90be19bb0e1915f1eea691d06fb8929


-- 
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] Status of s3tc patent in respect to open-source drivers and workarounds

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

Ian Romanick schrieb:
> Philipp Klaus Krause wrote:
>> Corbin Simpson schrieb:
>>> After re-reading ARB_texture_compression, it does seem like it is
>>> legal for extensions such as EXT_texture_compression_s3tc to fall
>>> back, using a basic mechanism: glGetTexLevelParameter can return
>>> GL_FALSE for GL_TEXTURE_COMPRESSED_ARB (now GL_TEXTURE_COMPRESSED) if
>>> the texture could not successfully be compressed. Issue (10) of
>>> ARB_texture_compression deals with this explicitly:
>> Yes, ARB_texture_compression allows to support decompression only. That
>> could probably be used to have decompression support for the S3TC
>> formats in Mesa. However, this does mean that
>> EXT_texture_compression_s3tc would be supported, since
>> EXT_texture_compression_s3tc does require support for encoding and the
>> wording in ARB_texture_compression does not change that.
> 
> EXT_texture_compression_s3tc is layered on top of
> ARB_texture_compression.  I don't see anything in the spec that adds
> this requirement.  In fact, I don't see *anything* in that spec that
> mentions TexImage2D.  Am I just overlooking some wording in
> EXT_texture_compression_s3tc that adds this?

Well, there is TexSubImage2D. Assuming we have a compressed texture
stored internally as some S3TC format and then the application replaces
part of it using TexSubImage2D. According to ARB_texture_compression we
may not go to uncompressed ("the allocation and chosen compressed image
format must not be a function of any other state and cannot be changed
once they are established". And while ARB_texture_compression does not
require TexSubImage2D support, EXT_texture_compression_s3tc does.

Philipp

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

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

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

Philipp Klaus Krause wrote:
> Corbin Simpson schrieb:
>> After re-reading ARB_texture_compression, it does seem like it is
>> legal for extensions such as EXT_texture_compression_s3tc to fall
>> back, using a basic mechanism: glGetTexLevelParameter can return
>> GL_FALSE for GL_TEXTURE_COMPRESSED_ARB (now GL_TEXTURE_COMPRESSED) if
>> the texture could not successfully be compressed. Issue (10) of
>> ARB_texture_compression deals with this explicitly:
> 
> Yes, ARB_texture_compression allows to support decompression only. That
> could probably be used to have decompression support for the S3TC
> formats in Mesa. However, this does mean that
> EXT_texture_compression_s3tc would be supported, since
> EXT_texture_compression_s3tc does require support for encoding and the
> wording in ARB_texture_compression does not change that.

EXT_texture_compression_s3tc is layered on top of
ARB_texture_compression.  I don't see anything in the spec that adds
this requirement.  In fact, I don't see *anything* in that spec that
mentions TexImage2D.  Am I just overlooking some wording in
EXT_texture_compression_s3tc that adds this?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuw83QACgkQX1gOwKyEAw+cuQCfbI7prb98/COjFd1hHL+tG0T8
SrYAnR5VC3BZ1XvSPvKSeQQ+7AabpXJr
=HO+K
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

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

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

SpliFF wrote:
> On 03/29/10 17:06, Ian Romanick wrote:
>> SpliFF wrote:
>>> So to clarify, you're saying a partial implementation (decoder only)
>>> isn't an option at all? If you expose an extension it must be complete?
>> See the documentation for glGetCompressedTexImage.
> 
> That does not appear to imply a run-time encoder. It seems to imply the
> data is already compressed - which could (and really should) be done
> prior to distribution (via the nvidia tools for example). The
> documentation does quite clearly state that the application should
> verify the texture really was compressed so you're only going to run
> into issues when the programmer made assumptions about the supported
> hardware. Not saying that's impossible, just that that's the
> programmers' responsibility, not the drivers.
> 
> Runtime compression is actually performed by glTexImage2D with its
> internalFormat set to a supported *_S3TC_* value, however the 2.1 spec says:
> 
> "If no corresponding internal format is available, or the GL can not
> compress that image for any reason, the internal format is instead
> replaced with a corresponding base internal format."

I hate to admit it, but I think you are correct.  Issue 10 in the
GL_ARB_texture_compression, the first two bullets in particular, seems
to support this.

(10) Should functionality be provided to allow applications to save
    compressed images to disk and reuse them in subsequent runs without
    programming to specific formats?  If so, how?

      RESOLVED:  Yes.  This can be done without knowledge of specific
      compression formats in the following manner:

        * Call TexImage with an uncompressed image and a generic
          compressed internal format.  The texture image will be
          compressed by the GL, if possible.

        * Call GetTexLevelParameteriv with a <value> of
          TEXTURE_COMPRESSED_ARB to determine if the GL was able to
          store the image in compressed form.

        * Call GetTexLevelParameteriv with a <value> of
          TEXTURE_INTERNAL_FORMAT to determine the specific compressed
          image format in which the image is stored.

        * Call GetTexLevelParameteriv with a <value> of
          TEXTURE_COMPRESSED_IMAGE_SIZE_ARB to determine the size (in
          ubytes) of the compressed image that will be returned by the
          GL.  Allocate a buffer of at least this size.

        * Call GetCompressedTexImageARB.  The GL will write the
          compressed texture image into the allocated buffer.

        * Save the returned compressed image to disk, along with the
          associated width, height, depth, border parameters and the
          returned values of TEXTURE_COMPRESSED_IMAGE_SIZE_ARB and
          TEXTURE_INTERNAL_FORMAT.

        * Load the compressed image and its parameters, and call
          CompressedTexImage_[123]DARB to use the compressed image.  The
          value of TEXTURE_INTERNAL_FORMAT should be used as
          <internalFormat> and the value of
          TEXTURE_COMPRESSED_IMAGE_SIZE_ARB should be used as
          <imageSize>.

      The saved images will be valid as long as they are used on a
      device supporting the returned <internalFormat> parameter.  If the
      saved images are used on a device that does not support the
      compressed internal format, an INVALID_ENUM error would be
      generated by the call to CompressedTexImage_[123]D because of the
      unknown format.

      Note also that to reliably determine if the GL will compress an
      image without actually compressing it, an application need only
      define a proxy texture image and query TEXTURE_COMPRESSED_ARB as
      above.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuw6/wACgkQX1gOwKyEAw9cWQCfViC2igK2W7DvhtcDj8pXVd0F
wJsAoJ0q1Pgp1sy6HVy9H9ihg/ms9oVR
=OgUh
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.7.1 and Mesa 7.8 released!

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

Brian Paul wrote:
> Ian Romanick wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Brian Paul wrote:
>>> Ian Romanick wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Final versions of both Mesa 7.8 and 7.7.1 have been released.  Links on
>>>> the Mesa website will still need to be updated, but I think Brian has to
>>>> do that.
>>> I'll do that soon.
>>>
>>>
>>>> The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'.  I had
>>>> originally intended to just use 7.8, but having a tag and a branch with
>>>> the same name makes GIT angry (i.e., you get "warning: refname '7.8' is
>>>> ambiguous.").
>>> Yeah, that's what I'm getting now - and I can't seem to update my 7.8
>>> branch to the latest commit:
>>>
>>> $ git rebase origin/7.8
>>> warning: refname '7.8' is ambiguous.
>>> Current branch 7.8 is up to date.
>>>
>>> I'm stuck at commit 59258498dc6fa51573b176d071644bd3e750b5ac now.  Help?
>> Hmm... I did 'git tag -d 7.8' and that fixed the problem locally.  I
>> thought pushing tags afterwards would delete the remote tag, but
>> apparently not.  I'll try to solve that today.
> 
> OK, "git tag -d 7.8" fixed the problem here.

Grrr, the 7.8 tag comes back after a git-fetch though.

-Brian

Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.7.1 and Mesa 7.8 released!

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

Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Brian Paul wrote:
>> Ian Romanick wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Final versions of both Mesa 7.8 and 7.7.1 have been released.  Links on
>>> the Mesa website will still need to be updated, but I think Brian has to
>>> do that.
>> I'll do that soon.
>>
>>
>>> The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'.  I had
>>> originally intended to just use 7.8, but having a tag and a branch with
>>> the same name makes GIT angry (i.e., you get "warning: refname '7.8' is
>>> ambiguous.").
>> Yeah, that's what I'm getting now - and I can't seem to update my 7.8
>> branch to the latest commit:
>>
>> $ git rebase origin/7.8
>> warning: refname '7.8' is ambiguous.
>> Current branch 7.8 is up to date.
>>
>> I'm stuck at commit 59258498dc6fa51573b176d071644bd3e750b5ac now.  Help?
> 
> Hmm... I did 'git tag -d 7.8' and that fixed the problem locally.  I
> thought pushing tags afterwards would delete the remote tag, but
> apparently not.  I'll try to solve that today.

OK, "git tag -d 7.8" fixed the problem here.

-Brian

Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.7.1 and Mesa 7.8 released!

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

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

Brian Paul wrote:
> Ian Romanick wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Final versions of both Mesa 7.8 and 7.7.1 have been released.  Links on
>> the Mesa website will still need to be updated, but I think Brian has to
>> do that.
> 
> I'll do that soon.
> 
> 
>> The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'.  I had
>> originally intended to just use 7.8, but having a tag and a branch with
>> the same name makes GIT angry (i.e., you get "warning: refname '7.8' is
>> ambiguous.").
> 
> Yeah, that's what I'm getting now - and I can't seem to update my 7.8
> branch to the latest commit:
> 
> $ git rebase origin/7.8
> warning: refname '7.8' is ambiguous.
> Current branch 7.8 is up to date.
> 
> I'm stuck at commit 59258498dc6fa51573b176d071644bd3e750b5ac now.  Help?

Hmm... I did 'git tag -d 7.8' and that fixed the problem locally.  I
thought pushing tags afterwards would delete the remote tag, but
apparently not.  I'll try to solve that today.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuw5fcACgkQX1gOwKyEAw//tQCfZozsn1QERLAymiBIEqIjVyJh
+74AniUhr37oBq8Gx/aSmsxfA1XwYVup
=5WMT
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [PATCH] glsl: optimize sqrt

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

Roland Scheidegger wrote:
> On 29.03.2010 04:50, Marek Olšák wrote:
>>  We were talking a bit on IRC that the GLSL compiler implements the sqrt
>> function somewhat inefficiently. Instead of rsq+rcp+cmp instructions as
>> is in the original code, the proposed patch uses just rsq+mul. Please
>> see the patch log for further explanation, and please review.
> 
> I'll definitely agree with the mul instead of rcp part, as that should
> be more efficient on a lot of modern hardware (rcp usually being part of
> some special function block instead of main alu).
> As far as I can tell though we still need the cmp unfortunately, since
> invsqrt(0) is infinite and multiplying by 0 will give some undefined
> result, for IEEE it should be NaN (well depending on hardware I guess,
> if you have implementation which clamps infinity to its max
> representable number it should be ok). In any case, glsl says invsqrt(0)
> is undefined, hence can't rely on this.

Yeah, I'm going to keep the x==0 test for now.  I'm replacing the rcp 
with mul, per Marek's idea.  Thanks, Marek!


> Thinking about it, we'd possibly want a SQRT opcode, both in mesa and
> tgsi. Because there's actually hardware which can do sqrt (i965
> MathBox), and just as importantly because this gives drivers a way to
> implement this as invsqrt + mul without the cmp, if they can. For
> instance AMD hardware generally has 3 rounding modes for these ops,
> "IEEE" (which gives infinity for invsqrt(0)), "DX" (clamps to
> MAX_FLOAT), and "FF" (which clamps infinity to 0, exactly what you need
> to implement sqrt with a mul and invsqrt and no cmp - though actually it
> should work with "DX" clamping as well).

I'd be happy to see a new SQRT instruction.  I'll put it on my to-do list.

-Brian

Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.7.1 and Mesa 7.8 released!

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

Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Final versions of both Mesa 7.8 and 7.7.1 have been released.  Links on
> the Mesa website will still need to be updated, but I think Brian has to
> do that.

I'll do that soon.


> The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'.  I had
> originally intended to just use 7.8, but having a tag and a branch with
> the same name makes GIT angry (i.e., you get "warning: refname '7.8' is
> ambiguous.").

Yeah, that's what I'm getting now - and I can't seem to update my 7.8 
branch to the latest commit:

$ git rebase origin/7.8
warning: refname '7.8' is ambiguous.
Current branch 7.8 is up to date.

I'm stuck at commit 59258498dc6fa51573b176d071644bd3e750b5ac now.  Help?


-Brian

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

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

Corbin Simpson schrieb:
> After re-reading ARB_texture_compression, it does seem like it is
> legal for extensions such as EXT_texture_compression_s3tc to fall
> back, using a basic mechanism: glGetTexLevelParameter can return
> GL_FALSE for GL_TEXTURE_COMPRESSED_ARB (now GL_TEXTURE_COMPRESSED) if
> the texture could not successfully be compressed. Issue (10) of
> ARB_texture_compression deals with this explicitly:

Yes, ARB_texture_compression allows to support decompression only. That
could probably be used to have decompression support for the S3TC
formats in Mesa. However, this does mean that
EXT_texture_compression_s3tc would be supported, since
EXT_texture_compression_s3tc does require support for encoding and the
wording in ARB_texture_compression does not change that.

Philipp

Re: [Mesa3d-dev] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds

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

Corbin Simpson schrieb:

> There is already a non-infringing decoder inside Mesa, wired up
> correctly, that kicks in when the HW supports it, but there's no
> extension that exposes only decoding and loading functionality.

Not fort all of S3TC, but for DXT1 there is:
EXT_texture_compression_dxt1

Philipp

Re: [Mesa3d-dev] Separate demos repository

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

On Wed, 2010-03-24 at 15:11 -0700, Eric Anholt wrote:
> People that hang out on IRC have probably heard about my build system
> work.  One of the first steps I've been working on finishing is
> splitting out the demos repository.  We're currently distributing the
> Mesa progs/ separately from the main Mesa distribution, and most people
> aren't installing it, so from a distribution perspective it doesn't make
> sense to be in the same repository.  On the other hand, for driver
> developers that are having to make clean on a regular basis, wiping out
> the programs (if you even use them) doesn't help since the programs
> aren't really changing.  And if they are, when you're bisecting around
> trying an app, you don't want the app changing at the same time.

I also think that separating the demos/tests is a sensible thing to do.
One doesn't (re)build tests as often as the rest of the drivers, and GL,
GL ES, VG, are all stable interfaces.

> So, I've made a branch in my Mesa repository for a split of the progs/
> From Mesa.
> 
> git://people.freedesktop.org/~anholt/mesa on the mesa-demos branch
>
> Open issues:
> 
> Right now they don't install in general, but it would be easy to change
> if people are interested in a package that does.  I've tested a bunch of
> them in tree and they seem fine.
> 
> I've only tested the build on Linux with GL.  The GLES stuff needs to
> get hooked up (I don't see a GLES implementation to test against or I
> would have).
> 
> I don't know what to do about the progs/gallium.  progs/gallium/unit
> looks like it should probably live in the Mesa tree next to the code
> that it's unit testing.  progs/gallium/python/ though?

Yes, all subdirs inside progs/gallium essentially have tests for gallium
interfaces, so its contents should move to src/gallium/tests .

> None of the GLEW or GLUT is brought along with the apps.  It looks to me
> like all OSes should have libGLEW and libfreeglut reasonably available.

> I'm not sure if we want the repository to contain all of previous Mesa
> history.  Right now that history costs 145MB on disk for a deep
> checkout.  If that's a problem for people, we could use the same tool
> that xcb did whose name I forget to to construct a history of just
> progs/

Probably "git filter-branch".

Jose