From: Robert S. K. <rs...@ds...> - 2005-11-30 16:26:09
Attachments:
rskerr.vcf
|
Hello, I'm writing to ask about the status of the savage driver and DRI in X.org. I have a Linux machine that I use for MythTV (a homebrew PVR app) running FC3 with an onboard Prosavage DDR chip in it. A while back (FEB '05), I spent the time to get DRI working on my X.org install. It worked great, but at the time caused other performance issues when dragging windows that made the benefits of accelerated openGL not worth it. The issue was that when dragging windows around on the screen, or under Myth when I play video, there is a spike in my Xserver's CPU utilization. Without DRI, Xserver utilization never broke 10% or so. When DRI was enabled, it would jump to as high as 50% utilization. At the time, Felix Kuhling mentioned that the driver was essentially very inefficient and didn't make use of IRQs or DMA to speed things up. My question is if this has been resolved in recent work with DRI and x.org has resolved either of these two issues. I've looked through the archives but haven't seen any direct reference, but I noticed that there has been a fair amount of savage work in the interim. Can anyone provide some insight? Also, when I compiled DRI in the past, I had to get the CVS version of X.org, CVS Mesa, and CVS DRM and build all the parts separately. I've noticed that X.org now includes versions of Mesa and DRM in its tree. Can I use these to compile DRM for the Savage? Rob |
From: Alex D. <ale...@gm...> - 2005-11-30 17:33:22
|
On 11/30/05, Robert S. Kerr <rs...@ds...> wrote: > Hello, > > I'm writing to ask about the status of the savage driver and DRI in X.org= . > > I have a Linux machine that I use for MythTV (a homebrew PVR app) > running FC3 with an onboard Prosavage DDR chip in it. > > A while back (FEB '05), I spent the time to get DRI working on my X.org > install. It worked great, but at the time caused other performance > issues when dragging windows that made the benefits of accelerated > openGL not worth it. The issue was that when dragging windows around on > the screen, or under Myth when I play video, there is a spike in my > Xserver's CPU utilization. Without DRI, Xserver utilization never broke > 10% or so. When DRI was enabled, it would jump to as high as 50% > utilization. > I don't see how the DRI would affect regular 2D performance unless some app you are using uses the drm or GL somehow. > At the time, Felix Kuhling mentioned that the driver was essentially > very inefficient and didn't make use of IRQs or DMA to speed things up. > > My question is if this has been resolved in recent work with DRI and > x.org has resolved either of these two issues. I've looked through the > archives but haven't seen any direct reference, but I noticed that there > has been a fair amount of savage work in the interim. > > Can anyone provide some insight? > > Also, when I compiled DRI in the past, I had to get the CVS version of > X.org, CVS Mesa, and CVS DRM and build all the parts separately. I've > noticed that X.org now includes versions of Mesa and DRM in its tree. > Can I use these to compile DRM for the Savage? > the drm and mesa were always included in monolithic xorg releases, however, savage DRI support in mesa and drm was not merged in until recently. you can now use either. the version of mesa in xorg cvs is 6.4.x, while cvs mesa and drm as the latest and greatest. Alex > Rob > > > > |
From: Felix <fx...@gm...> - 2005-11-30 23:38:53
|
Am Mittwoch, den 30.11.2005, 12:33 -0500 schrieb Alex Deucher: > On 11/30/05, Robert S. Kerr <rs...@ds...> wrote: > > Hello, > > > > I'm writing to ask about the status of the savage driver and DRI in X.o= rg. > > > > I have a Linux machine that I use for MythTV (a homebrew PVR app) > > running FC3 with an onboard Prosavage DDR chip in it. > > > > A while back (FEB '05), I spent the time to get DRI working on my X.org > > install. It worked great, but at the time caused other performance > > issues when dragging windows that made the benefits of accelerated > > openGL not worth it. The issue was that when dragging windows around o= n > > the screen, or under Myth when I play video, there is a spike in my > > Xserver's CPU utilization. Without DRI, Xserver utilization never brok= e > > 10% or so. When DRI was enabled, it would jump to as high as 50% > > utilization. > > >=20 > I don't see how the DRI would affect regular 2D performance unless > some app you are using uses the drm or GL somehow. The tiled frame-buffer might have a bad performance impact on direct access to the frame buffer. I had the impression that software fallbacks were very slow in the Savage and my guess was that the translation from linear for tiled memory layout in hardware may be the cause. Also the Xv implementation is new in current CVS compared to Xorg 6.8. It adds smooth scaling (with some caveats) on the Savage 4, ProSavage and Twister. It may also have different performance compared to Xorg 6.8. Another thing: I did some work on shadow status in January which might have an impact on performance under some circumstances. Robert, I'm not sure if your bad experience was before or after those changes. Regards, Felix >=20 > > At the time, Felix Kuhling mentioned that the driver was essentially > > very inefficient and didn't make use of IRQs or DMA to speed things up. > > > > My question is if this has been resolved in recent work with DRI and > > x.org has resolved either of these two issues. I've looked through the > > archives but haven't seen any direct reference, but I noticed that ther= e > > has been a fair amount of savage work in the interim. > > > > Can anyone provide some insight? > > > > Also, when I compiled DRI in the past, I had to get the CVS version of > > X.org, CVS Mesa, and CVS DRM and build all the parts separately. I've > > noticed that X.org now includes versions of Mesa and DRM in its tree. > > Can I use these to compile DRM for the Savage? > > >=20 > the drm and mesa were always included in monolithic xorg releases, > however, savage DRI support in mesa and drm was not merged in until > recently. you can now use either. the version of mesa in xorg cvs is > 6.4.x, while cvs mesa and drm as the latest and greatest. >=20 > Alex >=20 > > Rob > > > > > > > > >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick > -- > _______________________________________________ > Dri-users mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-users >=20 >=20 --=20 | Felix K=C3=BChling <fx...@gm...> http://fxk.de.vu = | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: Robert S. K. <rs...@ds...> - 2005-11-30 19:01:52
Attachments:
rskerr.vcf
|
Alex, Felix, Thanks both of you for your help here. I'm planning to try again and see what I find. The apps I was running previously (and will be running again) are an xserver and MythTV. MythTV does video playback so there is use of streams and Xv scaling going on in there I'm pretty sure. The problem before was that replaying video was taking way more CPU with the DRI enabled than without. To explore some more I found a couple of really simple apps that did similar operations (I don't remember the name, but I think one was called xvtest or something like that. It just displayed an image (single frame animation?) and used Xv to scale it to the window size.) Dragging that window around caused a CPU spike. It might have been all windows but I don't remember. Its entirely possible that I botched up the X install last time around too. Everything seemed to work okay though. The logs showed DRI being enabled, but if I remember correctly, getting everything installed took a couple of tries, it could be that some part of my work messed up the rest of the X install. The last e-mail I sent was 28 FEB 05, so I probably had the shadow status stuff as I was using CVS at the time. If you check this link: http://archive.netbsd.se/?ml=dri-users&a=2005-03&t=729479 You can see what I wrote then and your responses. Not all of it is making sense to me now as I've forgotten some of what I'd learned about this stuff and I don't know diddley about how X drivers work or I'd try to hack this out myself, but I remember at the time, your responses made sense to me. You mentioned something about DRM not using IRQs and that being the likely source, but then also mentioned that if the driver used BCI instead of MMIO it might be faster. At the time you both mentioned that you had other things you were working on and so wouldn't be doing anything in this area anytime soon. I'll have some time Thursday and Friday to play around with this stuff again and will be happy to report my progress. Is the users list the right place? Rob Felix Kühling wrote: > Am Mittwoch, den 30.11.2005, 12:33 -0500 schrieb Alex Deucher: > >> On 11/30/05, Robert S. Kerr <rs...@ds...> wrote: >> >>> Hello, >>> >>> I'm writing to ask about the status of the savage driver and DRI in X.org. >>> >>> I have a Linux machine that I use for MythTV (a homebrew PVR app) >>> running FC3 with an onboard Prosavage DDR chip in it. >>> >>> A while back (FEB '05), I spent the time to get DRI working on my X.org >>> install. It worked great, but at the time caused other performance >>> issues when dragging windows that made the benefits of accelerated >>> openGL not worth it. The issue was that when dragging windows around on >>> the screen, or under Myth when I play video, there is a spike in my >>> Xserver's CPU utilization. Without DRI, Xserver utilization never broke >>> 10% or so. When DRI was enabled, it would jump to as high as 50% >>> utilization. >>> >>> >> I don't see how the DRI would affect regular 2D performance unless >> some app you are using uses the drm or GL somehow. >> > > The tiled frame-buffer might have a bad performance impact on direct > access to the frame buffer. I had the impression that software fallbacks > were very slow in the Savage and my guess was that the translation from > linear for tiled memory layout in hardware may be the cause. > > Also the Xv implementation is new in current CVS compared to Xorg 6.8. > It adds smooth scaling (with some caveats) on the Savage 4, ProSavage > and Twister. It may also have different performance compared to Xorg > 6.8. > > Another thing: I did some work on shadow status in January which might > have an impact on performance under some circumstances. Robert, I'm not > sure if your bad experience was before or after those changes. > > Regards, > Felix > > >>> At the time, Felix Kuhling mentioned that the driver was essentially >>> very inefficient and didn't make use of IRQs or DMA to speed things up. >>> >>> My question is if this has been resolved in recent work with DRI and >>> x.org has resolved either of these two issues. I've looked through the >>> archives but haven't seen any direct reference, but I noticed that there >>> has been a fair amount of savage work in the interim. >>> >>> Can anyone provide some insight? >>> >>> Also, when I compiled DRI in the past, I had to get the CVS version of >>> X.org, CVS Mesa, and CVS DRM and build all the parts separately. I've >>> noticed that X.org now includes versions of Mesa and DRM in its tree. >>> Can I use these to compile DRM for the Savage? >>> >>> >> the drm and mesa were always included in monolithic xorg releases, >> however, savage DRI support in mesa and drm was not merged in until >> recently. you can now use either. the version of mesa in xorg cvs is >> 6.4.x, while cvs mesa and drm as the latest and greatest. >> >> Alex >> >> >>> Rob >>> >>> >>> >>> >>> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click >> -- >> _______________________________________________ >> Dri-users mailing list >> Dri...@li... >> https://lists.sourceforge.net/lists/listinfo/dri-users >> >> >> |
From: Alex D. <ale...@gm...> - 2005-11-30 19:28:14
|
On 11/30/05, Robert S. Kerr <rs...@ds...> wrote: > Alex, Felix, > > Thanks both of you for your help here. > > I'm planning to try again and see what I find. > > The apps I was running previously (and will be running again) are an > xserver and MythTV. MythTV does video playback so there is use of > streams and Xv scaling going on in there I'm pretty sure. The problem > before was that replaying video was taking way more CPU with the DRI > enabled than without. To explore some more I found a couple of really > simple apps that did similar operations (I don't remember the name, but > I think one was called xvtest or something like that. It just displayed > an image (single frame animation?) and used Xv to scale it to the window > size.) Dragging that window around caused a CPU spike. It might have > been all windows but I don't remember. > Ah! try turning off BCIforXv. theoretically using the BCI for image transfers should be faster, but it's always been pretty buggy, plus I think in that particular instance it's using MMIO rather than DMA. > Its entirely possible that I botched up the X install last time around > too. Everything seemed to work okay though. The logs showed DRI being > enabled, but if I remember correctly, getting everything installed took > a couple of tries, it could be that some part of my work messed up the > rest of the X install. > > The last e-mail I sent was 28 FEB 05, so I probably had the shadow > status stuff as I was using CVS at the time. If you check this link: > > http://archive.netbsd.se/?ml=3Ddri-users&a=3D2005-03&t=3D729479 > > You can see what I wrote then and your responses. Not all of it is > making sense to me now as I've forgotten some of what I'd learned about > this stuff and I don't know diddley about how X drivers work or I'd try > to hack this out myself, but I remember at the time, your responses made > sense to me. You mentioned something about DRM not using IRQs and that > being the likely source, but then also mentioned that if the driver used > BCI instead of MMIO it might be faster. At the time you both mentioned > that you had other things you were working on and so wouldn't be doing > anything in this area anytime soon. > > I'll have some time Thursday and Friday to play around with this stuff > again and will be happy to report my progress. Is the users list the > right place? yes. > > Rob > > Felix K=FChling wrote: > > Am Mittwoch, den 30.11.2005, 12:33 -0500 schrieb Alex Deucher: > > > >> On 11/30/05, Robert S. Kerr <rs...@ds...> wrote: > >> > >>> Hello, > >>> > >>> I'm writing to ask about the status of the savage driver and DRI in X= .org. > >>> > >>> I have a Linux machine that I use for MythTV (a homebrew PVR app) > >>> running FC3 with an onboard Prosavage DDR chip in it. > >>> > >>> A while back (FEB '05), I spent the time to get DRI working on my X.o= rg > >>> install. It worked great, but at the time caused other performance > >>> issues when dragging windows that made the benefits of accelerated > >>> openGL not worth it. The issue was that when dragging windows around= on > >>> the screen, or under Myth when I play video, there is a spike in my > >>> Xserver's CPU utilization. Without DRI, Xserver utilization never br= oke > >>> 10% or so. When DRI was enabled, it would jump to as high as 50% > >>> utilization. > >>> > >>> > >> I don't see how the DRI would affect regular 2D performance unless > >> some app you are using uses the drm or GL somehow. > >> > > > > The tiled frame-buffer might have a bad performance impact on direct > > access to the frame buffer. I had the impression that software fallback= s > > were very slow in the Savage and my guess was that the translation from > > linear for tiled memory layout in hardware may be the cause. > > > > Also the Xv implementation is new in current CVS compared to Xorg 6.8. > > It adds smooth scaling (with some caveats) on the Savage 4, ProSavage > > and Twister. It may also have different performance compared to Xorg > > 6.8. > > > > Another thing: I did some work on shadow status in January which might > > have an impact on performance under some circumstances. Robert, I'm not > > sure if your bad experience was before or after those changes. > > > > Regards, > > Felix > > > > > >>> At the time, Felix Kuhling mentioned that the driver was essentially > >>> very inefficient and didn't make use of IRQs or DMA to speed things u= p. > >>> > >>> My question is if this has been resolved in recent work with DRI and > >>> x.org has resolved either of these two issues. I've looked through t= he > >>> archives but haven't seen any direct reference, but I noticed that th= ere > >>> has been a fair amount of savage work in the interim. > >>> > >>> Can anyone provide some insight? > >>> > >>> Also, when I compiled DRI in the past, I had to get the CVS version o= f > >>> X.org, CVS Mesa, and CVS DRM and build all the parts separately. I'v= e > >>> noticed that X.org now includes versions of Mesa and DRM in its tree. > >>> Can I use these to compile DRM for the Savage? > >>> > >>> > >> the drm and mesa were always included in monolithic xorg releases, > >> however, savage DRI support in mesa and drm was not merged in until > >> recently. you can now use either. the version of mesa in xorg cvs is > >> 6.4.x, while cvs mesa and drm as the latest and greatest. > >> > >> Alex > >> > >> > >>> Rob > >>> > >>> > >>> > >>> > >>> > >> ------------------------------------------------------- > >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log= files > >> for problems? Stop! Download the new AJAX search engine that makes > >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK= ! > >> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick > >> -- > >> _______________________________________________ > >> Dri-users mailing list > >> Dri...@li... > >> https://lists.sourceforge.net/lists/listinfo/dri-users > >> > >> > >> > > > > |
From: Robert S. K. <rs...@ds...> - 2005-12-02 16:39:29
|
Well, I had some time last night to look at my issues again. I followed the instructions over on http://dri.freedesktop.org/wiki/Building through building the server, installing it, building libdrm and installing it. I'm using the hosts.def from http://freedesktop.org/~fxkuehl/host.def pretty much as given. I have not yet installed built or installed the 3D drivers or turned on DRI in my config though. Just to see how things were going and perhaps isolate some more, I started up the x server at that point and am experiencing the high x load again. So it would seem that this is something in the 2D driver, or something in the config I'm using. I can get back by moving my old modules back into /usr/X11R6/lib/modules, so I was able to test a bunch of configurations last night. I wasn't able to get my CPU back down to where it is with my stock install though. I'm running FC3 with X.org 6.8.1 installed via RPM. With what I did last night I guess I'd be running CVS X with either CVS X modules, or 6.8.1 modules based on whether I switch back or not. With the old modules, when running a video playback, by checking a TOP my X server hovers between 10-20% CPU, with the mythtv app taking up a similar amount. With the new modules I see 30-50% CPU. I get similar behavior when dragging a window, although its harder to see there because my top display doesn't update during the drag, so I get about 1 frame of the spike in top and then it drops down to a reasonable level. I played around with all the settings in xorg.conf that I could find. Nothing seemed to help, and at least one caused my x server to die or get to a bad place. I tried BCIforXv true and false and it didn't seem to make any real difference. The xorg log did say that it was using MMIO when BCIforXv is TRUE, btw. I tried HWCursor, ShadowFB (caused a crash), BackingStore, and several others (disable XVMC and the other disables) and wasn't able to find a combination that seemed to make any real difference. The other area I explored was the host.def file that I pulled down. I didn't see any obvious culprits in there. I did add some machine based options for the compiler, but that didn't help. The default file has -O3, I left that. Is there anything else about this build that might be different than the stock build from FC3 that could be slowing things down? It looks like all the debugging options are off in that hosts.def file. There was a #define DoLoadableServer YES or something like that just under the section labeled /* Optionally turn these on for debugging */ Commenting that out didn't seem to make a difference. I'm back at this again this evening so perhaps I'll have more tomorrow. Rob |
From: Felix <fx...@gm...> - 2005-12-03 00:17:48
|
Am Freitag, den 02.12.2005, 11:38 -0500 schrieb Robert S. Kerr: > Well, I had some time last night to look at my issues again. I followed=20 > the instructions over on http://dri.freedesktop.org/wiki/Building=20 > through building the server, installing it, building libdrm and=20 > installing it. I'm using the hosts.def from=20 > http://freedesktop.org/~fxkuehl/host.def pretty much as given. I have=20 > not yet installed built or installed the 3D drivers or turned on DRI in=20 > my config though. >=20 > Just to see how things were going and perhaps isolate some more, I=20 > started up the x server at that point and am experiencing the high x=20 > load again. So it would seem that this is something in the 2D driver,=20 > or something in the config I'm using. I can get back by moving my old=20 > modules back into /usr/X11R6/lib/modules, so I was able to test a bunch=20 > of configurations last night. I wasn't able to get my CPU back down to=20 > where it is with my stock install though. That's odd. >=20 > I'm running FC3 with X.org 6.8.1 installed via RPM. With what I did=20 > last night I guess I'd be running CVS X with either CVS X modules, or=20 > 6.8.1 modules based on whether I switch back or not. >=20 > With the old modules, when running a video playback, by checking a TOP=20 > my X server hovers between 10-20% CPU, with the mythtv app taking up a=20 > similar amount. With the new modules I see 30-50% CPU. I get similar=20 > behavior when dragging a window, although its harder to see there=20 > because my top display doesn't update during the drag, so I get about 1=20 > frame of the spike in top and then it drops down to a reasonable level. Which desktop environment / window manager are you using? Top updates fine here with Gnome/Metacity/GnomeTerminal. >=20 > I played around with all the settings in xorg.conf that I could find. =20 > Nothing seemed to help, and at least one caused my x server to die or=20 > get to a bad place. I tried BCIforXv true and false and it didn't seem=20 > to make any real difference. The xorg log did say that it was using=20 > MMIO when BCIforXv is TRUE, btw. I tried HWCursor, ShadowFB (caused a=20 > crash), BackingStore, and several others (disable XVMC and the other=20 > disables) and wasn't able to find a combination that seemed to make any=20 > real difference. Try DisableCOB and ShadowStatus. >=20 > The other area I explored was the host.def file that I pulled down. I=20 > didn't see any obvious culprits in there. I did add some machine based=20 > options for the compiler, but that didn't help. The default file has=20 > -O3, I left that. Is there anything else about this build that might be=20 > different than the stock build from FC3 that could be slowing things=20 > down? It looks like all the debugging options are off in that hosts.def=20 > file. There was a >=20 > #define DoLoadableServer YES I can't think of any important settings for 2D performance in host.def, except maybe compiler options. But I guess most CPU time is spent in busy waiting loops. So we're probably doing something different with the 2D engine. One thing is that the COB (command overflow buffer) was made bigger for better 3D performance. While this should make 2D acceleration more efficient too, it may at the same time lead to more CPU overhead in busy waiting loops. As for Xv, you can't really compare the old and the new implementation. It is expected that smooth scaling takes longer in the hardware. Busy waiting makes this horribly inefficient because it stalls the CPU at the same time. >=20 > or something like that just under the section labeled /* Optionally turn=20 > these on for debugging */ Commenting that out didn't seem to make a=20 > difference. >=20 > I'm back at this again this evening so perhaps I'll have more tomorrow. >=20 > Rob Regards, Felix --=20 | Felix K=C3=BChling <fx...@gm...> http://fxk.de.vu = | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: Alex D. <ale...@gm...> - 2005-12-02 20:45:38
|
On 12/2/05, Felix K=FChling <fx...@gm...> wrote: > Am Freitag, den 02.12.2005, 11:38 -0500 schrieb Robert S. Kerr: > > Well, I had some time last night to look at my issues again. I followe= d > > the instructions over on http://dri.freedesktop.org/wiki/Building > > through building the server, installing it, building libdrm and > > installing it. I'm using the hosts.def from > > http://freedesktop.org/~fxkuehl/host.def pretty much as given. I have > > not yet installed built or installed the 3D drivers or turned on DRI in > > my config though. > > > > Just to see how things were going and perhaps isolate some more, I > > started up the x server at that point and am experiencing the high x > > load again. So it would seem that this is something in the 2D driver, > > or something in the config I'm using. I can get back by moving my old > > modules back into /usr/X11R6/lib/modules, so I was able to test a bunch > > of configurations last night. I wasn't able to get my CPU back down to > > where it is with my stock install though. > > That's odd. > > > > > I'm running FC3 with X.org 6.8.1 installed via RPM. With what I did > > last night I guess I'd be running CVS X with either CVS X modules, or > > 6.8.1 modules based on whether I switch back or not. > > > > With the old modules, when running a video playback, by checking a TOP > > my X server hovers between 10-20% CPU, with the mythtv app taking up a > > similar amount. With the new modules I see 30-50% CPU. I get similar > > behavior when dragging a window, although its harder to see there > > because my top display doesn't update during the drag, so I get about 1 > > frame of the spike in top and then it drops down to a reasonable level. > > Which desktop environment / window manager are you using? Top updates > fine here with Gnome/Metacity/GnomeTerminal. > > > > > I played around with all the settings in xorg.conf that I could find. > > Nothing seemed to help, and at least one caused my x server to die or > > get to a bad place. I tried BCIforXv true and false and it didn't seem > > to make any real difference. The xorg log did say that it was using > > MMIO when BCIforXv is TRUE, btw. I tried HWCursor, ShadowFB (caused a > > crash), BackingStore, and several others (disable XVMC and the other > > disables) and wasn't able to find a combination that seemed to make any > > real difference. > > Try DisableCOB and ShadowStatus. > > > > > The other area I explored was the host.def file that I pulled down. I > > didn't see any obvious culprits in there. I did add some machine based > > options for the compiler, but that didn't help. The default file has > > -O3, I left that. Is there anything else about this build that might b= e > > different than the stock build from FC3 that could be slowing things > > down? It looks like all the debugging options are off in that hosts.de= f > > file. There was a > > > > #define DoLoadableServer YES > > I can't think of any important settings for 2D performance in host.def, > except maybe compiler options. But I guess most CPU time is spent in > busy waiting loops. So we're probably doing something different with the > 2D engine. One thing is that the COB (command overflow buffer) was made > bigger for better 3D performance. While this should make 2D acceleration > more efficient too, it may at the same time lead to more CPU overhead in > busy waiting loops. As for Xv, you can't really compare the old and the > new implementation. It is expected that smooth scaling takes longer in > the hardware. Busy waiting makes this horribly inefficient because it > stalls the CPU at the same time. > you can turn off vertical interpolation with an Xv attribute, XV_VERTICAL_INTERPOLATION, IIRC. Other than that the XV code is pretty much the same. there are only a *limited* number of ways to make the savage overlay work at all and even those are few and far between. FWIW, the savage streams engine is a work of PURE EVIL. Alex > > > > or something like that just under the section labeled /* Optionally tur= n > > these on for debugging */ Commenting that out didn't seem to make a > > difference. > > > > I'm back at this again this evening so perhaps I'll have more tomorrow. > > > > Rob > > Regards, > Felix > > -- > | Felix K=FChling <fx...@gm...> http://fxk.de.vu | > | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | > > |
From: Robert S. K. <rs...@ds...> - 2005-12-05 14:13:46
|
Felix Kühling wrote: >> Just to see how things were going and perhaps isolate some more, I >> started up the x server at that point and am experiencing the high x >> load again. So it would seem that this is something in the 2D driver, >> or something in the config I'm using. I can get back by moving my old >> modules back into /usr/X11R6/lib/modules, so I was able to test a bunch >> of configurations last night. I wasn't able to get my CPU back down to >> where it is with my stock install though. >> > > That's odd. > > Perhaps I didn't explain that well. By replacing the modules folder I can get back to where I started. What I haven't figured out is if I could make the newly compiled CVS version of the server perform as well as my stock version. > Which desktop environment / window manager are you using? Top updates > fine here with Gnome/Metacity/GnomeTerminal. > > I use KDE, but it doesn't really matter to me. MythTV takes over the whole UI and there are many other m;yth users who who use really light WMs like FVWM, or ICE, etc. I'll try another one if I can't make this one work for me. > I can't think of any important settings for 2D performance in host.def, > except maybe compiler options. But I guess most CPU time is spent in > busy waiting loops. So we're probably doing something different with the > 2D engine. One thing is that the COB (command overflow buffer) was made > bigger for better 3D performance. While this should make 2D acceleration > more efficient too, it may at the same time lead to more CPU overhead in > busy waiting loops. As for Xv, you can't really compare the old and the > new implementation. It is expected that smooth scaling takes longer in > the hardware. Busy waiting makes this horribly inefficient because it > stalls the CPU at the same time. > Is there anything that I could do to eliminate/minimize the busy waiting going on? Or even know that is the source of my problems? One of the things that stopped me from looking into this earlier is that I didn't know where/how to start when it comes to debugging a running driver. Stopping and starting the x-server loads of times makes the develop/code/test cycle quite long and hard to follow as you work though an issue. Rob |
From: Alex D. <ale...@gm...> - 2005-12-05 16:20:17
|
On 12/5/05, Robert S. Kerr <rs...@ds...> wrote: > Felix K=FChling wrote: > >> Just to see how things were going and perhaps isolate some more, I > >> started up the x server at that point and am experiencing the high x > >> load again. So it would seem that this is something in the 2D driver, > >> or something in the config I'm using. I can get back by moving my old > >> modules back into /usr/X11R6/lib/modules, so I was able to test a bunc= h > >> of configurations last night. I wasn't able to get my CPU back down t= o > >> where it is with my stock install though. > >> > > > > That's odd. > > > > > Perhaps I didn't explain that well. By replacing the modules folder I > can get back to where I started. What I haven't figured out is if I > could make the newly compiled CVS version of the server perform as well > as my stock version. > > Which desktop environment / window manager are you using? Top updates > > fine here with Gnome/Metacity/GnomeTerminal. > > > > > I use KDE, but it doesn't really matter to me. MythTV takes over the > whole UI and there are many other m;yth users who who use really light > WMs like FVWM, or ICE, etc. I'll try another one if I can't make this > one work for me. > > I can't think of any important settings for 2D performance in host.def, > > except maybe compiler options. But I guess most CPU time is spent in > > busy waiting loops. So we're probably doing something different with th= e > > 2D engine. One thing is that the COB (command overflow buffer) was made > > bigger for better 3D performance. While this should make 2D acceleratio= n > > more efficient too, it may at the same time lead to more CPU overhead i= n > > busy waiting loops. As for Xv, you can't really compare the old and the > > new implementation. It is expected that smooth scaling takes longer in > > the hardware. Busy waiting makes this horribly inefficient because it > > stalls the CPU at the same time. > > > > Is there anything that I could do to eliminate/minimize the busy waiting > going on? Or even know that is the source of my problems? One of the > things that stopped me from looking into this earlier is that I didn't > know where/how to start when it comes to debugging a running driver. > Stopping and starting the x-server loads of times makes the > develop/code/test cycle quite long and hard to follow as you work though > an issue. > if you turn off vertical interpolation, the Xv paths should be pretty much identical. part of the problem may be that the 3D engine uses the BCI in DMA mode while the 2d driver bangs the BCI regs directly via MMIO. perhaps the engine idling between access types would cause this problem? Alex > Rob > |
From: Robert S. K. <rs...@ds...> - 2005-12-08 14:03:28
|
Alex Deucher wrote: > if you turn off vertical interpolation, the Xv paths should be pretty > much identical. part of the problem may be that the 3D engine uses > the BCI in DMA mode while the 2d driver bangs the BCI regs directly > via MMIO. perhaps the engine idling between access types would cause > this problem? > > Alex > > I turned off XV_VERTICAL_INTERPOLATION only to find that it was already off. When I turn it on, the problem gets worse (CPU spikes from ~40% up to as high as 80%. Since I can switch back and forth pretty easily by moving my modules folder from the old files to the new ones and back, I tried mixing them up to see if I could isolate the lib that was causing the issue for me. This was unsuccessful, although I notice that my old server used lib*.a, and the new one uses lib*.so. Could that be part of the issue? Seems like it shouldn't be, but I had to ask. I took a look at the X log files between the two versions and the differences appear minor. The newer savage driver appears to be a bit more chatty about what its doing but nothing seems obviously broken. I could forward that diff if you think there might something in there that could point me in the right direction. Otherwise, my next step is to spend some time with x11perf and see if I can get some more indication of if there is anything about the server itself that could be different between the two instances. Either that or pulling the CVS source for the old version I have working well to see if it something about the way I'm compiling the code itself. Rob |