mesa3d-dev

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

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

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

The problem I see is that while fenced is guaranteed to make at most
one fence_signalled query for a busy buffer per allocation, cached
could potentially query the busy status of _all_ destroyed buffers for
every allocation.

The reason of this is that fenced orders the buffers in fence order
and stops at the first busy one, only handing them to the lower layer
(e.g. cached) once they are no longer busy.

If kernel calls are used instead of userspace fencing, the problem
probably gets worse.

So IMHO it should be much more efficient to use fenced over cached
(perhaps with slab between them too).

[Mesa3d-dev] r300g color bug with VBO

[Tom <to...@ri...>]

Hi people,

With the r300g driver (git ~today) drawing tris with color pointer like so:

glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(struct vtx_data), blah);

Seems to invert the RGBA -> ABGR.

This short program shows the bug. It should display a yellow tri, and
instead on r300g it shows a blue tri.

http://tom.noflag.org.uk/misc/r300g_color_bug.c

Not sure if you want user bug reports of this kind yet, but anyway...

-- 
Tom

[Mesa3d-dev] [RFC] Minor gallium changes

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

1. Rename pipe_sampler_state:min_mip_filter to mip_filter.

I don't know that the "min" part of that field refers to.


2. Remove PIPE_MAX_TEXTURE_LEVELS from p_state.h

This token isn't used anywhere in the gallium interface anymore, nor 
the state trackers.  I've already removed the use of this token in the 
gallium drivers (use per-driver #defines instead).  There's still some 
use in the blitter code though.


3. BTW, none of these #defines are used in the gallium interface 
header files:
    PIPE_MAX_CONSTANT_BUFFERS
    PIPE_MAX_ATTRIBS
    PIPE_MAX_SAMPLERS
    PIPE_MAX_VERTEX_SAMPLERS

They are used in the utility code and drivers though.  Should we 
define these in the gallium interface if they're not used by the 
interface itself?

-Brian

Re: [Mesa3d-dev] Mesa (master): intel: Remove the unused s8 spans code. Not hit during no_rast piglit.

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

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

Eric Anholt wrote:
> Module: Mesa
> Branch: master
> Commit: 7cbc4c07ee85782d5da3e2db3c4e072ca498ff07
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=7cbc4c07ee85782d5da3e2db3c4e072ca498ff07
> 
> Author: Eric Anholt <er...@an...>
> Date:   Thu Mar  4 15:33:21 2010 -0800
> 
> intel: Remove the unused s8 spans code.  Not hit during no_rast piglit.
> 
> Shaves 5.5k off of the driver.

Do any of the piglit tests actually try using stencil without depth?
It's an uncommon case, and it seems like it's the only way to hit this path.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuVf0MACgkQX1gOwKyEAw9GNQCfRsfY/iyrKOZvH5yhJX2Co1Ke
II0An3S5a79QDrxaV4JtU00TevMD/HiU
=wvU2
-----END PGP SIGNATURE-----

[Mesa3d-dev] [Bug 26965] [REGR?] slang_compile.c:665: parse_layout_qualifiers: Assertion `0 && "Bad layout qualifier"' failed.

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

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





--- Comment #6 from Brian Paul <bri...@gm...>  2010-03-08 14:34:46 PST ---
Last time I looked into this, it appeared that makedepend was missing something
when scanning the src/mesa/shader/slang/*.[ch] files.  AFAICT, it may be a bug
in makedepend.


-- 
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 26965] [REGR?] slang_compile.c:665: parse_layout_qualifiers: Assertion `0 && "Bad layout qualifier"' failed.

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

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


Rafał Miłecki <za...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #5 from Rafał Miłecki <za...@gm...>  2010-03-08 14:29:58 PST ---
(In reply to comment #4)
> Try a 'make clean' and recompile please.

Ohh, I hate this Mesa's bug so much!

What's so wrong with our Makefile :|


-- 
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 26965] [REGR?] slang_compile.c:665: parse_layout_qualifiers: Assertion `0 && "Bad layout qualifier"' failed.

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

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





--- Comment #4 from Brian Paul <bri...@gm...>  2010-03-08 14:24:42 PST ---
Try a 'make clean' and recompile please.


-- 
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 26965] [REGR?] slang_compile.c:665: parse_layout_qualifiers: Assertion `0 && "Bad layout qualifier"' failed.

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

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





--- Comment #3 from Rafał Miłecki <za...@gm...>  2010-03-08 14:22:26 PST ---
I've put printf in slang_compile.c just before assert:
[DBG] weird value is: 90

I've no idea however why c gets 90. We expect it to be 0, 1 or 2.


-- 
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 26965] [REGR?] slang_compile.c:665: parse_layout_qualifiers: Assertion `0 && "Bad layout qualifier"' failed.

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

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





--- Comment #2 from Rafał Miłecki <za...@gm...>  2010-03-08 13:50:58 PST ---
Whoops, mistake, sorry!


[Game exits immediately with:]
commit c2c4935cb8fe8601c72f585f70d776e3a65f15dc
Author: Brian Paul <br...@vm...>
Date:   Sat Feb 13 13:57:31 2010 -0700
glsl: implement layout qualifiers


[Game starts (with problems, but no creash) with:]
commit 26661ac0e10aba63de093e871e40d336696f4827
Author: Brian Paul <br...@vm...>
Date:   Sat Feb 13 13:52:37 2010 -0700
glsl: added type layout field and new type compare func


-- 
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 26965] [REGR?] slang_compile.c:665: parse_layout_qualifiers: Assertion `0 && "Bad layout qualifier"' failed.

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

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





--- Comment #1 from Rafał Miłecki <za...@gm...>  2010-03-08 13:48:51 PST ---
Created an attachment (id=33869)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33869)
output of starting Wine with one commit before mentioned


-- 
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 26965] New: [REGR?] slang_compile.c:665: parse_layout_qualifiers: Assertion `0 && "Bad layout qualifier"' failed.

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

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

           Summary: [REGR?] slang_compile.c:665: parse_layout_qualifiers:
                    Assertion `0 && "Bad layout qualifier"' failed.
           Product: Mesa
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: za...@gm...
                CC: br...@vm...


Starting with:

commit 26661ac0e10aba63de093e871e40d336696f4827
Author: Brian Paul <br...@vm...>
Date:   Sat Feb 13 13:52:37 2010 -0700

    glsl: added type layout field and new type compare func

    Note: because of a weird dependency checking bug, a 'make clean' may be
    needed before recompiling.

The Sims 3 started in Wine exits on very beginning. This is with r600 driver
and happens in Mesa git master. Going back to one commit before mentioned
workarounds problem.

Please note The Sims 3 is generally problematic using r600 (black screen on
beginning, corrupted fonts) but it at least started before this commit :)


-- 
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] code generation for dynamic extensions broken ?

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

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

George Sapountzis wrote:

> I made a small test to test code genration for dynamic extensions in
> http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-test
> 
> When using libGL + swrast_dri.so from getproc-test, the dynamic
> extensions code is not exercised and the test passes.
> 
> When using libGL from mesa 7.7 and swrast_dri.so from getproc-test,
> the extension string does contain GL_MESA_test_extension but the test
> segfaults.

There are a few places where this could break.

 - The generated dispatch stub function is wrong.
 - The dispatch offset used by the driver is wrong.
 - The dispatch remapping used by the driver is wrong.

The easiest way to check this is probably to set a breakpoint in
_mesa_init_exec_table at the line after the SET_TestExtensionMESA.  Look
at driDispatchRemapTable[TestExtensionMESA_remap_index].  Does it seem
sensible?  Look at the function stored in the dispatch table at that
offset.  Does it look sensible?

> It seems that dynamic extensions code is broken (since at least 7.7),
> unless there is something wrong with the test or my arch:
> 
> model name	: AMD Athlon(tm) XP 2200+
> flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
> pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up

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

iEYEARECAAYFAkuVYBYACgkQX1gOwKyEAw9eMwCfWcgdWnjN37FYDn6Q6nv1GXLG
Zj8AoIlciQ5+yp9RxFnKmYCdCcbYUklr
=OTOr
-----END PGP SIGNATURE-----

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

[Alex D. <ale...@gm...>]

2010/3/7 Ian Romanick <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).
>

Ok, I've gone ahead and enabled the extension in the 7.8 branch.

Alex

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

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

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

Well I guess another solution would be to just call it directly from the
place the dri_extennsion code initially was, i.e. in dri_create_context.

Roland

On 08.03.2010 17:21, Jakob Bornecrantz wrote:
> Calling dri code from src/mesa/state_tracker is not allowed since it  
> supposed to be independent of windowing systems. That said from what I  
> can see both driInitExtensions and driInitSignleExtension could be  
> folded into mesa core, I can't see anything "dri special" about them.
> 
> Cheers Jakob.
> 
> On 8 mar 2010, at 16.12, Roland Scheidegger wrote:
>> Otherwise, looks good to me, but I'd prefer if someone more familiar
>> with the extension handling code could give it a look.
>>
>> Roland
>>
>> On 08.03.2010 17:03, Marek Olšák wrote:
>>> Alright, I will add driInitExtensions(ctx, NULL, TRUE) at the end of
>>> st_init_extensions. Anything else I missed or is it OK?
>>>
>>> -Marek
>>>
>>> On Mon, Mar 8, 2010 at 4:25 PM, Roland Scheidegger  
>>> <sr...@vm...
>>> <mailto:sr...@vm...>> wrote:
>>>
>>>    On 08.03.2010 14:22, Joakim Sindholt wrote:
>>>> On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
>>>>> On 07.03.2010 20:26, Marek Olšák wrote:
>>>>>> 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
>>>    <http://cgit.freedesktop.org/%7Emareko/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.
>>>>> The second commit looks fine to me.
>>>>> The first one, I'm not sure. Maybe that's ok, but if so I'm  
>>>>> wondering
>>>>> why, since this skips all the mapping business driInitExtensions
>>>    did and
>>>>> just sets the extension enable bits to true. At least I'm fairly
>>>    sure it
>>>>> was needed in the past...
>>>>>
>>>>> Roland
>>>> I believe airlied pointed out earlier that
>>>>
>>>    http://cgit.freedesktop.org/mesa/mesa/commit/?id=17ef1f6074d6107c167f1956a5c60993904c0b72
>>>    fixed that problem.
>>>
>>>    But even with that commit, all drivers still call  
>>> driInitExtensions at
>>>    least once, though the parameter list can be NULL. I don't see  
>>> that
>>>    happening here.
>>>
>>>    Roland
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> 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
> 

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

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

Calling dri code from src/mesa/state_tracker is not allowed since it  
supposed to be independent of windowing systems. That said from what I  
can see both driInitExtensions and driInitSignleExtension could be  
folded into mesa core, I can't see anything "dri special" about them.

Cheers Jakob.

On 8 mar 2010, at 16.12, Roland Scheidegger wrote:
> Otherwise, looks good to me, but I'd prefer if someone more familiar
> with the extension handling code could give it a look.
>
> Roland
>
> On 08.03.2010 17:03, Marek Olšák wrote:
>> Alright, I will add driInitExtensions(ctx, NULL, TRUE) at the end of
>> st_init_extensions. Anything else I missed or is it OK?
>>
>> -Marek
>>
>> On Mon, Mar 8, 2010 at 4:25 PM, Roland Scheidegger  
>> <sr...@vm...
>> <mailto:sr...@vm...>> wrote:
>>
>>    On 08.03.2010 14:22, Joakim Sindholt wrote:
>>> On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
>>>> On 07.03.2010 20:26, Marek Olšák wrote:
>>>>> 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
>>    <http://cgit.freedesktop.org/%7Emareko/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.
>>>> The second commit looks fine to me.
>>>> The first one, I'm not sure. Maybe that's ok, but if so I'm  
>>>> wondering
>>>> why, since this skips all the mapping business driInitExtensions
>>    did and
>>>> just sets the extension enable bits to true. At least I'm fairly
>>    sure it
>>>> was needed in the past...
>>>>
>>>> Roland
>>>
>>> I believe airlied pointed out earlier that
>>>
>>    http://cgit.freedesktop.org/mesa/mesa/commit/?id=17ef1f6074d6107c167f1956a5c60993904c0b72
>>    fixed that problem.
>>
>>    But even with that commit, all drivers still call  
>> driInitExtensions at
>>    least once, though the parameter list can be NULL. I don't see  
>> that
>>    happening here.
>>
>>    Roland
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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

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

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

Looks OK, but have you tested with Glean's clipFlat test?  If it 
passes go ahead and commit.

-Brian

Marek Olšák wrote:
> 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... 
> <mailto:br...@vm...>> wrote:
> 
>     Corbin Simpson wrote:
>      >>From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00
>     2001
>      > From: Corbin Simpson <Mos...@gm...
>     <mailto: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...
>     <mailto:Mes...@li...>
>     https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

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

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

Otherwise, looks good to me, but I'd prefer if someone more familiar
with the extension handling code could give it a look.

Roland

On 08.03.2010 17:03, Marek Olšák wrote:
> Alright, I will add driInitExtensions(ctx, NULL, TRUE) at the end of
> st_init_extensions. Anything else I missed or is it OK?
> 
> -Marek
> 
> On Mon, Mar 8, 2010 at 4:25 PM, Roland Scheidegger <sr...@vm...
> <mailto:sr...@vm...>> wrote:
> 
>     On 08.03.2010 14:22, Joakim Sindholt wrote:
>     > On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
>     >> On 07.03.2010 20:26, Marek Olšák wrote:
>     >>>  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
>     <http://cgit.freedesktop.org/%7Emareko/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.
>     >> The second commit looks fine to me.
>     >> The first one, I'm not sure. Maybe that's ok, but if so I'm wondering
>     >> why, since this skips all the mapping business driInitExtensions
>     did and
>     >> just sets the extension enable bits to true. At least I'm fairly
>     sure it
>     >> was needed in the past...
>     >>
>     >> Roland
>     >
>     > I believe airlied pointed out earlier that
>     >
>     http://cgit.freedesktop.org/mesa/mesa/commit/?id=17ef1f6074d6107c167f1956a5c60993904c0b72
>     fixed that problem.
> 
>     But even with that commit, all drivers still call driInitExtensions at
>     least once, though the parameter list can be NULL. I don't see that
>     happening here.
> 
>     Roland
> 
> 

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

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

