Re: [Dri-devel] R200 notes & issues

[Martin Spott]

In article  you wrote:
> Message-ID: <[EMAIL PROTECTED]>
> References:  
><[EMAIL PROTECTED]>
> Mime-Version: 1.0
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5.1i
> In-Reply-To: <[EMAIL PROTECTED]>; from 
>[EMAIL PROTECTED] on Fri, Dec 20, 2002 at 12:47:34PM +0100
> Sender: [EMAIL PROTECTED]
> Errors-To: [EMAIL PROTECTED]
> Precedence: bulk
> List-Help: 
> List-Post: 
> List-Subscribe: ,
>   
> List-Id: 
> List-Unsubscribe: ,
>   
> List-Archive: 
> Date: Fri, 20 Dec 2002 10:48:38 -0800
> Content-Type: text/plain; charset=us-ascii

> On Fri, Dec 20, 2002 at 12:47:34PM +0100, Martin Spott wrote:
>> >> There are sporadic rendering bugs in FlightGear, however.  Every ~40
>> >> frames or so, I'll see a large triangle or two flash on the screen.
>> 
>> > Like these ones ?
>> 
>> > http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4_3.png
>> 
>> Did you know that 'Solace' - recently mentioned on this list - also shows
>> this sort of artifacts ?

> And I can guarantee it's not a bug in Solace. ;)

>> http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-4.x.png
>> 
>> 
>> Maybe this program is not that complex and could server as a test case for
>> DRI/Mesa-4.x,

> Wow, that's a really cool failure mode...  What's your GL_draw_method (in
> ~/.Solace/registry) set to?  Try changing it to 1 or 0... also, I notice a
> problem with the outlines on the various objects which have them (the group
> of torii and the "bubble"-shaded thing on the right).  The easy workaround
> (in Solace anyway) is to change GL_line_method to 0, which switches it to
> immediate mode (it still records a displaylist though).

> BTW, for an explanation of the various settings (so that people really
> could use Solace as a driver stress test), type "d_set" from the
> controlling terminal (and you can also use this command to change the
> settings on-the-fly).

> I must take issue with your claim that Solace is 'not that complex' though.
> ;)

> -- 
> http://trikuare.cx


> ---
> This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
> Time is running out!  Thinkgeek.com has the coolest gifts for
> your favorite geek.   Let your fingers do the typing.   Visit Now.
> T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel



-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] R200 notes & issues

[Martin Spott]

>> > http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4_3.png
>> 
>> Did you know that 'Solace' - recently mentioned on this list - also shows
>> this sort of artifacts ?

> And I can guarantee it's not a bug in Solace. ;)

>> http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-4.x.png
>> 
>> 
>> Maybe this program is not that complex and could server as a test case for
>> DRI/Mesa-4.x,

> Wow, that's a really cool failure mode...  What's your GL_draw_method (in
> ~/.Solace/registry) set to?  Try changing it to 1 or 0...

Yep, this circumvences the bug,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] R200 - what can I do to help?

[Martin Spott]

>> Yes, that would be the one.  If you take all the torus together it reminds 
>> me of a cartoonish framework for what could be overall a sphere.  Imagine 
>> stretching a piece of cloth around the whole grouping ...
>> 
>> > Also, what do you mean by flickers?
>> 
>> It was like the image that was supposed to be clipped because it was 
>> hidden became visible briefly as the light went by.  It just happens 
>> briefly and then it is quickly corrected.  This is probably not an 
>> accurate description, but there it is.

> Okay... could you set the value of testRender/capt to some directory with
> lots of free space and press 'k'?  It'll record PPM-format screenshots...
> then send the appropriate frame(s) to me, preferrably as PNG or JPG. :)

Are you still interested in these ones ?

>> Oops - mistype.  Switching the GL_draw method to 0 correct all of the 
>> anomalies I was seeing in the display.  

> That makes more sense. :)  Sounds like it's a problem with displaylists and
> vertex arrays.  Does it still happen if you set the value of GL_dlistMax to
> 0?

This not only cures the artifacts I encountered, this also cures the
flickering torus and - as far as I can tell now - it cures the X server
crashes with my Radeon7500. Even with GL_draw_method set to 1,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] R200 - what can I do to help?

[Martin Spott]

>>> Oops - mistype.  Switching the GL_draw method to 0 correct all of the 
>>> anomalies I was seeing in the display.  

>> That makes more sense. :)  Sounds like it's a problem with displaylists and
>> vertex arrays.  Does it still happen if you set the value of GL_dlistMax to
>> 0?

> This not only cures the artifacts I encountered, this also cures the
> flickering torus and - as far as I can tell now - it cures the X server
> crashes with my Radeon7500. Even with GL_draw_method set to 1,

O.k., the crash doesn't get prevented but it gets delayed heavily,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)

[Jens Owen]

Michel Daenzer wrote:

CVSROOT:	/cvsroot/dri
Module name:	xc
Repository:	xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
Changes by:	mdaenzer@sc8-pr-cvs1.	03/01/07 13:21:52

Log message:
  Use shadowfb instead of mi shadow to fix 2D corruption when page flipping
  is enabled.


Wow, you found the source of the corruption?  That's worthy of a posting 
to dri-devel...

  This doesn't help mixed OpenGL and X11 rendering in the same
  window, but that supposedly doesn't work with the traditional method of
  drawing to the back buffer and then copying it over the front buffer
  either, so enable page flipping by default.


I'm a little confused here.  By traditional method are you referring to 
not using page flipping?  What doesn't work in that method?

Modified files:
  xc/xc/programs/Xserver/hw/xfree86/drivers/ati/:
radeon_dri.c radeon_driver.c 
  
  Revision  ChangesPath
  1.41  +23 -29xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c
  1.53  +9 -9  xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c

--
   /\
 Jens Owen/  \/\ _
  [EMAIL PROTECTED]  /\ \ \   Steamboat Springs, Colorado



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)

[Michel Dänzer]

On Die, 2003-01-07 at 23:00, Jens Owen wrote:
> Michel Daenzer wrote:
> > CVSROOT:/cvsroot/dri
> > Module name:xc
> > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
> > Changes by: mdaenzer@sc8-pr-cvs1.   03/01/07 13:21:52
> > 
> > Log message:
> >   Use shadowfb instead of mi shadow to fix 2D corruption when page flipping
> >   is enabled.
> 
> Wow, you found the source of the corruption?  That's worthy of a posting 
> to dri-devel...

True, I posted about it on December 14th and asked for testing, sadly I
didn't receive any reports.

> >   This doesn't help mixed OpenGL and X11 rendering in the same
> >   window, but that supposedly doesn't work with the traditional method of
> >   drawing to the back buffer and then copying it over the front buffer
> >   either, so enable page flipping by default.
> 
> I'm a little confused here.  By traditional method are you referring to 
> not using page flipping?  

Yes.

> What doesn't work in that method?

The X server always renders to the front buffer, so when you mix OpenGL
and X11 rendering, the former clobbers the latter when rendering to the
back buffer.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)

[Dieter Nützel]

Am Dienstag, 7. Januar 2003 23:35 schrieb Michel Dänzer:
> On Die, 2003-01-07 at 23:00, Jens Owen wrote:
> > Michel Daenzer wrote:
> > > CVSROOT:  /cvsroot/dri
> > > Module name:  xc
> > > Repository:   xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
> > > Changes by:   mdaenzer@sc8-pr-cvs1.   03/01/07 13:21:52
> > >
> > > Log message:
> > >   Use shadowfb instead of mi shadow to fix 2D corruption when page
> > > flipping is enabled.
> >
> > Wow, you found the source of the corruption?  That's worthy of a posting
> > to dri-devel...
>
> True, I posted about it on December 14th and asked for testing, sadly I
> didn't receive any reports.

I had if you had send both for r100 and r200;-)

Cheers,
Dieter


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)

[Dieter Nützel]

Am Mittwoch, 8. Januar 2003 00:06 schrieb Dieter Nützel:
> Am Dienstag, 7. Januar 2003 23:35 schrieb Michel Dänzer:
> > On Die, 2003-01-07 at 23:00, Jens Owen wrote:
> > > Michel Daenzer wrote:
> > > > CVSROOT:/cvsroot/dri
> > > > Module name:xc
> > > > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
> > > > Changes by: mdaenzer@sc8-pr-cvs1.   03/01/07 13:21:52
> > > >
> > > > Log message:
> > > >   Use shadowfb instead of mi shadow to fix 2D corruption when page
> > > > flipping is enabled.
> > >
> > > Wow, you found the source of the corruption?  That's worthy of a
> > > posting to dri-devel...
> >
> > True, I posted about it on December 14th and asked for testing, sadly I
> > didn't receive any reports.
>
> I had if you had send both for r100 and r200;-)

Oh, shit. Ignore me. I shot to fast.

Regards,
Dieter

PS Compiling, now.


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] R200 notes & issues

[magenta]

On Tue, Jan 07, 2003 at 03:40:09PM +0100, Martin Spott wrote:
> > And I can guarantee it's not a bug in Solace. ;)
> 
> >> http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-4.x.png
> >> 
> >> 
> >> Maybe this program is not that complex and could server as a test case for
> >> DRI/Mesa-4.x,
> 
> > Wow, that's a really cool failure mode...  What's your GL_draw_method (in
> > ~/.Solace/registry) set to?  Try changing it to 1 or 0...
> 
> Yep, this circumvences the bug,

Which one?  1 uses vertex arrays with glArrayElement, 0 uses immediate
mode. (2 uses glDrawElements.  For some reason it seems to cause problems
on lots of drivers, such as the nVidia binary-only ones, and also the ATI
binary-only ones according to someone who ran Solace on them for me).

