Re: CFS review
Rene Herman [2007-08-30 09:05]: > On 08/29/2007 09:56 PM, Rene Herman wrote: > > Realised the BUGs may mean the kernel DRM people could want to be in CC... > > > On 08/29/2007 05:57 PM, Keith Packard wrote: > > > >> With X server 1.3, I'm getting consistent crashes with two glxgear > >> instances running. So, if you're getting any output, it's better than my > >> situation. > > > > Before people focuss on software rendering too much -- also with 1.3.0 > > (and a Matrox Millenium G550 AGP, 32M) glxgears also works decidedly > > crummy using hardware rendering. While I can move the glxgears window > > itself, the actual spinning wheels stay in the upper-left corner of the > > screen and the movement leaves a non-repainting trace on the screen. This sounds like you're running an older version of Mesa. The bugfix went into Mesa 6.3 and 7.0. > > Running a second instance of glxgears in addition seems to make both > > instances unkillable -- and when I just now forcefully killed X in this > > situation (the spinning wheels were covering the upper left corner of all > > my desktops) I got the below. Running two instances of glxgears and killing them works for me, too. I'm using xorg-server 1.3.0.0, Mesa 7.0.1 with the latest DRM bits from http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary I'm not running CFS though, but I guess the oops wasn't related to that. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpiinZrp5CqP.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 / R500 support and news
Jerome Glisse [2007-01-11 16:32]: > I have setup a page on the DRI wiki: > http://dri.freedesktop.org/wiki/R300 Maybe Rune's status page should be merged with this one. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgplyEuzw8df6.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r500 - where to start?
Jerome Glisse [2006-12-23 23:23]: > On 12/23/06, Magnus Ahlberg <[EMAIL PROTECTED]> wrote: > > I know that there has been some discussion about the r500 chip and how > > tough it will be to create a working driver for it. However, I for one > > would love to see an open alternative to the fglrx and I want to know, > > where to start? I own a laptop with a X1600 mobility radeon card. > > > > The current status of the radeon driver is that xorg bails out with > > "no devices found". > > Is there any possibility to make the radeon driver to recognize my > > video card and at least try to initialize it? Where do I start? Are > > there any tools I can run or anything that will help a more > > experienced developer to point me in the right direction? > > > > Cheers. > > > > >From limited informations we got on those chips we miss the 2D > video mode setup. Basicly you need to spy bios/vbe try using > a tools such as mjg59/airlied vbe, you might also want to spy > fglrx maybe libsegfault can help you people.freedesktop.org/~glisse/ Just for the record, there's also airlied's valgrind-mmt that tracks MMIO register writes: http://www.skynet.ie/~airlied/patches/valgrind/ If that's not enough, I extended it and implemented support for tracking writes to write-only registers (and other stuff): http://code-monkey.de/articles/2007/01/08/hacking-up-valgrind-mmt Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgppohr38KQSG.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: /usr/X11R6/lib/modules ?
Jacek Poplawski [2006-11-26 05:46]: > I compiled Mesa CVS and after installation - my acceleration was broken, so > I enabled LIBGL_DEBUG and found that Mesa search for r300_dri.so not in > /usr/xorg/lib/modules/dri, but in /usr/X11R6/lib/modules/dri. I made a > symlink and now it works correctly. You need to override DRI_DRIVER_SEARCH_DIR - set it to /usr/xorg/lib/modules/dri. > I never had such problem before, is it a new change? > My distribution uses /usr/xorg/lib/modules only. > Is /usr/X11R6/lib/modules proper way now? No, of course not. There's a bug in Bugzilla that suggests to make /usr/lib/modules/dri the default, but it hasn't happened yet. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpFEFMJK4L3g.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: (MGA) DRI locking
Tilman Sauerbeck [2006-08-08 21:27]: > Tilman Sauerbeck [2006-07-28 18:21]: > > Tilman Sauerbeck [2006-07-28 14:42]: > > > Michel Dänzer [2006-07-28 13:40]: > > > > Are you familiar with the X server's function wrapping mechanism? > > > > DRI(Do)BlockHandler() is the DRI module's wrapper of the X server's > > > > BlockHandler screen hook, which it calls whenever it has run out of > > > > requests and goes to sleep for a bit. For symmetry, there's a DRILock() > > > > call in DRIDoWakeupHandler(), which is a wrapper for the hook the X > > > > server calls before it starts processing new requests. The idea is for > > > > the DRI module to automatically hold the lock whenever the X server > > > > might need hardware access. > > > > > > I should have asked a more specific question. While DRIBlockHandler() > > > was called all the time, DRIDoBlockHandler() was only called once, which > > > led to the bad DRIUnlock() call. I wanted to know when > > > DRI_Do_BlockHandler() is called :) > > > > > > Looking at the code again, it seems DRIDoWakeupHandler() and > > > DRIDoBlockHandler() are the base functions for the job, which may be > > > overridden by the DDX driver. MGA overrides both in MGADRIScreenInit(). > > > > So it seems like mga_dri.c's MGAWakeupHandler should always call > > DRILock(). The attached patch implements this change - it makes glxinfo > > work again. It's probably horribly wrong though... :) > > A better approach is to teach glxdri.c about the driver-specific > block/wakeuphandlers. See the attached patch. It makes glxinfo work as This patch has been committed. > well, but glxgears is still hanging. > > It seems that DRILockTree() is being the bugger that causes the > double-unlock: > > ... > (II) MGA(0): MGABlockHandler: unlocking > DRILockTree: unlocking > DRIUnlock called when not locked I committed a proper patch to the MGA driver (bde592047cd62194d7ef67520a9fdbaf269a8b90). Please report any regressions you might find ;) Thanks to anyone who helped in tracking this down. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpfoh3QavTUi.pgp Description: PGP signature - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: (MGA) DRI locking
Tilman Sauerbeck [2006-07-28 18:21]:
> Tilman Sauerbeck [2006-07-28 14:42]:
> > Michel Dänzer [2006-07-28 13:40]:
> > > Are you familiar with the X server's function wrapping mechanism?
> > > DRI(Do)BlockHandler() is the DRI module's wrapper of the X server's
> > > BlockHandler screen hook, which it calls whenever it has run out of
> > > requests and goes to sleep for a bit. For symmetry, there's a DRILock()
> > > call in DRIDoWakeupHandler(), which is a wrapper for the hook the X
> > > server calls before it starts processing new requests. The idea is for
> > > the DRI module to automatically hold the lock whenever the X server
> > > might need hardware access.
> >
> > I should have asked a more specific question. While DRIBlockHandler()
> > was called all the time, DRIDoBlockHandler() was only called once, which
> > led to the bad DRIUnlock() call. I wanted to know when
> > DRI_Do_BlockHandler() is called :)
> >
> > Looking at the code again, it seems DRIDoWakeupHandler() and
> > DRIDoBlockHandler() are the base functions for the job, which may be
> > overridden by the DDX driver. MGA overrides both in MGADRIScreenInit().
>
> So it seems like mga_dri.c's MGAWakeupHandler should always call
> DRILock(). The attached patch implements this change - it makes glxinfo
> work again. It's probably horribly wrong though... :)
A better approach is to teach glxdri.c about the driver-specific
block/wakeuphandlers. See the attached patch. It makes glxinfo work as
well, but glxgears is still hanging.
It seems that DRILockTree() is being the bugger that causes the
double-unlock:
...
(II) MGA(0): MGABlockHandler: unlocking
DRILockTree: unlocking
DRIUnlock called when not locked
...
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
diff --git a/GL/glx/glxdri.c b/GL/glx/glxdri.c
index 6a10554..cfa9996 100644
--- a/GL/glx/glxdri.c
+++ b/GL/glx/glxdri.c
@@ -137,19 +137,13 @@ #define COPY_SUB_BUFFER_INTERNAL_VERSION
static void
__glXDRIleaveServer(void)
{
- int i;
-
- for (i = 0; i < screenInfo.numScreens; i++)
-DRIDoBlockHandler(i, NULL, NULL, NULL);
+ DRIBlockHandler(NULL, NULL, NULL);
}
static void
__glXDRIenterServer(void)
{
- int i;
-
- for (i = 0; i < screenInfo.numScreens; i++)
-DRIDoWakeupHandler(i, NULL, 0, NULL);
+ DRIWakeupHandler(NULL, 0, NULL);
}
static void
pgpFDhHmih7At.pgp
Description: PGP signature
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: (MGA) DRI locking
Tilman Sauerbeck [2006-07-28 14:42]:
> Michel Dänzer [2006-07-28 13:40]:
> > Are you familiar with the X server's function wrapping mechanism?
> > DRI(Do)BlockHandler() is the DRI module's wrapper of the X server's
> > BlockHandler screen hook, which it calls whenever it has run out of
> > requests and goes to sleep for a bit. For symmetry, there's a DRILock()
> > call in DRIDoWakeupHandler(), which is a wrapper for the hook the X
> > server calls before it starts processing new requests. The idea is for
> > the DRI module to automatically hold the lock whenever the X server
> > might need hardware access.
>
> I should have asked a more specific question. While DRIBlockHandler()
> was called all the time, DRIDoBlockHandler() was only called once, which
> led to the bad DRIUnlock() call. I wanted to know when
> DRI_Do_BlockHandler() is called :)
>
> Looking at the code again, it seems DRIDoWakeupHandler() and
> DRIDoBlockHandler() are the base functions for the job, which may be
> overridden by the DDX driver. MGA overrides both in MGADRIScreenInit().
So it seems like mga_dri.c's MGAWakeupHandler should always call
DRILock(). The attached patch implements this change - it makes glxinfo
work again. It's probably horribly wrong though... :)
glxgears still hangs in glxMakeCurrent(). Any idea what to try next?
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
diff --git a/src/mga_dri.c b/src/mga_dri.c
index a43ebe4..246e87e 100644
--- a/src/mga_dri.c
+++ b/src/mga_dri.c
@@ -363,7 +363,6 @@ void MGAGetQuiescence( ScrnInfoPtr pScrn
{
MGAPtr pMga = MGAPTR(pScrn);
- DRILock( screenInfo.screens[pScrn->scrnIndex], 0 );
pMga->haveQuiescense = 1;
if ( pMga->directRenderingEnabled ) {
@@ -401,8 +400,6 @@ void MGAGetQuiescenceShared( ScrnInfoPtr
MGAEntPtr pMGAEnt = pMga->entityPrivate;
MGAPtr pMGA2 = MGAPTR(pMGAEnt->pScrn_2);
- DRILock( screenInfo.screens[pMGAEnt->pScrn_1->scrnIndex], 0 );
-
pMga = MGAPTR(pMGAEnt->pScrn_1);
pMga->haveQuiescense = 1;
pMGA2->haveQuiescense = 1;
@@ -496,13 +493,24 @@ static void MGAWakeupHandler( int screen
ScreenPtr pScreen = screenInfo.screens[screenNum];
ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
MGAPtr pMga = MGAPTR(pScrn);
+MGAEntPtr pMGAEnt;
if ( xf86IsEntityShared( pScrn->entityList[0] )
&& pMga->DualHeadEnabled) {
+pMGAEnt = pMga->entityPrivate;
+
+if (pMGAEnt->directRenderingEnabled)
+DRILock(screenInfo.screens[pMGAEnt->pScrn_1->scrnIndex], 0);
+
MGASwapContextShared( pScreen );
} else {
+if (pMga->directRenderingEnabled)
+DRILock(pScreen, 0);
+
MGASwapContext( pScreen );
}
+
+pMga->haveQuiescense = 1;
}
static void MGABlockHandler( int screenNum, pointer blockData,
diff --git a/src/mga_driver.c b/src/mga_driver.c
pgp7e1IjyhzzM.pgp
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: (MGA) DRI locking
Michel Dänzer [2006-07-28 13:40]: > On Thu, 2006-07-27 at 22:08 +0200, Tilman Sauerbeck wrote: > > > > Any idea what's wrong with the locking here? > > IIRC it's due to locking oddities in the mga DRI driver, I'm sure > Kristian knows more about it. Yeah, he told me that ajax looked into the problem, but he has been unresponsive so far ;) > > Hints on when DRIDoBlockHandler is called or why it can be called even > > though the DRI lock isn't held are appreciated :) > > Are you familiar with the X server's function wrapping mechanism? > DRI(Do)BlockHandler() is the DRI module's wrapper of the X server's > BlockHandler screen hook, which it calls whenever it has run out of > requests and goes to sleep for a bit. For symmetry, there's a DRILock() > call in DRIDoWakeupHandler(), which is a wrapper for the hook the X > server calls before it starts processing new requests. The idea is for > the DRI module to automatically hold the lock whenever the X server > might need hardware access. I should have asked a more specific question. While DRIBlockHandler() was called all the time, DRIDoBlockHandler() was only called once, which led to the bad DRIUnlock() call. I wanted to know when DRI_Do_BlockHandler() is called :) Looking at the code again, it seems DRIDoWakeupHandler() and DRIDoBlockHandler() are the base functions for the job, which may be overridden by the DDX driver. MGA overrides both in MGADRIScreenInit(). So the only place that could call DRIDoBlockHandler() is xserver/GL/glx/glxdri.c, in __glXDRIleaveServer(). I'll have a look at that code and see what I can find out. Thanks, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpEOSg3EHOTy.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
(MGA) DRI locking
Hi, I'm trying to fix bug 7265, but I'm stuck. I added some debugging output to the xserver and the mga driver and I attached the interesting parts of the lock. What's interesting is that DRILock()/DRIUnlock() are continually called about every second even if no DRI client is connected. This might be due to XAA rendering though, and it seems XAA cannot be disabled without disabling DRI, too. As my test case, I started glxinfo in a xterm (which hangs in mgaGetLock(), as expected). This is line 18 in the log. At the end of the log, you'll see that DRIDoBlockHandler() results in another DRIUnlock() call, although the lock isn't currently held. Now, the problem is that I cannot figure out why and how DRIDoBlockHandler() is called. It's assigned to the DRI inforec->wrap.BlockHandler, but I don't see when it's called. To make things worse, I cannot get a backtrace either... attaching GDB or using xorg_backtrace() will crash the server. Any idea what's wrong with the locking here? Hints on when DRIDoBlockHandler is called or why it can be called even though the DRI lock isn't held are appreciated :) Thanks, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? DRIWakeupHandler (II) MGA(0): MGAWakeupHandler (mga_dri.c) locking. flags = 0 (II) MGA(0): MGABlockHandler (mga_driver.c) DRIBlockHandler (II) MGA(0): MGABlockHandler (mga_dri.c) unlocking DRIWakeupHandler (II) MGA(0): MGAWakeupHandler (mga_dri.c) (II) MGA(0): MGABlockHandler (mga_driver.c) DRIBlockHandler (II) MGA(0): MGABlockHandler (mga_dri.c) # last block repeated 3 times # at about this time, I started glxinfo: DRIWakeupHandler (II) MGA(0): MGAWakeupHandler (mga_dri.c) locking. flags = 0 (II) MGA(0): MGABlockHandler (mga_driver.c) DRIBlockHandler (II) MGA(0): MGABlockHandler (mga_dri.c) unlocking DRIWakeupHandler (II) MGA(0): MGAWakeupHandler (mga_dri.c) (II) MGA(0): MGABlockHandler (mga_driver.c) DRIBlockHandler (II) MGA(0): MGABlockHandler (mga_dri.c) # last block repeated ~10 times DRIWakeupHandler (II) MGA(0): MGAWakeupHandler (mga_dri.c) DRIDoBlockHandler DRIUnlock called when not locked DRIDoWakeupHandler locking. flags = 0 pgptwoUYimV5W.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 code cleanup
Jerome Glisse [2006-07-03 23:49]: > I want to cleanup a bit the r300 code, there is a lot of dead > code. I also would like to use unified indenting rules and > function naming rules. Good idea :) > For indenting rules i personnaly use the linux kernel ones, > iirc this was the original indenting choosed by Nicolai. > Anyway, we can use another if people prefer another one > (as long as the indenting you propose is not severly broken). Shouldn't we stick to the Mesa indentation rules? > For function name i think that r300DoSomething is for > function called by mesa and r300_do_otherthings is for > internal driver function at leat this is my guess from looking > at i915 driver :) I'd prefer not to mix up CamelCase and snake_case. Do you think the benefit it provides is good enough to make up for the inconsistency? Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpQOziErOJsL.pgp Description: PGP signature Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Doom3 causes VBO leak
Brian Paul [2006-06-29 12:12]: > Tilman Sauerbeck wrote: > > Tilman Sauerbeck [2006-06-11 12:35]: > > > >>Tilman Sauerbeck [2006-05-22 19:42]: > >> > >>>[...] > >>> > >>>I found out that the buffer in question was allocated by > >>>r300BufferData(). Now, the proper call to radeon_mm_free() would have > >>>been made by r300DeleteBuffer(), but that function was never called. > >>> > >>>From looking at the code I think this means that it's an application > >>>error. > >>>Now the question is, should Mesa call the "DeleteBuffer" callback for > >>>all buffers that are still alive when the context is destroyed or should > >>>r300 be able to cope with it the way it currently is? > >> > >>Here's a patch that deletes all VBOs that are still alive when the > >>context is destroyed. > >> > >>Because r300DeleteBuffer() calls radeon_mm_free(), which depends on > >>ctx->DriverCtx, we now cannot set DriverCtx to NULL before destroying > >>the Mesa context however. > >> > >>Is this a problem? There's lots of driver calls in free_share_state() > >>that might depend on DriverCtx not being NULL, so I don't think I'm > >>adding new evil code here. > > > > > > Can anyone please comment on that patch? > > Looks OK to me. I think you can check it in. Thanks, I put it in. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgphsMDUvTaUN.pgp Description: PGP signature Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Doom3 causes VBO leak
Tilman Sauerbeck [2006-06-11 12:35]: > Tilman Sauerbeck [2006-05-22 19:42]: > > [...] > > > > I found out that the buffer in question was allocated by > > r300BufferData(). Now, the proper call to radeon_mm_free() would have > > been made by r300DeleteBuffer(), but that function was never called. > > > > From looking at the code I think this means that it's an application > > error. > > Now the question is, should Mesa call the "DeleteBuffer" callback for > > all buffers that are still alive when the context is destroyed or should > > r300 be able to cope with it the way it currently is? > > Here's a patch that deletes all VBOs that are still alive when the > context is destroyed. > > Because r300DeleteBuffer() calls radeon_mm_free(), which depends on > ctx->DriverCtx, we now cannot set DriverCtx to NULL before destroying > the Mesa context however. > > Is this a problem? There's lots of driver calls in free_share_state() > that might depend on DriverCtx not being NULL, so I don't think I'm > adding new evil code here. Can anyone please comment on that patch? Thanks, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpSARcDlst60.pgp Description: PGP signature Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][PATCH] fix vertex attribs - try 2 - Re: [r300] ARB vp attribs broken?
Brian Paul [2006-06-27 10:55]:
> Ian Romanick wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Tilman Sauerbeck wrote:
> >
> >
> >>Index: r300_context.h
> >>===
> >>RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v
> >>retrieving revision 1.98
> >>diff -u -p -r1.98 r300_context.h
> >>--- r300_context.h 27 Jun 2006 01:26:47 - 1.98
> >>+++ r300_context.h 27 Jun 2006 16:30:09 -
> >>@@ -544,7 +544,7 @@ struct r300_vap_reg_state {
> >> int i_color[2];
> >> int i_fog;
> >> int i_tex[R300_MAX_TEXTURE_UNITS];
> >>- int i_attrib[_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC];
> >>+ int i_attrib[_TNL_LAST_GENERIC - _TNL_FIRST_GENERIC + 1];
> >> int i_index;
> >> int i_pointsize;
> >>};
> >
> >
> > I think we should add a define _TNL_NUM_GENERIC for this. This will
> > likely happen in other drivers in the future, and I'd hate to see these
> > off-by-one errors come back.
>
> Yes, please do so. Put it in tnl/t_context.h
Done. I also committed the fix for the off-by-one problem.
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
pgppKsClsf05F.pgp
Description: PGP signature
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][PATCH] fix vertex attribs - try 2 - Re: [r300] ARB vp attribs broken?
Aapo Tahkola [2006-06-27 04:28]:
> On Mon, 26 Jun 2006 21:22:12 +0200
> Rune Petersen <[EMAIL PROTECTED]> wrote:
>
> > Brian Paul wrote:
> > > Rune Petersen wrote:
> > >> Tilman Sauerbeck wrote:
> > >>
> > >>> Rune Petersen [2006-06-25 16:31]:
> > >>>
> > >>>> I've been looking at vertex shaders this weekend.
> > >>>>
> > >>>> It would appear that attribs are broken. The most straight
> > >>>> forward way to test this it to compare progs/tests/arbvptest3 to
> > >>>> progs/tests/vptest3
> > >>>>
> > >>>> On my system I get different colors when I resize the window.
> > >>>>
> > >>>> Can someone confirm this? (it would explain why Doom 3 is broken)
> > >>>
> > >>> Yes, I have reported this some weeks ago:
> > >>> http://marc.theaimsgroup.com/?l=dri-devel&m=114855685402158&w=2
> > >>>
> > >>
> > >> Don't know how I fixed that...
> > >>
> > >> It would appear to be caused bu the reshuffling of the attribs.
> > >>
> > >> Any idea where the attribs are passed to the driver?
> > >> and how to read the data in the attribs...
> > >
> > > I can't comment on the r300 driver, but the change in vertex
> > > aliasing in core Mesa is pretty simple. It's really just a change
> > > of which index into the VB->Attribs[] array corresponds to
> > > glVertexAttribARB(index, ...).
> > >
> >
> >
> > This is getting embarrassing...
> >
> > try 3 attached.
>
> Checked in. Thanks.
Good job Rune, but didn't you sneak in a couple of off-by-one errors? :)
There's 16 generic TNL attributes, not 15. See the attached patch.
btw, Doom3 runs much better with the ARB2 renderer now, but there's
still some glitches.
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Index: r300_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v
retrieving revision 1.98
diff -u -p -r1.98 r300_context.h
--- r300_context.h 27 Jun 2006 01:26:47 - 1.98
+++ r300_context.h 27 Jun 2006 16:30:09 -
@@ -544,7 +544,7 @@ struct r300_vap_reg_state {
int i_color[2];
int i_fog;
int i_tex[R300_MAX_TEXTURE_UNITS];
- int i_attrib[_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC];
+ int i_attrib[_TNL_LAST_GENERIC - _TNL_FIRST_GENERIC + 1];
int i_index;
int i_pointsize;
};
Index: r300_maos.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_maos.c,v
retrieving revision 1.34
diff -u -p -r1.34 r300_maos.c
--- r300_maos.c 27 Jun 2006 01:26:47 - 1.34
+++ r300_maos.c 27 Jun 2006 16:30:09 -
@@ -368,7 +368,7 @@ void r300EmitArrays(GLcontext * ctx, GLb
rmesa->state.aos[nr++].aos_reg =
prog->inputs[VERT_ATTRIB_TEX0+i];
}
}
- for (i=0;i<(_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC);i++) {
+ for (i=0;i<=(_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC);i++) {
if (InputsRead & (1<<(VERT_ATTRIB_GENERIC0+i))) {
RENDERINPUTS_SET( inputs_bitset,
_TNL_ATTRIB_GENERIC(i) );
rmesa->state.aos[nr++].aos_reg =
prog->inputs[VERT_ATTRIB_GENERIC0+i];
@@ -463,7 +463,7 @@ void r300EmitArrays(GLcontext * ctx, GLb
r300->state.texture.tc_count++;
}
}
- for (i = 0; i < (_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC); i++) {
+ for (i = 0; i <= (_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC); i++) {
if (RENDERINPUTS_TEST( inputs_bitset, _TNL_ATTRIB_GENERIC(i) ))
{
CONFIGURE_AOS(i_attrib[i], AOS_FORMAT_FLOAT,
VB->AttribPtr[VERT_ATTRIB_GENERIC0+i],
pgp1UroyJMmYJ.pgp
Description: PGP signature
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] ARB vp attribs broken?
Rune Petersen [2006-06-25 21:55]: > Tilman Sauerbeck wrote: > > Rune Petersen [2006-06-25 16:31]: > >> I've been looking at vertex shaders this weekend. > >> > >> It would appear that attribs are broken. The most straight forward way > >> to test this it to compare progs/tests/arbvptest3 to progs/tests/vptest3 > >> > >> On my system I get different colors when I resize the window. > >> > >> Can someone confirm this? (it would explain why Doom 3 is broken) > > > > Yes, I have reported this some weeks ago: > > http://marc.theaimsgroup.com/?l=dri-devel&m=114855685402158&w=2 > > > Don't know how I fixed that... > > It would appear to be caused bu the reshuffling of the attribs. > > Any idea where the attribs are passed to the driver? > and how to read the data in the attribs... I figured it out. For NV vp's, the generic attributes will shadow the conventional ones, which means that src->Index will be 3 if you're accessing vertex.attrib[3] (the 3rd generic attribute). In ARB vp's, src->Index will be 19 instead for the 3rd generic attribute (= VERT_ATTRIB_GENERIC3). It seems the code in r300_vertexprog.c (and thus also the hardware) wants the number of the generic attribute... Modifying t_src_index in r300_vertexprog.c like this: tmp = src->Index; if (tmp >= VERT_ATTRIB_GENERIC0) tmp -= VERT_ATTRIB_GENERIC0; /* use tmp instead of src->Index in the following lines */ doesn't help though. Not sure what to do :/ Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgppa3yAGGlET.pgp Description: PGP signature Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] ARB vp attribs broken?
Rune Petersen [2006-06-25 16:31]: > I've been looking at vertex shaders this weekend. > > It would appear that attribs are broken. The most straight forward way > to test this it to compare progs/tests/arbvptest3 to progs/tests/vptest3 > > On my system I get different colors when I resize the window. > > Can someone confirm this? (it would explain why Doom 3 is broken) Yes, I have reported this some weeks ago: http://marc.theaimsgroup.com/?l=dri-devel&m=114855685402158&w=2 Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgphiYxceYfQY.pgp Description: PGP signature Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Aapo Tahkola [2006-06-18 15:40]: > On Sun, 18 Jun 2006 12:53:40 +0200 > Tilman Sauerbeck <[EMAIL PROTECTED]> wrote: > > > Rune Petersen [2006-06-18 02:27]: > > > Tilman Sauerbeck wrote: > > > > Rune Petersen [2006-06-17 23:38]: > > > > > > > >> I'm having problems with the ARL instruction. > > > >> It appears to mostly return 0. > > > > > > > > Yes. It would probably help if you could document in which cases > > > > it works reliably and in which cases it doesn't :) > > > > > > Something very strange is going on with ARL: > > > > > > I have an array with all non-zero values. > > > > > > I do an ARL on any given value within the array. > > > > > > > > > I read the array myArray[addr.x] and I allways get the value at > > > index 0. > > > > > > if I add an offset myArray[addr.x + ] where addr.x + > > > > "array size" provided addr.x is the correct value, I get > > > 0. > > > > > > Looks to me like there is a bounds check on arrays that work > > > correctly, but the actual array lookup is broken. > > > > > > Is this at all possible? > > > > Interesting, I can also reproduce this behaviour. So it seems like ARL > > is working correctly, but reading from ADDRESSes is broken. > > It should work now. Thanks. Awesome, the ARL test from progs/vp now passes, as do the glean tests :) Thanks, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgptT5AuBVTls.pgp Description: PGP signature -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Rune Petersen [2006-06-18 02:27]: > Tilman Sauerbeck wrote: > > Rune Petersen [2006-06-17 23:38]: > > > >> I'm having problems with the ARL instruction. > >> It appears to mostly return 0. > > > > Yes. It would probably help if you could document in which cases it > > works reliably and in which cases it doesn't :) > > Something very strange is going on with ARL: > > I have an array with all non-zero values. > > I do an ARL on any given value within the array. > > > I read the array myArray[addr.x] and I allways get the value at index 0. > > if I add an offset myArray[addr.x + ] where addr.x + > > "array size" provided addr.x is the correct value, I get 0. > > Looks to me like there is a bounds check on arrays that work correctly, > but the actual array lookup is broken. > > Is this at all possible? Interesting, I can also reproduce this behaviour. So it seems like ARL is working correctly, but reading from ADDRESSes is broken. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpnLYCFg6XXP.pgp Description: PGP signature -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Rune Petersen [2006-06-17 23:38]: > I'm having problems with the ARL instruction. > It appears to mostly return 0. Yes. It would probably help if you could document in which cases it works reliably and in which cases it doesn't :) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpl1gBQPCiSm.pgp Description: PGP signature -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Doom3 causes VBO leak
Tilman Sauerbeck [2006-05-22 19:42]:
> [...]
>
> I found out that the buffer in question was allocated by
> r300BufferData(). Now, the proper call to radeon_mm_free() would have
> been made by r300DeleteBuffer(), but that function was never called.
>
> From looking at the code I think this means that it's an application
> error.
> Now the question is, should Mesa call the "DeleteBuffer" callback for
> all buffers that are still alive when the context is destroyed or should
> r300 be able to cope with it the way it currently is?
Here's a patch that deletes all VBOs that are still alive when the
context is destroyed.
Because r300DeleteBuffer() calls radeon_mm_free(), which depends on
ctx->DriverCtx, we now cannot set DriverCtx to NULL before destroying
the Mesa context however.
Is this a problem? There's lots of driver calls in free_share_state()
that might depend on DriverCtx not being NULL, so I don't think I'm
adding new evil code here.
Comments?
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
? progs/vp/arbvptorus.c
? progs/vp/vp-tris
Index: src/mesa/drivers/dri/r300/r300_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.c,v
retrieving revision 1.54
diff -u -p -r1.54 r300_context.c
--- src/mesa/drivers/dri/r300/r300_context.c11 Jun 2006 09:12:27 -
1.54
+++ src/mesa/drivers/dri/r300/r300_context.c11 Jun 2006 10:31:35 -
@@ -385,8 +385,12 @@ static void r300FreeGartAllocations(r300
if (r300->rmm->u_list[i].ptr == NULL) {
continue;
}
-
- assert(r300->rmm->u_list[i].pending);
+
+ /* check whether this buffer is still in use */
+ if (!r300->rmm->u_list[i].pending) {
+ continue;
+ }
+
assert(r300->rmm->u_list[i].h_pending == 0);
tries = 0;
Index: src/mesa/drivers/dri/r300/radeon_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_context.c,v
retrieving revision 1.12
diff -u -p -r1.12 radeon_context.c
--- src/mesa/drivers/dri/r300/radeon_context.c 2 Jun 2006 01:52:54 -
1.12
+++ src/mesa/drivers/dri/r300/radeon_context.c 11 Jun 2006 10:31:36 -
@@ -202,9 +202,13 @@ GLboolean radeonInitContext(radeonContex
void radeonCleanupContext(radeonContextPtr radeon)
{
/* free the Mesa context */
- radeon->glCtx->DriverCtx = NULL;
_mesa_destroy_context(radeon->glCtx);
+ /* the above call might result in calls to functions that depend on
+* the DriverCtx.
+*/
+ radeon->glCtx->DriverCtx = NULL;
+
if (radeon->state.scissor.pClipRects) {
FREE(radeon->state.scissor.pClipRects);
radeon->state.scissor.pClipRects = 0;
Index: src/mesa/main/context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/main/context.c,v
retrieving revision 1.276
diff -u -p -r1.276 context.c
--- src/mesa/main/context.c 15 May 2006 15:26:04 - 1.276
+++ src/mesa/main/context.c 11 Jun 2006 10:31:40 -
@@ -887,6 +887,20 @@ free_shared_state( GLcontext *ctx, struc
#endif
#if FEATURE_ARB_vertex_buffer_object
+ /* Free vertex buffer objects */
+ while (1) {
+ GLuint name = _mesa_HashFirstEntry(ss->BufferObjects);
+ if (name) {
+ struct gl_buffer_object *bufObj = (struct gl_buffer_object *)
+_mesa_HashLookup(ss->BufferObjects, name);
+ ASSERT(bufObj);
+ ctx->Driver.DeleteBuffer(ctx, bufObj);
+ _mesa_HashRemove(ss->BufferObjects, name);
+ }
+ else {
+ break;
+ }
+ }
_mesa_DeleteHashTable(ss->BufferObjects);
#endif
pgpp3FXHtlOgv.pgp
Description: PGP signature
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Adam K Kirchhoff [2006-06-10 18:33]: > Rune Petersen wrote: > > Adam K Kirchhoff wrote: > >> So last night I decided to give the new vertex programs on the r200 > >> driver a shot and to see how doom3 stacked up with the r200 driver vs > >> the fglrx driver now. With both drivers, I was getting approximately > >> 12 FPS with demo1 (with the r200 renderer, of course). > >> > >> This morning I decided to give the r300 driver a shot, but ran into > >> some problems: > >> > >> http://68.44.156.246/shot-current.jpg > >> > >> Everything is shiny and textures are all screwed up :-) > >> > >> Same room, but with the Mesa 6.5 drivers: > >> > >> http://68.44.156.246/shot-6.5.jpg > >> > >> If this isn't something currently being worked on, I'll go ahead and > >> open up a new bug for it. > > > > set r_renderer "arb" > > > > r_renderer "arb2" is broken. My guess is that with Mesa 6.5, Doom 3 > > (demo) defaults to arb unlike with Mesa CVS. > > Sorry, but according to the output from doom3, it's using the ARB render > path for both 6.5 and CVS. Here both versions result in Doom3 choosing the ARB2 renderer, the startup logs are nearly identical. Setting r_renderer to "arb" does indeed fix the rendering problems with cvs HEAD for me. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpEy75Gtu1Cv.pgp Description: PGP signature -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Adam K Kirchhoff [2006-06-10 17:54]: > This morning I decided to give the r300 driver a shot, but ran into some > problems: > > http://68.44.156.246/shot-current.jpg > > Everything is shiny and textures are all screwed up :-) I guess this is the same problem I reported earlier: http://marc.theaimsgroup.com/?l=dri-devel&m=114855685402158&w=2 Seems this one isn't easy to fix, so opening bug sounds like a good idea :) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpYZaga1sjTK.pgp Description: PGP signature -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] per-component negation for SWZ
Roland Scheidegger [2006-05-30 22:33]: > Tilman Sauerbeck wrote: > > I finally ran glean today, and noticed that SWZ wasn't implemented > > properly for r300 ARB vertex programs. > > > > So far I didn't handle per-component negation flags, the attached patch > > adds that. > > > > Question: is it okay to assume that "NegateBase" in > > struct prog_src_register will always be filled the way it's filled > > currently? ie that the sign for the x component is at bit 0 etc. > I'd guess that's ok. Whoever wants to change it needs to make sure that > the code wherever it's used still works. Such things can get forgotten > though, but in that case someone will notice and fix it up then :-). Mmh, alright :) > > If it doesn't, the patch I attached obviously wouldn't work... > > > > If there are no objections, I'll commit this in a few days. > Wouldn't it be simpler to just change t_src to always apply > src->NegateBase? I can't see a need for that "src->NegateBase ? > VSF_FLAG_ALL : VSF_FLAG_NONE", as the mesa parser sets all 4 bits anyway > when "normal" instructions are parsed. The code would both be smaller > and faster :-). (t_src_scalar OTOH cannot be changed.) That won't work for NV vertex programs. nvvertparse.c sets NegateBase to either GL_TRUE or GL_FALSE. If they'd use 0xf (== VSF_FLAG_ALL) and 0x0 as NV fp and ARB vp/fp do, it would work indeed :) Maybe nvvertparse.c should be changed? Setting a GLuint bitfield to GL_TRUE seems a bit weird :) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgp10YtlvJKwL.pgp Description: PGP signature -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] per-component negation for SWZ
Hi, I finally ran glean today, and noticed that SWZ wasn't implemented properly for r300 ARB vertex programs. So far I didn't handle per-component negation flags, the attached patch adds that. Question: is it okay to assume that "NegateBase" in struct prog_src_register will always be filled the way it's filled currently? ie that the sign for the x component is at bit 0 etc. If it doesn't, the patch I attached obviously wouldn't work... If there are no objections, I'll commit this in a few days. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? Index: src/mesa/drivers/dri/r300/r300_vertexprog.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_vertexprog.c,v retrieving revision 1.51 diff -u -p -r1.51 r300_vertexprog.c --- src/mesa/drivers/dri/r300/r300_vertexprog.c 30 May 2006 18:49:20 - 1.51 +++ src/mesa/drivers/dri/r300/r300_vertexprog.c 30 May 2006 19:11:56 - @@ -913,7 +913,19 @@ void r300_translate_vertex_shader(struct o_inst->op=MAKE_VSF_OP(hw_op, t_dst_index(vp, &vpi->DstReg), t_dst_mask(vpi->DstReg.WriteMask), t_dst_class(vpi->DstReg.File)); - o_inst->src1=t_src(vp, &src[0]); + /* SWZ supports per-component negation in the swizzle mask, +* so we just pass src->NegateBase as-is, instead of reducing it +* to VSF_FLAG_ALL or VSF_FLAG_NONE. +* This works because the flags in NegateBase equal the ones we +* need here. +*/ + o_inst->src1=MAKE_VSF_SOURCE(t_src_index(vp, &src[0]), + t_swizzle(GET_SWZ(src->Swizzle, 0)), + t_swizzle(GET_SWZ(src->Swizzle, 1)), + t_swizzle(GET_SWZ(src->Swizzle, 2)), + t_swizzle(GET_SWZ(src->Swizzle, 3)), + t_src_class(src->File), + src->NegateBase) | (src->RelAddr << 4); o_inst->src2=ONE_SRC_0; o_inst->src3=ZERO_SRC_0; pgpri282900Y3.pgp Description: PGP signature -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] vertex attribute changes broke Doom3?
Brian Paul [2006-05-29 08:42]: > Tilman Sauerbeck wrote: > >Hi, > >I suspect that the vertex attribute changes from 2006-04-26 broke > >Doom3 on r300. > >Symptoms: > >The rendering of Mars in the main menu screen is broken, see the > >attached screenshot (the planet is supposed to look reddish, not white). > >It's also flickering a lot. > >Similar problems exist in game, but they aren't very well visible on > >screenshots... > >Anyway, CVS from 2006-04-25 works, but the code from the 26th (including > >the _TNL_ATTRIB_INDEX -> _TNL_ATTRIB_LAST_MAT fix) doesn't. > >Any ideas? > > I just checked in a patch to Mesa that _might_ help with this. Jesse's patch improves the rendering, but it's not perfect yet. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpSdQDzkbi0n.pgp Description: PGP signature
[r300] vertex attribute changes broke Doom3?
Hi, I suspect that the vertex attribute changes from 2006-04-26 broke Doom3 on r300. Symptoms: The rendering of Mars in the main menu screen is broken, see the attached screenshot (the planet is supposed to look reddish, not white). It's also flickering a lot. Similar problems exist in game, but they aren't very well visible on screenshots... Anyway, CVS from 2006-04-25 works, but the code from the 26th (including the _TNL_ATTRIB_INDEX -> _TNL_ATTRIB_LAST_MAT fix) doesn't. Any ideas? Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpxBqHEwEMzc.pgp Description: PGP signature
[r300] Doom3 causes VBO leak
Hi, when I exit Doom3, I'm seeing the following error message on stdout: doom.x86: r300_context.c:392: r300FreeGartAllocations: Assertion `r300->rmm->u_list[i].pending' failed. The believe this indicates that a buffer that was allocated by radeon_mm_alloc() hasn't been freed by radeon_mm_free() (the latter sets the pending flag). So this indicates a memory leak of some kind. I found out that the buffer in question was allocated by r300BufferData(). Now, the proper call to radeon_mm_free() would have been made by r300DeleteBuffer(), but that function was never called. From looking at the code I think this means that it's an application error. Now the question is, should Mesa call the "DeleteBuffer" callback for all buffers that are still alive when the context is destroyed or should r300 be able to cope with it the way it currently is? Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgptmBWuvwpOE.pgp Description: PGP signature
Re: Insane build system (Was: glxinfo segfaults with r300)
Daniel Stone [2006-04-14 14:50]:
> On Fri, Apr 14, 2006 at 07:08:30AM -0600, Brian Paul wrote:
> > Tilman Sauerbeck wrote:
> > >Benjamin Herrenschmidt [2006-04-14 16:40]:
> > >>Ok, finally... stale {prefix}/include/GL/internal/glcore.h
> > >>
> > >>No idea who installed this file, it wasn't updated by a make install of
> > >>Mesa/DRI, could have been put there by the server, not sure.
> > >
> > >{prefix}/include/GL/internal/glcore.h is installed by xorg's glproto.
> >
> > Why is that? I don't think that's a good idea. {prefix}/include/GL
> > should only have the public OpenGL headers needed to compile apps, no
> > internal headers.
>
> Last I checked, drivers needed this to build, and since the drivers are
> now out-of-tree from the server and Mesa builds ...
Seems they don't need it anymore:
[EMAIL PROTECTED] [~/devel/other/xorg/driver] > grep -r glcore xf86-video-*
[EMAIL PROTECTED] [~/devel/other/xorg/driver] >
(that's CVS HEAD)
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
pgpUnVEFb5sPV.pgp
Description: PGP signature
Re: Insane build system (Was: glxinfo segfaults with r300)
Benjamin Herrenschmidt [2006-04-14 16:40]:
> On Fri, 2006-04-14 at 15:31 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2006-04-14 at 15:15 +1000, Benjamin Herrenschmidt wrote:
> > > > Not sure at this point, but the problem ends up being ctx->DriverCtx at
> > > > a different offset
> > > > within GLcontext between mesa context.c and r300_tex.c.
> > > >
> > > > Looks like to get the stuff built properly, one has to build first, make
> > > > install, make clean and rebuild, and finally re-make install
> > >
> > > Oh, and I'm not even sure where the "installed" versions came from...
> > > looks like it could have been from an X.org install (does it install
> > > GL/internal/* stuff too ?)
> >
> > Hrm... did make install which updated headers, rebuilt all and still
> > crash... so something else is causing r300_tex.c to be built with a
> > different idea of what GLcontext is than the rest of mesa, maybe some
> > #define related to an EXTension or something like that...
>
> Ok, finally... stale {prefix}/include/GL/internal/glcore.h
>
> No idea who installed this file, it wasn't updated by a make install of
> Mesa/DRI, could have been put there by the server, not sure.
{prefix}/include/GL/internal/glcore.h is installed by xorg's glproto.
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
pgpHdyM4PV2eq.pgp
Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-14 10:06]: > > > > Can you try all combinations of my old patch, new patch, X patch & !X > > > patch and let me know what the results are ? > > > > If it's perfectly stable with your latest patch and without that one bad > > Mesa patch, would that convince you it's not a bug in DRM/DDX? :) > > Well, I'm navigating between lots of conflicting reports so yes, any > "solid" data like that would be very useful. Also, is it stable if not > using 3d ? Yes, it is. FYI, this is with an ATI R420 JI [Radeon X800PRO] (that's what lspci says, I think the box says it's an x800 GTO). Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpAq983QxHJV.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-14 09:37]: > > > Current DRM CVS HEAD doesn't work for me. However it does work with a > > small patch applied: > > https://bugs.freedesktop.org/show_bug.cgi?id=5450#c3 > > > > Does it make sense to test that DRM code with the new X patch? > > You mean the DRM without my old patch doesn't work ? What was the > symptom ? lockups ? So it worked in the short period of time when my old > patch was in and broke when it was backed off right ? If revision 1.71 of radeon_cp.c was the only change that was backed off, then yes, in worked with your old patch. When the single radeon_cp.c change was backed off, my screen got garbled on X startup and the machine locked up hard. > That's interesting... In that case I would have expected my new patch to > work but you say you still have lockups. As I said in my other mail, it's quite likely that the lock up was introduced by bad Mesa code. > Can you try all combinations of my old patch, new patch, X patch & !X > patch and let me know what the results are ? If it's perfectly stable with your latest patch and without that one bad Mesa patch, would that convince you it's not a bug in DRM/DDX? :) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgppYIKlwVPwa.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-13 09:20]: > On Sun, 2006-02-12 at 19:25 +0100, Tilman Sauerbeck wrote: > > Tilman Sauerbeck [2006-02-12 13:39]: > > > Benjamin Herrenschmidt [2006-02-10 18:12]: > > > > Here's a 3rd set of patches. Please report regressions ASAP as I intend > > > > to merge those in the various CVS trees real soon now. > > > > > > > > [...] > > > > > > > > Also, I fixed a potential issue in the DRM with machines where AGP > > > > writeback doesn't work (we would still rely on AGP writeback for the > > > > ring read ptr instead of reading it from a register). > > > > > > I believe these 2 patches introduce a hardware lockup problem in 3D > > > mode for me. It's not reliably reproduced though, so I'm not sure > > > > n/m, I just reproduced it with patch set #2, so it's not a regression. > > What if you only apply the X patch and not the DRM patch ? It's possible that the crash that I'm seeing was introduced by a change to the r300 DRI driver, so it's not DRMs fault necessarily. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpPonvV6Wj8t.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-13 09:20]: > On Sun, 2006-02-12 at 19:25 +0100, Tilman Sauerbeck wrote: > > Tilman Sauerbeck [2006-02-12 13:39]: > > > Benjamin Herrenschmidt [2006-02-10 18:12]: > > > > Here's a 3rd set of patches. Please report regressions ASAP as I intend > > > > to merge those in the various CVS trees real soon now. > > > > > > > > [...] > > > > > > > > Also, I fixed a potential issue in the DRM with machines where AGP > > > > writeback doesn't work (we would still rely on AGP writeback for the > > > > ring read ptr instead of reading it from a register). > > > > > > I believe these 2 patches introduce a hardware lockup problem in 3D > > > mode for me. It's not reliably reproduced though, so I'm not sure > > > > n/m, I just reproduced it with patch set #2, so it's not a regression. > > What if you only apply the X patch and not the DRM patch ? Current DRM CVS HEAD doesn't work for me. However it does work with a small patch applied: https://bugs.freedesktop.org/show_bug.cgi?id=5450#c3 Does it make sense to test that DRM code with the new X patch? Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpaVumFHj6yo.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Tilman Sauerbeck [2006-02-12 13:39]: > Benjamin Herrenschmidt [2006-02-10 18:12]: > > Here's a 3rd set of patches. Please report regressions ASAP as I intend > > to merge those in the various CVS trees real soon now. > > > > [...] > > > > Also, I fixed a potential issue in the DRM with machines where AGP > > writeback doesn't work (we would still rely on AGP writeback for the > > ring read ptr instead of reading it from a register). > > I believe these 2 patches introduce a hardware lockup problem in 3D > mode for me. It's not reliably reproduced though, so I'm not sure n/m, I just reproduced it with patch set #2, so it's not a regression. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpkVuHLhIJXr.pgp Description: PGP signature
Re: [PATCH] new radeon memory map fixes (#3)
Benjamin Herrenschmidt [2006-02-10 18:12]:
> Here's a 3rd set of patches. Please report regressions ASAP as I intend
> to merge those in the various CVS trees real soon now.
>
> [...]
>
> Also, I fixed a potential issue in the DRM with machines where AGP
> writeback doesn't work (we would still rely on AGP writeback for the
> ring read ptr instead of reading it from a register).
I believe these 2 patches introduce a hardware lockup problem in 3D
mode for me. It's not reliably reproduced though, so I'm not sure
whether this is a regression wrt to patch set #2 or a another problem.
However, I never had that problem with the second patch set.
The symptom is that my LCD turns off ("no signal") and the machine locks
up. I don't know enough about the DRM code to say whether it's even
possible that the diff between drm-3.diff and drm-4.diff could introduce
such problems.
The AGP writeback stuff seems to work just fine on my machine. dmesg
says: [drm] writeback test succeeded, tmp=1.
The graphics card is a ATI Technologies Inc R420 JI [Radeon X800PRO] /
X800 GTO.
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
pgpaXI55DXFo2.pgp
Description: PGP signature
Re: persistant problems with drm + mga
David Mulcahy [2006-01-03 13:34]: > http://sourceforge.net/mailarchive/forum.php?thread_id=8163981&forum_id=7177 The "missing visuals" messages aren't a problem from my experience. I think the Blender bug is this one: https://bugs.freedesktop.org/show_bug.cgi?id=1236 > Now although That particular problem has stopped I still cannot get drm > working again. I have a current kernel 2.6.14 and a new xorg "X Protocol > Version 11, Revision 0, Release 6.9" but still no drm. No clue on that. Regards, Tilman -- GnuPG key available at http://code-monkey.de/files/tsauerbeck-public-key.asc pgp37QKwTkznJ.pgp Description: PGP signature
[PATCH] drmStrdup doesn't check for failed allocation
Hi,
drmStrdup() doesn't check for an allocation failure. I attached a patch
that also tries to improve readability of the code. Feel free to
disagree on that :)
I realize the chances of drmStrdup() failing are probably low, but it
should be corrected anyway.
Regards,
Tilman
Index: libdrm/xf86drm.c
===
RCS file: /cvs/dri/drm/libdrm/xf86drm.c,v
retrieving revision 1.53
diff -u -r1.53 xf86drm.c
--- libdrm/xf86drm.c29 Nov 2005 09:50:47 - 1.53
+++ libdrm/xf86drm.c29 Nov 2005 19:27:46 -
@@ -164,12 +164,15 @@
/* drmStrdup can't use strdup(3), since it doesn't call _DRM_MALLOC... */
static char *drmStrdup(const char *s)
{
-char *retval = NULL;
+char *retval;
+
+if (!s) return NULL;
+
+retval = _DRM_MALLOC(strlen(s)+1);
+if (!retval) return NULL;
+
+strcpy(retval, s);
-if (s) {
- retval = _DRM_MALLOC(strlen(s)+1);
- strcpy(retval, s);
-}
return retval;
}
pgpvy3nfQougT.pgp
Description: PGP signature
