Re: [Dri-devel] Memory leak affecting Xv (NOT A BUG)
On Sat, 2004-01-17 at 20:56, Alex Deucher wrote: > I'm not sure if this is a leak per se... the problem is the 2D and 3D > driver aren't too good at managing memory. the 3D driver may snag a > big chunk for a full screen 3D app and then "keep" it. It's then no > longer available for the 2D driver resulting in a bad alloc error. I > think Alan H. was working on a new memory management system for > radeon/r200 for post 4.4. It seems you were correct that this was not a leak. After tracing through the various functions that might allocate and free video memory, I realized that RADEONTransitionTo2d was not being called after the GL hacks were closed. It seems that xscreensaver hangs on to something that prevents this. After I killed xscreensaver, RADEONTransitionTo2d was called and Xv started working. --Jonathan Thambidurai --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage IX framebuffer weirdness
On Sun, 2004-01-18 at 11:00, Felix Kühling wrote: > Hi, > > I got software fallbacks to work with Savage IX ;-), more or less. It's > scribbling all over the screen, and what it draws depends on the > background. Furthermore, the way it scribbles stuff over the screen > depends on whether I have DisableTile set to true of false. Looks like > frame buffer access is not linear in either case and other stuff is > probably not setup correctly. Alex, could you take a look, please. I'm > lost here. > > I'm attaching a patch with my 3D driver changes for SavageIX. It'll most > likely break other savages and it draws everything as software fallbacks. > Try running glxgears on a desktop with the standard X background (black > and white mesh). It draws some stuff over the white pixels, but the > black pixels stay black. With DisableTile set to false you can almost > recognize the gears. This is great work, just to confirm, I applied the patch & X is now running without slowing to a crawl when glxgears/glxinfo is run. When running glxgears, an interesting 'colouring-in' effect of the gears results when doing a click 'n drag on any window & moving the window vigorously about. Everything else worked as you described though I'm not sure why it's only showing 640x480 for you & Alex. All resolutions work fine up to 1024x768 on the laptop (MobileSavage IX/MV). Still trying to check-out utah-glx cvs & compare, server seems down at the minute. Thanks, Rick --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory leak affecting Xv?
I'm not sure if this is a leak per se... the problem is the 2D and 3D driver aren't too good at managing memory. the 3D driver may snag a big chunk for a full screen 3D app and then "keep" it. It's then no longer available for the 2D driver resulting in a bad alloc error. I think Alan H. was working on a new memory management system for radeon/r200 for post 4.4. Alex --- Jonathan Thambidurai <[EMAIL PROTECTED]> wrote: > On Sat, 2004-01-17 at 20:16, Jonathan Thambidurai wrote: > > On Sat, 2004-01-17 at 19:07, Jonathan Thambidurai wrote: > > > With DRI CVS, using DRI on my 16 MB M7, if I run the xscreensaver > hack > > > that turns my desktop into a texture and makes it wavy (GLFlux) > > > fullscreen and then close it, I subsequently cannot properly run > any app > > > that uses Xv; mplayer bugs out, xine gives a black picture, and > tvtime > > > gives a BadAlloc error. This is at a 1280x1024x24 resolution. > Note > > > that Xv continues to work after I open and close Blender or > glxgears > > > (both fullscreen) or run GLFlux in a window. This problem also > does not > > > exist with a 16 bit depth. > > > > > > > I did some more testing with this and found that running any of the > GL > > hacks fullscreen screws up Xv. When I said I ran Blender and > glxgears > > fullscreen, I meant they were maximized (Blender without borders, > as it > > does automatically). > > I did some more checking on this and found that the allocation on > line > 1188 of radeon_video.c is what is failing. > > --Jonathan Thambidurai > > ps My apologies to the moderator for the messages from my other > account. > > > > --- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Savage IX framebuffer weirdness
--- Felix Kühling <[EMAIL PROTECTED]> wrote: > Hi, > > I got software fallbacks to work with Savage IX ;-), more or less. > It's > scribbling all over the screen, and what it draws depends on the > background. Furthermore, the way it scribbles stuff over the screen > depends on whether I have DisableTile set to true of false. Looks > like > frame buffer access is not linear in either case and other stuff is > probably not setup correctly. Alex, could you take a look, please. > I'm > lost here. > Nice work Felix! I'll look into it either tomorrow or Monday, depending on how busy I am. Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory leak affecting Xv?
On Sat, 2004-01-17 at 20:16, Jonathan Thambidurai wrote: > On Sat, 2004-01-17 at 19:07, Jonathan Thambidurai wrote: > > With DRI CVS, using DRI on my 16 MB M7, if I run the xscreensaver hack > > that turns my desktop into a texture and makes it wavy (GLFlux) > > fullscreen and then close it, I subsequently cannot properly run any app > > that uses Xv; mplayer bugs out, xine gives a black picture, and tvtime > > gives a BadAlloc error. This is at a 1280x1024x24 resolution. Note > > that Xv continues to work after I open and close Blender or glxgears > > (both fullscreen) or run GLFlux in a window. This problem also does not > > exist with a 16 bit depth. > > > > I did some more testing with this and found that running any of the GL > hacks fullscreen screws up Xv. When I said I ran Blender and glxgears > fullscreen, I meant they were maximized (Blender without borders, as it > does automatically). I did some more checking on this and found that the allocation on line 1188 of radeon_video.c is what is failing. --Jonathan Thambidurai ps My apologies to the moderator for the messages from my other account. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory leak affecting Xv?
On Sat, 2004-01-17 at 19:07, Jonathan Thambidurai wrote: > With DRI CVS, using DRI on my 16 MB M7, if I run the xscreensaver hack > that turns my desktop into a texture and makes it wavy (GLFlux) > fullscreen and then close it, I subsequently cannot properly run any app > that uses Xv; mplayer bugs out, xine gives a black picture, and tvtime > gives a BadAlloc error. This is at a 1280x1024x24 resolution. Note > that Xv continues to work after I open and close Blender or glxgears > (both fullscreen) or run GLFlux in a window. This problem also does not > exist with a 16 bit depth. > I did some more testing with this and found that running any of the GL hacks fullscreen screws up Xv. When I said I ran Blender and glxgears fullscreen, I meant they were maximized (Blender without borders, as it does automatically). --Jonathan Thambidurai --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Memory leak affecting Xv?
With DRI CVS, using DRI on my 16 MB M7, if I run the xscreensaver hack that turns my desktop into a texture and makes it wavy (GLFlux) fullscreen and then close it, I subsequently cannot properly run any app that uses Xv; mplayer bugs out, xine gives a black picture, and tvtime gives a BadAlloc error. This is at a 1280x1024x24 resolution. Note that Xv continues to work after I open and close Blender or glxgears (both fullscreen) or run GLFlux in a window. This problem also does not exist with a 16 bit depth. --Jonathan Thambidurai --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Savage IX framebuffer weirdness
Hi,
I got software fallbacks to work with Savage IX ;-), more or less. It's
scribbling all over the screen, and what it draws depends on the
background. Furthermore, the way it scribbles stuff over the screen
depends on whether I have DisableTile set to true of false. Looks like
frame buffer access is not linear in either case and other stuff is
probably not setup correctly. Alex, could you take a look, please. I'm
lost here.
I'm attaching a patch with my 3D driver changes for SavageIX. It'll most
likely break other savages and it draws everything as software fallbacks.
Try running glxgears on a desktop with the standard X background (black
and white mesh). It draws some stuff over the white pixels, but the
black pixels stay black. With DisableTile set to false you can almost
recognize the gears.
Regards,
Felix
P.S.: drawing everything as software fallbacks doesn't always work on my
ProSavage. With glxgears and some xscreensaver hacks I tried the window
stays black. In flightgear some polys are missing (the runway) and the
propeller disk is drawn inside the cockpit in some frames (zbuffer
problem?). With ng-glx the output is ok, though. I havn't found out
what's wrong yet.
--- ./savagespan.c.~1.1.4.4.~ 2003-12-28 17:42:33.0 +0100
+++ ./savagespan.c 2004-01-17 22:51:54.0 +0100
@@ -45,7 +45,8 @@
dPriv->x * cpp + \
dPriv->y * pitch); \
GLuint p = SAVAGE_CONTEXT( ctx )->MonoColor; \
- (void) read_buf; (void) buf; (void) p
+ /*GLuint dummy = *(int *)(NULL);*/ \
+ (void) read_buf; (void) buf; (void) p/*; (void)dummy*/
#define LOCAL_DEPTH_VARS \
__DRIdrawablePrivate *dPriv = imesa->mesa_drawable; \
--- ./savage_bci.h.~1.1.4.2.~ 2003-12-29 02:02:07.0 +0100
+++ ./savage_bci.h 2004-01-17 18:45:04.0 +0100
@@ -670,8 +670,8 @@
/*frank 2001/11/20 */
#define MAXLOOP 0xFF
-/*#define MAXFIFO 0x7F00*/
-#define MAXFIFO 0x1FF00
+#define MAXFIFO 0x7F00
+/*#define MAXFIFO 0x1FF00*/
/* get eventtag from shadow status */
/* here we use eventTag1 because eventTag0 is used by HWXvMC*/
@@ -704,15 +704,16 @@
}while(0);
#define ALT_STATUS_WORD0 (* (volatile GLuint *)(imesa->MMIO_BASE+0x48c60))
+#define STATUS_WORD0 (* (volatile GLuint *)(imesa->MMIO_BASE+0x48c00))
#define PAGE_PENDING(result) do{\
-result=((ALT_STATUS_WORD0 & 0x0800)?GL_TRUE:GL_FALSE);\
+result=((STATUS_WORD0 & 0x0800)?GL_TRUE:GL_FALSE);\
}while(0)
#define WAIT_FOR_FIFO(count) do{\
int loop = 0; \
int slots = MAXFIFO-count; \
-while(((ALT_STATUS_WORD0 &0x001f)>slots)&&(loop++slots)&&(loop++shadowStatus)\
while*imesa->shadowPointer) & 0x0E00L)!=0x0E00L)&&(loop++driReadable = driReadPriv;
imesa->driDrawable = driDrawPriv;
+ imesa->mesa_drawable = driDrawPriv;
imesa->dirty = ~0;
_mesa_make_current2(imesa->glCtx,
--- ./savagedma.h.~1.1.4.2.~2003-12-29 02:28:37.0 +0100
+++ ./savagedma.h 2004-01-17 17:00:09.0 +0100
@@ -27,7 +27,7 @@
#define SAVAGEDMA
/* Whether use DMA to transfer the 3d commands and data */
-#define SAVAGE_CMD_DMA 1
+#define SAVAGE_CMD_DMA 0
#define DMA_BUFFER_SIZE (4*1024*1024) /*4M*/
#define MAX_DMA_BUFFER_SIZE (16*1024*1024)
--- ./savageioctl.c.~1.1.4.5.~ 2004-01-11 12:08:16.0 +0100
+++ ./savageioctl.c 2004-01-18 00:18:44.0 +0100
@@ -200,7 +200,6 @@
else
{ /* Use bitblt copy from back to front buffer*/
-
for (i = 0 ; i < nbox; i++, pbox++)
{
unsigned int w = pbox->x2 - pbox->x1;
@@ -366,7 +365,6 @@
}
}
UNLOCK_HARDWARE( imesa );
-
}
--- ./savagecontext.h.~1.1.4.3.~2004-01-16 00:09:41.0 +0100
+++ ./savagecontext.h 2004-01-17 23:14:10.0 +0100
@@ -57,6 +57,7 @@
#define SAVAGE_FALLBACK_STENCIL0x80
#define SAVAGE_FALLBACK_RENDERMODE 0x100
+#define SAVAGE_FALLBACK_DISABLE0x200
#define HW_STENCIL 1
--- ./savagetris.c.~1.1.4.3.~ 2004-01-16 00:09:42.0 +0100
+++ ./savagetris.c 2004-01-18 00:32:26.0 +0100
@@ -205,7 +205,7 @@
imesa->DrawPrimitiveCmd &=
~(SAVAGE_HW_TRIANGLE_TYPE | SAVAGE_HW_TRIANGLE_CONT);
WRITE_CMD(vb, SAVAGE_DRAW_PRIMITIVE(6, imesa->DrawPrimitiveCmd, 0),GLuint);
-
+
vb = savage_send_one_vertex(imesa, v0, vb, 0, vertsize);
vb = savage_send_one_vertex(imesa, v1, vb, 0, vertsize);
vb = savage_send_one_vertex(imesa, v3, vb, 0, vertsize);
@@ -652,6 +652,8 @@
{
savageContextPtr imesa = SAVAGE_CONTEXT(ctx);
+ FALLBACK (ctx, SAVAGE_FALLBACK_DISABLE, GL_TRUE);
+
if (imesa->new_state)
savageDDUpdateHwState( ctx );
@@ -666,6 +668,8 @@
}
_tnl_run_pipeline( ctx );
+
+ FALLBACK (ctx, SAVAGE_FALLBACK_DISABLE, GL_FALSE);
}
/**/
Re: [Dri-devel] tv-out of radeon mobility as another display?
On Sat, Jan 17, 2004 at 10:08:54AM -0800, Alex Deucher wrote: > In theory this is possible, all you really need to do is direct one of > the crtcs to output to the tv-out port rather than one of the monitor > ports. unfortuantely I don't know anything about tv out on radeon. if > the gatos drivers support clone mdoe, 3D should work on the cloned > head. you might have more luck inquiring on the gatos list. > OK. I'll check gatos list. I'm interested in using my vj-application with my laptop.. which means, that I can see the control-gui and the preview-window on the laptop itself (:0.0), and the "master-output" (only the opengl rendered video) on the another output (tv-out, :0.1). - Pasi Kärkkäinen > Alex > > --- Pasi K?rkk?inen <[EMAIL PROTECTED]> wrote: > > Hello! > > > > Is it possible with the current (DRI) drivers to use tv-out as > > another > > display? Built-in LCD/VGA being the first display (:0.0), and tv-out > > as the > > second display (:0.1) ? > > > > How about (3d) acceleration on the tv-out? Does mergedfb help with > > this? > > > > gatos project seems to have some tv-out drivers available too.. > > but they support only "clone"-mode. > > > > If I remember correctly, this is supported under windows. > > > > Thanks. > > > > -- Pasi K?rkk?inen > > > >^ > > . . > > Linux > > /-\ > > Choice.of.the > >.Next.Generation. > > > > > > --- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > -- > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > __ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus > > > --- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel -- ^ . . Linux /-\ Choice.of.the .Next.Generation. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: First experience with Savage4
On Fri, 16 Jan 2004, Alex Deucher wrote: > --- Felix K?hling <[EMAIL PROTECTED]> wrote: > > over the screen for a few seconds. So it may be a hardware problem, > > maybe overheating. Maybe using a lower AGP mode could help too. Though > > the AGP mode setting code is commented out in savage_driver.c, IIRC. > > > Same here. I suspect heat. the little heat sink gets REAL hot. You might want to consider putting a slot fan into the box before something burns. Google for "Titan TTC-003" for one example model of those fans. --j --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tv-out of radeon mobility as another display?
In theory this is possible, all you really need to do is direct one of the crtcs to output to the tv-out port rather than one of the monitor ports. unfortuantely I don't know anything about tv out on radeon. if the gatos drivers support clone mdoe, 3D should work on the cloned head. you might have more luck inquiring on the gatos list. Alex --- Pasi Kärkkäinen <[EMAIL PROTECTED]> wrote: > Hello! > > Is it possible with the current (DRI) drivers to use tv-out as > another > display? Built-in LCD/VGA being the first display (:0.0), and tv-out > as the > second display (:0.1) ? > > How about (3d) acceleration on the tv-out? Does mergedfb help with > this? > > gatos project seems to have some tv-out drivers available too.. > but they support only "clone"-mode. > > If I remember correctly, this is supported under windows. > > Thanks. > > -- Pasi Kärkkäinen > >^ > . . > Linux > /-\ > Choice.of.the >.Next.Generation. > > > --- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] suspending the mach64 driver
On Sat, Jan 17, 2004 at 04:55:15PM +0100, Michel D?nzer wrote:
> On Sat, 2004-01-17 at 04:48, Micha Feigin wrote:
> >
> > There does seem to be a point to completely shutdown dri when leaving X
> > and restarting on entry which would seem at list
>
> BTW, I think you mean 'at least' instead of 'at list'? Took me a while
> to understand what you mean. :)
>
Yes, sorry I keep making that mistake. The problems of english as a
second language, and the speller doesn't catch that one ;-)
> > on the surface to support to accelerated X servers running on the same
> > machine possibly at different color depths (I had problems with a second
> > one especially with a different color depth),
>
> http://penguinppc.org/~daenzer/DRI/radeon-reinit.diff works fine with
> several servers at the same depth, but there are also problems with
> different depths.
>
The reason I mentioned shutting DRI down completely is that it looks
like its allocating a memory window on startup and releases it only on
shutdown.
Thus if you have two servers running they would be sharing the video
memory instead of letting the active server control all the memory,
which can both degrade performance and cause trouble when you have two
or three high resolution true color servers running in parallel.
It may also solve the problem of running two servers with different
depths in parallel.
I forgot to remove the allocation code at first when playing around
with the changes which caused an out of memory error after the second
VT switch, which seems to point in the possibility of the memory
problem way.
I will try to do a complete DRI shutdown/restart on VT switch later and
see if it enables two servers of different depths to run in parallel
(would be nice since the mach64 is so mediocre that I get proper 3D
acceleration only with 16bpp but images don't look that good at that
depth so that way I can ran one server for games and another for movies
and the rest).
>
> > + int ret;
> > + /* int major, minor, patch;
> > +
> > + DRIQueryVersion( &major, &minor, &patch );
> > +
> > + if (minor >= 9) { */
> > + xf86DrvMsg( pScreen->myNum, X_INFO,
> > +"[RESUME] Attempting to re-init Mach64 hardware.\n");
> > + /* } else {
> > + xf86DrvMsg(pScreen->myNum, X_WARNING,
> > +"[RESUME] Cannot re-init Mach64 hardware, DRM too old\n"
> > +"(need 1.9.0 or newer)\n");
> > + return;
> > + } */
>
> You can remove the commented out code. The radeon driver checks for the
> DRM minor version to make sure the resume ioctl is available. You don't
> seem to need a new ioctl at all, checking for the DRI version doesn't
> make sense here.
Missed that one when cleaning up, thanks. I tried the ioctl, but that
only made things stop working on VT switch, seems like the mach64 doesn't
have whatever the radeon needs to reset.
>
>
> --
> Earthling Michel D??nzer | Debian (powerpc), X and DRI developer
> Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
>
>
>
> ---
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> --
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Savage IX 3D is going to take time
Quick update... On Sat, 17 Jan 2004 17:23:40 +0100 Felix Kühling <[EMAIL PROTECTED]> wrote: > hard when I start glxgears. :( It's pretty hard to find out what causes > the lockup at this point. Tim Roberts mentioned a bug in Savage4 and > ProSavages that causes lockups when reading the Fifo Status regs, but he > didn't mention Savage IX in this context. Also, I tested BCI-only > operation successfully on my ProSavage (not too thoroughly, though). I tracked this one down. It was related to buffer swaps somehow. Now it doesn't lock up any more but the 3D window remains black. glxgears shows about 290 fps. I tried to use fallbacks for all primitives in order to find out if it's a problem with the swap or with the 3D engine. But I get a segfault. Probably the same as I got in torcs yesterday on the Savage4. I'm going to track down that segfault first. Felix --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa demos/tests failures on rv250
On Fri, 2004-01-16 at 18:01, Roland Scheidegger wrote: > Roland Scheidegger wrote: > > Ian Romanick wrote: > > > >> http://marc.theaimsgroup.com/?l=dri-devel&m=105862837814769&w=2 > > Seems to be quite complicated. Though wouldn't it be a better idea to > figure out why it doesn't work in the first place? R200/RV250 should > support this, but apparently for some reason it doesn't work. The RE_POINTSIZE register seems to only affect point sprites, and even the reference driver in the R200 DDK limits the size of 'normal' points to 1, so something like the above patch will probably be needed for SW TCL anyway. > According to r200_reg.h, the chip should also be able to handle > ARB_point_sprite in hardware. Yes. Would it make sense to render points as point sprites with HW TCL? -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: First experience with Savage4
At 07:48 PM 16/1/2004, Alex Deucher wrote: > In all apps I tried so far textures look messed up like you described > before (fonts, lightmaps, normal textures, everything AFAICT). I > tried > quakeforge, q3demo, tuxracer and fgfs. In addition to that I saw the > same corruption of small mipmap levels in quakeforge that I noticed > on > the ProSavageDDR in my notebook before. I got no problem with glxgears here, the only problem I can see is that the gears seems to stop from time to time for a very sort time, but i think that happen when it is calculating the FPS but not sure. I tested Chromium here and i got a lockup on the main menu after 3 to 5 seconds but if i start the game before the lockup, the game runs really smooth but with texture problems too (http://max.brz.net/chromium.png). The main menus seems messed up to except for the image on the upper side. You guys are doing a great job and i would like to help to. What do you think is the problem here? should it be a problem when uploading the textures? bye. Rafael Máximo --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Savage IX 3D is going to take time
Ok, I plugged this Savage IX into my box now. The best way to work with it for now seems to be to explicitly set a virtual desktop size. It will only show 640x480. The CrtOnly option is not really helpful ATM. I did some first tests with 3D. First it used to hang in WAIT_FOR_FIFO and later in getDMAPage. This seems to be due to different status register layouts of the SavageIX. Also the driver used an alternative status register that doesn't seem to exist on older savages. I think I got WAIT_FOR_FIFO to work with some info from the UtahGLX driver. And I switched to pure BCI without DMA, as a shortcut. Now the system locks up hard when I start glxgears. :( It's pretty hard to find out what causes the lockup at this point. Tim Roberts mentioned a bug in Savage4 and ProSavages that causes lockups when reading the Fifo Status regs, but he didn't mention Savage IX in this context. Also, I tested BCI-only operation successfully on my ProSavage (not too thoroughly, though). The only idea I have right now is to try to write a small standalone programme using some 3D driver fragments that programs the savage IX directly. That should allow me to find out step-by-step what works and what doesn't. I expect this to take a few weeks until I have enough info to adapt the 3D driver to work with savageIX without locking up all the time. If anyone has alternative ideas how to tackle this, I'm open to suggestions. Regards, Felix --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] suspending the mach64 driver
On Sat, 2004-01-17 at 04:48, Micha Feigin wrote:
>
> There does seem to be a point to completely shutdown dri when leaving X
> and restarting on entry which would seem at list
BTW, I think you mean 'at least' instead of 'at list'? Took me a while
to understand what you mean. :)
> on the surface to support to accelerated X servers running on the same
> machine possibly at different color depths (I had problems with a second
> one especially with a different color depth),
http://penguinppc.org/~daenzer/DRI/radeon-reinit.diff works fine with
several servers at the same depth, but there are also problems with
different depths.
> + int ret;
> + /* int major, minor, patch;
> +
> + DRIQueryVersion( &major, &minor, &patch );
> +
> + if (minor >= 9) { */
> + xf86DrvMsg( pScreen->myNum, X_INFO,
> + "[RESUME] Attempting to re-init Mach64 hardware.\n");
> + /* } else {
> + xf86DrvMsg(pScreen->myNum, X_WARNING,
> + "[RESUME] Cannot re-init Mach64 hardware, DRM too old\n"
> + "(need 1.9.0 or newer)\n");
> + return;
> + } */
You can remove the commented out code. The radeon driver checks for the
DRM minor version to make sure the resume ioctl is available. You don't
seem to need a new ioctl at all, checking for the DRI version doesn't
make sense here.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] tv-out of radeon mobility as another display?
Hello! Is it possible with the current (DRI) drivers to use tv-out as another display? Built-in LCD/VGA being the first display (:0.0), and tv-out as the second display (:0.1) ? How about (3d) acceleration on the tv-out? Does mergedfb help with this? gatos project seems to have some tv-out drivers available too.. but they support only "clone"-mode. If I remember correctly, this is supported under windows. Thanks. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI compile problems, missing includes
Thanks a bunch Micha, You were spot on. I'm sure this is in a Howto or README somewhere that I've some how missed. Cheers, Rick On Sat, 2004-01-17 at 14:10, Micha Feigin wrote: > If I got things right then the dri tree is not a complete X tree. You > need a working X installation to install over. It installs only the > modified files. > Under debian this file appears in the libx11-dev package, don't know > where it comes from in other distributions. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