-- 
http://trikuare.cx


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Getting current vsync rate from within libGL.so?

[Ian Romanick]

I'm just about finished with the GLX enhancements that I've been working 
on for the past couple weeks.  There's only two little problems left. 
I've got a solution for one, but the other has me stumped.

One of the extensions that I'm implementing is GLX_OML_sync_control 
(link below).  One of the functions in that extension is 
glXGetMscRateOML.  This function returns the current vsync rate.  Since 
this data is available within X, it seems that it would be better to put 
the implementation of it in libGL.so (glxcmds.c, actually) rather than 
in each driver.  My first try was to use something like:

	GLXContext gc = __glXGetCurrentContext();
	ScrnInfoPtr  sInfo;
	float  refresh;

	sInfo = xf86Screens[ gc->screen ];
	refresh = sInfo->currentMode->VRefresh;

	/* Do black magic with refresh to convert float to numer / denom
	 */

The problem with that is that xf86screens is in the address space of the 
X server, so libGL.so can't get at it.

My next try was to use the XVidMode extension (based on xvidtune.c). 
This was somewhat problematic until I realized that I had to make 
libGL.so link with libXxf86vm.a.  Is this a good idea?  The only other 
libraries that libGL is linked with are "core" libraries (libm, libX11, 
libc, etc.).  Is it okay for libGL to use an XFree86 extension?  Is 
there some better way to do this?

It works right now, but I won't commit anything until I get some sort of 
a thumbs up.  When I do commit it, I will commit it to the texmem branch 
first.

http://oss.sgi.com/projects/ogl-sample/registry/OML/glx_sync_control.txt



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] R200 - what can I do to help?

[magenta]

On Tue, Jan 07, 2003 at 03:48:51PM +0100, Martin Spott wrote:
> >> Yes, that would be the one.  If you take all the torus together it reminds 
> >> me of a cartoonish framework for what could be overall a sphere.  Imagine 
> >> stretching a piece of cloth around the whole grouping ...
> >> 
> >> > Also, what do you mean by flickers?
> >> 
> >> It was like the image that was supposed to be clipped because it was 
> >> hidden became visible briefly as the light went by.  It just happens 
> >> briefly and then it is quickly corrected.  This is probably not an 
> >> accurate description, but there it is.
> 
> > Okay... could you set the value of testRender/capt to some directory with
> > lots of free space and press 'k'?  It'll record PPM-format screenshots...
> > then send the appropriate frame(s) to me, preferrably as PNG or JPG. :)
> 
> Are you still interested in these ones ?

Yeah.

> >> Oops - mistype.  Switching the GL_draw method to 0 correct all of the 
> >> anomalies I was seeing in the display.  
> 
> > That makes more sense. :)  Sounds like it's a problem with displaylists and
> > vertex arrays.  Does it still happen if you set the value of GL_dlistMax to
> > 0?
> 
> This not only cures the artifacts I encountered, this also cures the
> flickering torus and - as far as I can tell now - it cures the X server
> crashes with my Radeon7500. Even with GL_draw_method set to 1,

Then there's a problem with glArrayElement() in the R200 driver while
recording a displaylist.

The specific piece of code that it's running is this (while a displaylist
is being recorded in GL_COMPILE_AND_EXECUTE mode):

glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, stride, &((*mesh)[0]->pos.x)); 
glEnableClientState(GL_NORMAL_ARRAY);
glNormalPointer(GL_FLOAT, stride,
&((*mesh)[0]->nrm.x)); 
int p = 0;
for (int i = 0; i < h - 1; i++)
{
glBegin(GL_TRIANGLE_STRIP);
for (int j = 0; j < w; j++)
{
glArrayElement(p);
glArrayElement(p + w);
p++;
}
glEnd();
}

(w and h are set previously, and the nasty pointer math on 'mesh' just
gives pointers to the appropriate w*h arrays of vertex data.)

-- 
http://trikuare.cx


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)

[magenta]

On Tue, Jan 07, 2003 at 03:00:10PM -0700, Jens Owen wrote:
> Michel Daenzer wrote:
> >   This doesn't help mixed OpenGL and X11 rendering in the same
> >   window, but that supposedly doesn't work with the traditional method of
> >   drawing to the back buffer and then copying it over the front buffer
> >   either, so enable page flipping by default.
> 
> I'm a little confused here.  By traditional method are you referring to 
> not using page flipping?  What doesn't work in that method?

I thought that the glX spec said that mixing X11 and OpenGL within a single
drawable wasn't guaranteed anyway, and only gave hints about things that
might or might not work on certain implementations.

-- 
http://trikuare.cx


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Was this addressed - ATI_texture_env_combine3

[Frank Jacobberger]

The following is missing from the r200 driver:

ATI_texture_env_combine3

Hence when trying to play ut2k3, all I see when playing is
colliding triangles??

When will ATI_texture_env_combine3 be added?

Thanks,

Frank



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel