Dan Nicholson | 1 May 01:04 2008
Picon

[PATCH] autoconf: Scrape the version from configs/default

Added the make script version.mk to print the various version numbers
from configs/default. This is used to substitute the version in autoconf
rather than duplicating it in both places.
---
Dan

 Does anyone have any problems with this? If not, I'll probably commit
 it tomorrow.

 bin/version.mk    |   17 +++++++++++++++++
 configs/default   |    1 +
 configure.ac      |   14 ++++++++++----
 docs/devinfo.html |    4 ++--
 4 files changed, 30 insertions(+), 6 deletions(-)
 create mode 100755 bin/version.mk

diff --git a/bin/version.mk b/bin/version.mk
new file mode 100755
index 0000000..ab20d79
--- /dev/null
+++ b/bin/version.mk
 <at>  <at>  -0,0 +1,17  <at>  <at> 
+#!/usr/bin/make -sf
+# Print the various Mesa version fields. This is mostly used to add the
+# version to configure.
+
+# This reflects that this script is usually called from the toplevel
+TOP = .
+
+include $(TOP)/configs/default
(Continue reading)

Brian Paul | 2 May 02:10 2008

Re: Again: Resend with files in non zip-format/ Re: Suggested possible fix/ Re: progress on trimmed nurbs in display list

ruediger janecke wrote:
> Dear mesa3d-team,
> I'am resending the mail with the file in not-zip-format again -
> reason: mail was rejected again by your server, claiming for
> still being zip-files in my mail.
> Now I put attachments into a tar-file - all unzipped.
> 
> Herewith I forward the suggested fix for the example "trim.c with 
> display list".
> I also included another test example 
> "nurbs_half_sphere_trimmed_w_dlist.c.zip",
> which is a half sphere in nurbs form being trimmed, displayed by the 
> display
> list and also missing triangles along the trimcurve.
> My suggested possible fix is in "dlist.c"

Hmm, this doesn't look like a very clean fix.  Global vars are a bad 
sign.  Can you explain what exactly your patch is trying to do?

> I also noticed, "nurbs_half_sphere_trimmed_w_dlist.c" being quite slow.
> There is a lot of paging going on.
> I will try to identify the reason.

Yeah, the test is using over 600MB of memory (with NVIDIA's driver too).

Could you come up with a smaller/simpler test case?

-Brian

-------------------------------------------------------------------------
(Continue reading)

ruediger janecke | 1 May 21:41 2008
Picon

Again: Resend with files in non zip-format/ Re: Suggested possible fix/ Re: progress on trimmed nurbs in display list

Dear mesa3d-team,
I'am resending the mail with the file in not-zip-format again -
reason: mail was rejected again by your server, claiming for
still being zip-files in my mail.
Now I put attachments into a tar-file - all unzipped.

Herewith I forward the suggested fix for the example "trim.c with display list".
I also included another test example "nurbs_half_sphere_trimmed_w_dlist.c.zip",
which is a half sphere in nurbs form being trimmed, displayed by the display
list and also missing triangles along the trimcurve.
My suggested possible fix is in "dlist.c"

I also noticed, "nurbs_half_sphere_trimmed_w_dlist.c" being quite slow.
There is a lot of paging going on.
I will try to identify the reason.

I also noticed my reported problem of the outer stripes of a b-spline surface
in a displaylist not being drawn, is corrected in "slicer.cc" with mesa 7.03.
Thank you.

If there are any questions or comments, pls. let me know.

With kind regards,
Ruediger Janecke

Attachments:
- trim_w_display_list.c.zip   ("trim.c" of redbook, but w. display list)
- nurbs_half_sphere_trimmed_w_dlist.c.zip
                     (another example of a trimmed nurbs in display list)
- four screenshots showing the two examples above in error and OK when my
(Continue reading)

Matthias Hopf | 2 May 11:08 2008
Picon

[PATCH] Add missing chip id for RS690.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
George - | 2 May 18:51 2008
Picon

drixorg: software renderer with dri_interface.h

Hi,

Following krh's advice, I wrote a minimal software renderer that implements the __DRIcoreExtension interface and can be loaded by xorg in place of libGLcore.so . The patches are available at:

http://people.freedesktop.org/~gsap7/drixorg/

I tested it with Xephyr and seems pretty stable with most common 32-bit rgba double-buffered visuals.

wrt implementation details, drixorg uses "external" __DRIcoreExtension (from dri_interface.h) but does not use the "internal" __DRI types (from dri_utils.h). The reason being that very few fields and surrounding functionality is needed so I choose to minimally redefine them.

I also added __DRIcoreExtension with two methods: getPixmapInfo() for getting a pixmap's size (though not sure if it's actually needed) and putImage() for blitting to the front pixmap during swapbuffers.

We also need some extension for converting __GLXconfigs to _DRIconfigs because for GLcore, the loader is the one the defines the set of supported FBconfigs. The current implementation works only because of a gross hack (all configs, visuals, ... are currently __GLcontextModes ...)

drixorg at least needs support for front-buffer rendering and some debugging for depths other than 32.

I'll probably won't have much time during the next period, so if someone wants to pick up and put it in merge-able state, they are welcome.

regards,
George.

Explore the seven wonders of the world Learn more!
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
ruediger janecke | 2 May 17:54 2008
Picon

Answer on possible fix for trimmed nurbs in display list

Dear Brian, dear mesa3d-team,

concerning the global variable "triangle_status" it can/ should be
made local into module "execute_list".

What am I trying to do:
I'm trying to interprete the opcode sequences
| EXT_0 | EVAL_C2 | EVAL_C2 | ... | EVAL_C2 | END |,
which are currently not interpreted - hence the missing triangles
along the trimcurves as my accompanying pics show.

As soon as an EXT_0-opcode is encoutered, I prepare to gather for
following EVAL_C2-opcodes (which each contains one pair of u and v):
"triangle_status" is set to 1.
As soon as three EVAL_C2-opcodes have been arrived
("triangle_status" is then 4 (four)), a triangle through
Begin, EvalCoord2f, EvalCoord2f, EvalCoord2f, End is generated.

Some of those above mentioned opcodes sequences are not just a
triple of EVAL_C2's, but rather contain more than three EVAL_C2's:
they represent a triangle fan.
Hence, there is code to generate triangles at "case OPCODE_END:"
and at "case OPCODE_EVAL_C2:".
Derive triangles from a triangle fan sequence, the first point
(the "pivot" of the fan) has to be used for all triangles being
made from that fan.

The setting of "ctx->Driver.CurrentExecPrimitive = GL_POLYGON+1;"
was necessary to "allow" the
"Begin, EvalCoord2f, EvalCoord2f, EvalCoord2f, End" sequence.
Also, I was not able to generate triangle fans (was "rejected").
Now, looking at my code again, the
"ctx->Driver.CurrentExecPrimitive = PRIM_OUTSIDE_BEGIN_END;"
may be superfluous. I will try it.

Some provisions have been made to:
- "Recover" from a situation where a (yet) unknown opcode or opcode
    sequence may appear - especially within the opcode sequence I'm
    trying to interprete.
    It may be very well, that with working more with display lists,
    other kind of opcode sequences not yet interpreted may be
    encountered.
- Still execute the "regular" END-opcodes and EVAL_C2-opcodes,
    when there is no such opcode sequence representing triangles.

My possible suggested fix may not be the final solution and one may
encounter further demands with the display list, but it is - especially
to me - a further step using the OpenGL lib with trimmed b-splines in
the display list and gain more experience.

Regarding the test case using so much memory and being display quite
slow, I will try to make it simpler/ smaller.
On the other hand, the surface (half sphere) is just five times five
controlpoints and the trimcurve "across" the sphere has that many
points (pwl-curve), to do the trimming accurate enough.
OK, if it is that curve, that makes the example looking that large,
I will decrement the curve to a line, that will then trim the half
sphere to a quarter sphere.
You will receive the reduced example within the next days.
Also, I suspect the reason of the slow execution being the surface a
form of a sphere, I will try to make it rather flat and see what
happens.
Also, it may be worth to reduce the geometric size and/ or the
parameterization of the surface.

If there are any further questions or comments, pls. let me know.
- Ruediger

Brian Paul wrote 2008-05-02 02:10 AM:
> ruediger janecke wrote 05/01/2008 09:41 PM:
> 
>> Dear mesa3d-team,
>> I'am resending the mail with the file in not-zip-format again -
>> reason: mail was rejected again by your server, claiming for
>> still being zip-files in my mail.
>> Now I put attachments into a tar-file - all unzipped.
>>
>> Herewith I forward the suggested fix for the example "trim.c with 
>> display list".
>> I also included another test example 
>> "nurbs_half_sphere_trimmed_w_dlist.c.zip",
>> which is a half sphere in nurbs form being trimmed, displayed by the 
>> display
>> list and also missing triangles along the trimcurve.
>> My suggested possible fix is in "dlist.c"
> 
> 
> Hmm, this doesn't look like a very clean fix.  Global vars are a bad 
> sign.  Can you explain what exactly your patch is trying to do?
> 
> 
>> I also noticed, "nurbs_half_sphere_trimmed_w_dlist.c" being quite slow.
>> There is a lot of paging going on.
>> I will try to identify the reason.
> 
> 
> Yeah, the test is using over 600MB of memory (with NVIDIA's driver too).
> 
> Could you come up with a smaller/simpler test case?
> 
> -Brian
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
ruediger janecke | 3 May 16:15 2008
Picon

Slow trimmed NURBS surface - problem identified

Dear Brian, dear mesa3d-team,

as promised, I did some more testing with the example
of a trimmed NURBS surface (half sphere - rational b-spline),
that was executed/ displayed very slow - a lot of paging was
going on.

The reason seems to be:
   the parameterization of u and v of the surface (to be trimmed)
   has to be in a "close" number range.

In my example
the parameterization of u is in the range from  0.0 to 400.
while in v, it is in the range fromm 0.0 to 3.14  .

I changed the parameterization and my example was executed/
displayed as fast as "trim.c" from the "red book".

I think, this a good news to get an idea about a fix in
mesa3d, but also to be able to adapt the application to that
matter in the meantime.

I will come up with the examples showing the difference next
week.

Have a good weekend,
- Ruediger

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
bugzilla-daemon | 3 May 19:45 2008

[Bug 15809] [AIGLX] crash on window resize

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

Michel Dänzer <michel <at> tungstengraphics.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|dri-                        |mesa3d-
                   |devel <at> lists.sourceforge.net |dev <at> lists.sourceforge.net
          Component|Drivers/DRI/r200            |Mesa core

--- Comment #3 from Michel Dänzer <michel <at> tungstengraphics.com>  2008-05-03 10:45:55 PST ---
Doesn't look driver specific.

Does this also happen with current versions of compiz(-fusion)? The crash
should be fixed anyway, but I've never seen this with compiz...

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
bugzilla-daemon | 4 May 02:43 2008

[Bug 15809] [AIGLX] crash on window resize

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

--- Comment #4 from Andrew Randrianasulu <randrik <at> mail.ru>  2008-05-03 17:43:21 PST ---
compiz (0.7.4) works without crash. But beryl used something different while
resizing windows, like blurring everything in real time. Compiz simply resized
window, without this 'blur-everything-behind' effect.

--

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

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
bugzilla-daemon | 4 May 05:02 2008

[Bug 9539] Must-be-hidden surfaces are shown

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

Michael Fu <michael.fu <at> intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |NEEDINFO

--- Comment #8 from Michael Fu <michael.fu <at> intel.com>  2008-05-03 20:02:21 PST ---
(In reply to comment #5)
> Created an attachment (id=8510)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=8510) [details]
> Snapshots/notes
> 
> I found _two_ ways to reproduce the bug. Here goes the first:
> 
> 1. Execute an OpenGL XScreenSaver with an invalid visual. Examples:
> cube21 -visual 0 -cubesize 2
> gears -visual 0 -planetary
> 
> Please see the attachment for further comment.
> 
> OS: Gentoo Linux 2006.1, Updated to Jan 26, 2007
> Graphic Unit: Intel 945GM
> OpenGL renderer string: Mesa DRI Intel(R) 945GM 20061017 x86/MMX/SSE2
> 

Fabio, are you still able to reproduce this on a newer environment? e.g. newer
Gentoo build, latest stable Ubuntu or lastest stable Fedora.

--

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

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Gmane