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

[Dave Airlie]

On Tue, Mar 9, 2010 at 11:30 AM, Luca Barbieri  wrote:
>> 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).
>

We can do this optimisation with busy as well. As long as you add
things to the busy list at the end, and stop testing after the first
busy call. At least for a single linear GPU context, which is all
I expect this code will ever be handling.

Dave.

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Eric Anholt]

On Mon, 08 Mar 2010 14:50:45 -0800, Ian Romanick  wrote:
> -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 
> > 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.

You mean as an FBO setup?  That would be flagged as unsupported.


pgp0v7REtpL2v.pgp
Description: PGP signature
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] r300g color bug with VBO

[Marek Olšák]

Also I've fixed GL_RGBA in master so now only GL_BGRA remains unresolved...

On Tue, Mar 9, 2010 at 1:29 AM, Tom  wrote:

> 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
>
>
> --
> 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
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] r300g color bug with VBO

[Marek Olšák]

Yes, this is a known issue. The problem is that GL_RGBA and GL_BGRA map to
PIPE_FORMAT_R8G8B8A8 (RGBA) and PIPE_FORMAT_A8R8G8B8 (ARGB), respectively,
which is wrong. The attached patch fixes it for r300g but breaks other
drivers which depend on Draw (softpipe, llvmpipe). The reason is that Draw
seems to interpret A8R8G8B8 as BGRA, clearly hiding the bug.

The possibilites are:
- implement the same hack in r300g
- fix Draw (I'd prefer this one)

I hope I'll find some time this week to resolve this issue if no one else do
it.

-Marek

On Tue, Mar 9, 2010 at 1:29 AM, Tom  wrote:

> 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
>
>
> --
> 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
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 32b9a47..4b48c16 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -183,7 +183,7 @@ st_pipe_vertex_format(GLenum type, GLuint size, GLenum format,
   /* this is an odd-ball case */
   assert(type == GL_UNSIGNED_BYTE);
   assert(normalized);
-  return PIPE_FORMAT_A8R8G8B8_UNORM;
+  return PIPE_FORMAT_B8G8R8A8_UNORM;
}
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Luca Barbieri]

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

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] r300g color bug with VBO

[Tom]

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

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [RFC] Minor gallium changes

[Brian Paul]

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

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Ian Romanick]

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

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[bugzilla-daemon]

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





--- Comment #6 from Brian Paul   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.

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[bugzilla-daemon]

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


Rafał Miłecki  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Comment #5 from Rafał Miłecki   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.
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[bugzilla-daemon]

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





--- Comment #4 from Brian Paul   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.

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[bugzilla-daemon]

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





--- Comment #3 from Rafał Miłecki   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.
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[bugzilla-daemon]

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





--- Comment #2 from Rafał Miłecki   2010-03-08 13:50:58 PST 
---
Whoops, mistake, sorry!


[Game exits immediately with:]
commit c2c4935cb8fe8601c72f585f70d776e3a65f15dc
Author: Brian Paul 
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 
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.
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[bugzilla-daemon]

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





--- Comment #1 from Rafał Miłecki   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.
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[bugzilla-daemon]

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: mesa3d-dev@lists.sourceforge.net
ReportedBy: zaj...@gmail.com
CC: bri...@vmware.com


Starting with:

commit 26661ac0e10aba63de093e871e40d336696f4827
Author: Brian Paul 
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.

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Ian Romanick]

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

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Alex Deucher]

2010/3/7 Ian Romanick :
> -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-argb: 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.0). Is there a way to accept 1.0 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.00, 1.00, 1.00], 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.00 - 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® 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
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Roland Scheidegger]

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  
>>> >> > 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
>>>
>> 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® 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
>> Mesa3d-dev@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 


--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Jakob Bornecrantz]

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  
>> > > 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
>>
>
> 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® 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
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Brian Paul]

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  > wrote:
> 
> Corbin Simpson wrote:
>  >>From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00
> 2001
>  > From: Corbin Simpson  >
>  > 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
> Mesa3d-dev@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 


--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Brian Paul]

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


--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Roland Scheidegger]

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  > 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
> 
> >>>
> >>> 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® 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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Marek Olšák]

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 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
> >>>
> >>> 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
>
>
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[George Sapountzis]

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.

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Roland Scheidegger]

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


--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] gallium no texture blanket

[Keith Whitwell]

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


--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Joakim Sindholt]

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.



--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[José Fonseca]

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  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 
> > Date:   Fri Feb 26 16:45:22 2010 +
> >
> > 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


--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Roland Scheidegger]

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

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Roland Scheidegger]

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  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 
> Date:   Fri Feb 26 16:45:22 2010 +
>
> 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

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Keith Whitwell]

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


--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[The Fungi]

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...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

[Török Edwin]

[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-argb: 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.0). Is there a way to accept 1.0 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.00, 1.00, 1.00], 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.00 - 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.00, 1.00, 1.00], should be [0.00, 0.00,
0.00]
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
>From fa7b3da2f3b43486bd42a6c67b2bc1163e4c0358 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?T=C3=B6r=C3=B6k=20Edvin?= 
Date: Mon, 8 Mar 2010 11:01:22 +0200
Subject: [PATCH] Fix error reporting in glean/tpbo to report what it checks.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Previously it was always reporting that it expects 1.0 or 0.0,
instead of what it actually checked for.

Signed-off-by: Török Edvin 
---
 tests/glean/tpbo.cpp |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/glean/tpbo.cpp b/tests/glean/tpbo.cpp
index 7d86279..5f7d587 100644
--- a/tests/glean/tpbo.cpp
+++ b/tests/glean/tpbo.cpp
@@ -1030,7 +1030,7 @@ bool PBOTest::testPolygonStip(void)
 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");
+ printf("should be [%f, %f, %f]\n", exp[0],exp[1],exp[2]);
  return false;
   }
}
@@ -1041,7 +1041,7 @@ bool PBOTest::testPolygonStip(void)
 buf[(j * windowSize + i) * 3],
 buf[(j * windowSize + i) * 3 + 1],
 buf[(j * windowSize + i) * 3 + 2]);
- printf("should be [0.0, 0.0, 0.0]\n");
+ printf("should be [%f, %f, %f]\n", exp[0],exp[1],exp[2]);
  return false;
   }
 
-- 
1.7.0

--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/li