Keith Whitwell wrote:
> 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. 

Looks good to me too, Dave.

This reminds me that I have a branch that cleans up some of the 
fb/texture map/unmap code in Mesa.  I need to get back on that one of 
these days...

-Brian

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

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

Alright, I will add driInitExtensions(ctx, NULL, TRUE) at the end of
st_init_extensions. Anything else I missed or is it OK?

-Marek

On Mon, Mar 8, 2010 at 4:25 PM, Roland Scheidegger <sr...@vm...>wrote:

> On 08.03.2010 14:22, Joakim Sindholt wrote:
> > On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
> >> On 07.03.2010 20:26, Marek Olšák wrote:
> >>>  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<http://cgit.freedesktop.org/%7Emareko/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.
> >> The second commit looks fine to me.
> >> The first one, I'm not sure. Maybe that's ok, but if so I'm wondering
> >> why, since this skips all the mapping business driInitExtensions did and
> >> just sets the extension enable bits to true. At least I'm fairly sure it
> >> was needed in the past...
> >>
> >> Roland
> >
> > I believe airlied pointed out earlier that
> >
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=17ef1f6074d6107c167f1956a5c60993904c0b72fixed that problem.
>
> But even with that commit, all drivers still call driInitExtensions at
> least once, though the parameter list can be NULL. I don't see that
> happening here.
>
> Roland
>
>

[Mesa3d-dev] code generation for dynamic extensions broken ?

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

Hi,

I made a small test to test code genration for dynamic extensions in
http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-test

When using libGL + swrast_dri.so from getproc-test, the dynamic
extensions code is not exercised and the test passes.

When using libGL from mesa 7.7 and swrast_dri.so from getproc-test,
the extension string does contain GL_MESA_test_extension but the test
segfaults.

It seems that dynamic extensions code is broken (since at least 7.7),
unless there is something wrong with the test or my arch:

model name	: AMD Athlon(tm) XP 2200+
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up

regards,
George.

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

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

On 08.03.2010 14:22, Joakim Sindholt wrote:
> On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
>> On 07.03.2010 20:26, Marek Olšák wrote:
>>>  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.
>> The second commit looks fine to me.
>> The first one, I'm not sure. Maybe that's ok, but if so I'm wondering
>> why, since this skips all the mapping business driInitExtensions did and
>> just sets the extension enable bits to true. At least I'm fairly sure it
>> was needed in the past...
>>
>> Roland
> 
> I believe airlied pointed out earlier that
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=17ef1f6074d6107c167f1956a5c60993904c0b72 fixed that problem.

But even with that commit, all drivers still call driInitExtensions at
least once, though the parameter list can be NULL. I don't see that
happening here.

Roland

[Mesa3d-dev] gallium no texture blanket

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

I intend to merge this branch in the next few days.

This will temporarily break the XShm code in egl/x11, which is coded
around an interesting combination of user_buffer_create +
texture_blanket, but there is other work in progress to address that,
and the non-XShm version continues to work in the meantime.

Additionally, the surface_buffer_create() hook should no longer be
needed and will be removed soonish.  Some drivers still use this
internally, but it doesn't need to be part of the public interface.

Keith

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

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

On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
> On 07.03.2010 20:26, Marek Olšák wrote:
> >  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.
> 
> The second commit looks fine to me.
> The first one, I'm not sure. Maybe that's ok, but if so I'm wondering
> why, since this skips all the mapping business driInitExtensions did and
> just sets the extension enable bits to true. At least I'm fairly sure it
> was needed in the past...
> 
> Roland

I believe airlied pointed out earlier that
http://cgit.freedesktop.org/mesa/mesa/commit/?id=17ef1f6074d6107c167f1956a5c60993904c0b72 fixed that problem.

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

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

On Mon, 2010-03-08 at 04:25 -0800, Roland Scheidegger wrote:
> 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?

It might. But typed bitfields (ie. anything other than 'int' or
'unsigned int') are not standard C. gcc -pedantic will complaint IIRC.

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

Jose

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

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

On 07.03.2010 20:26, Marek Olšák wrote:
>  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.

The second commit looks fine to me.
The first one, I'm not sure. Maybe that's ok, but if so I'm wondering
why, since this skips all the mapping business driInitExtensions did and
just sets the extension enable bits to true. At least I'm fairly sure it
was needed in the past...

Roland