Re: GARTSize option not documented on radeon and other problems
Oliver McFadden írta: On 5/3/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Hi, sorry for the crossposting, I don't know who to address. I am experimenting the new CFS scheduler on Linux and tried to start multiple glxgears to see whether they are really running smooth and have evenly distributed framerate. At first I could only start two instances of glxgears but the third didn't start saying that it cannot allocate GART memory and try to increase increase GARTSize. First problem: man radeon doesn't have anything about this option, although radeon_drv.so contains this keyword. I tried guessing whether the parameter is in MBs and have set it to 128 but it disabled DRI because of some out of memory condition. Setting it to 64 gave me working DRI and I am able to start up some more instances of glxgears. Second problem: if I start 16 of them, the last 3 behaves very strange, i.e. instead of the spinning gears I get chaotic flickering triangles. As soon as the number of glxgears goes down to 13 every window behaves normal. Third problem: starting up 32 glxgears locked up the machine almost instantly but having only 16 of them also locks up the machine after some time passed. The machine is x86-64, Athlon64 X2 4200, PCIe Radeon X700 with 128MB onboard memory, up-to-date Fedora Core 6. Best regards, Zoltán Böszörményi This is interesting. I've occasionally seen my engine just display a mess of triangles, but if I was to kill it and start it again, it would work fine. This only happened very occasionally so I could never track down the problem. If running more than 13 glxgears shows the problem then maybe it would have a chance of getting fixed. :) You might want to open a bug report on the Freedesktop Bugzilla. BZ #10852 The lockups are nothing new, unfortionally. I think there is a bug somewhere in the R300 driver. You can also get deadlocks which are a little different... I think that these might go away after R300 uses TTM and thus doesn't grab the hardware lock anymore for texture upload, etc. Is the lockup happens with only multiple GL[X] clients? I can play hours with Diablo 2 :-) in Wine and it doesn't lock up. Best regards, Zoltán Böszörményi - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GARTSize option not documented on radeon and other problems
On 5/4/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Oliver McFadden írta: On 5/3/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Hi, sorry for the crossposting, I don't know who to address. I am experimenting the new CFS scheduler on Linux and tried to start multiple glxgears to see whether they are really running smooth and have evenly distributed framerate. At first I could only start two instances of glxgears but the third didn't start saying that it cannot allocate GART memory and try to increase increase GARTSize. First problem: man radeon doesn't have anything about this option, although radeon_drv.so contains this keyword. I tried guessing whether the parameter is in MBs and have set it to 128 but it disabled DRI because of some out of memory condition. Setting it to 64 gave me working DRI and I am able to start up some more instances of glxgears. Second problem: if I start 16 of them, the last 3 behaves very strange, i.e. instead of the spinning gears I get chaotic flickering triangles. As soon as the number of glxgears goes down to 13 every window behaves normal. Third problem: starting up 32 glxgears locked up the machine almost instantly but having only 16 of them also locks up the machine after some time passed. The machine is x86-64, Athlon64 X2 4200, PCIe Radeon X700 with 128MB onboard memory, up-to-date Fedora Core 6. Best regards, Zoltán Böszörményi This is interesting. I've occasionally seen my engine just display a mess of triangles, but if I was to kill it and start it again, it would work fine. This only happened very occasionally so I could never track down the problem. If running more than 13 glxgears shows the problem then maybe it would have a chance of getting fixed. :) You might want to open a bug report on the Freedesktop Bugzilla. BZ #10852 The lockups are nothing new, unfortionally. I think there is a bug somewhere in the R300 driver. You can also get deadlocks which are a little different... I think that these might go away after R300 uses TTM and thus doesn't grab the hardware lock anymore for texture upload, etc. Is the lockup happens with only multiple GL[X] clients? I can play hours with Diablo 2 :-) in Wine and it doesn't lock up. Best regards, Zoltán Böszörményi We believe lockup happen with high memory traffic (using big texture or sending meg of datas to the card). I believe Diablo isn't especialy such a traffic whore apps. For your test on the cfs scheduler i don't think drm is good to test with. From my understanding i would say that any apps that get the gpu lockup can basicly starve other app for it i.e. we haven't any scheduling or fair sharing of the gpu. This isn't at all easy to solve and i think we kind of don't care if app can DOS gpu. best, Jerome Glisse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GARTSize option not documented on radeon and other problems
Jerome Glisse írta: On 5/4/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Oliver McFadden írta: On 5/3/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Hi, sorry for the crossposting, I don't know who to address. I am experimenting the new CFS scheduler on Linux and tried to start multiple glxgears to see whether they are really running smooth and have evenly distributed framerate. At first I could only start two instances of glxgears but the third didn't start saying that it cannot allocate GART memory and try to increase increase GARTSize. First problem: man radeon doesn't have anything about this option, although radeon_drv.so contains this keyword. I tried guessing whether the parameter is in MBs and have set it to 128 but it disabled DRI because of some out of memory condition. Setting it to 64 gave me working DRI and I am able to start up some more instances of glxgears. Second problem: if I start 16 of them, the last 3 behaves very strange, i.e. instead of the spinning gears I get chaotic flickering triangles. As soon as the number of glxgears goes down to 13 every window behaves normal. Third problem: starting up 32 glxgears locked up the machine almost instantly but having only 16 of them also locks up the machine after some time passed. The machine is x86-64, Athlon64 X2 4200, PCIe Radeon X700 with 128MB onboard memory, up-to-date Fedora Core 6. Best regards, Zoltán Böszörményi This is interesting. I've occasionally seen my engine just display a mess of triangles, but if I was to kill it and start it again, it would work fine. This only happened very occasionally so I could never track down the problem. If running more than 13 glxgears shows the problem then maybe it would have a chance of getting fixed. :) You might want to open a bug report on the Freedesktop Bugzilla. BZ #10852 The lockups are nothing new, unfortionally. I think there is a bug somewhere in the R300 driver. You can also get deadlocks which are a little different... I think that these might go away after R300 uses TTM and thus doesn't grab the hardware lock anymore for texture upload, etc. Is the lockup happens with only multiple GL[X] clients? I can play hours with Diablo 2 :-) in Wine and it doesn't lock up. Best regards, Zoltán Böszörményi We believe lockup happen with high memory traffic (using big texture or sending meg of datas to the card). I believe Diablo isn't especialy such a traffic whore apps. But neither is glxgears. If I have a small number of them, say 2-3, I don't experience any lockup. For your test on the cfs scheduler i don't think drm is good to test with. From my understanding i would say that any But it seems that the mainstream scheduler in Linux cannot keep even small number of GL clients run smoothly under load. My test was to run make -j4 on the kernel source while running 12 glxgears. All 12 gears were smoothly running. And in the meantime, swithing workspaces worked quickly, i.e. repainting the large windows of Firefox and Thunderbird were although not instant but quite quick despite the high load. This kind of load makes the mainstream scheduler stall for several seconds which cannot be observed under Ingo Molnar's new scheduler. apps that get the gpu lockup can basicly starve other app for it i.e. we haven't any scheduling or fair sharing of the gpu. This isn't at all easy to solve and i think we kind of don't care if app can DOS gpu. best, Jerome Glisse The lockup I mentioned wasn't a complete machine lock-up. Although NumLock didn't work and the mouse pointer disappeared from the screen, the machine was still working. I.e. the kernel responded to Alt+SysRq commands (sync, remount-readonly, poweroff) So it must be some software locking problem. Best regards, Zoltán Böszörményi - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GARTSize option not documented on radeon and other problems
On 5/4/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Jerome Glisse írta: On 5/4/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Oliver McFadden írta: On 5/3/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Hi, sorry for the crossposting, I don't know who to address. I am experimenting the new CFS scheduler on Linux and tried to start multiple glxgears to see whether they are really running smooth and have evenly distributed framerate. At first I could only start two instances of glxgears but the third didn't start saying that it cannot allocate GART memory and try to increase increase GARTSize. First problem: man radeon doesn't have anything about this option, although radeon_drv.so contains this keyword. I tried guessing whether the parameter is in MBs and have set it to 128 but it disabled DRI because of some out of memory condition. Setting it to 64 gave me working DRI and I am able to start up some more instances of glxgears. Second problem: if I start 16 of them, the last 3 behaves very strange, i.e. instead of the spinning gears I get chaotic flickering triangles. As soon as the number of glxgears goes down to 13 every window behaves normal. Third problem: starting up 32 glxgears locked up the machine almost instantly but having only 16 of them also locks up the machine after some time passed. The machine is x86-64, Athlon64 X2 4200, PCIe Radeon X700 with 128MB onboard memory, up-to-date Fedora Core 6. Best regards, Zoltán Böszörményi This is interesting. I've occasionally seen my engine just display a mess of triangles, but if I was to kill it and start it again, it would work fine. This only happened very occasionally so I could never track down the problem. If running more than 13 glxgears shows the problem then maybe it would have a chance of getting fixed. :) You might want to open a bug report on the Freedesktop Bugzilla. BZ #10852 The lockups are nothing new, unfortionally. I think there is a bug somewhere in the R300 driver. You can also get deadlocks which are a little different... I think that these might go away after R300 uses TTM and thus doesn't grab the hardware lock anymore for texture upload, etc. Is the lockup happens with only multiple GL[X] clients? I can play hours with Diablo 2 :-) in Wine and it doesn't lock up. Best regards, Zoltán Böszörményi We believe lockup happen with high memory traffic (using big texture or sending meg of datas to the card). I believe Diablo isn't especialy such a traffic whore apps. But neither is glxgears. If I have a small number of them, say 2-3, I don't experience any lockup. For your test on the cfs scheduler i don't think drm is good to test with. From my understanding i would say that any But it seems that the mainstream scheduler in Linux cannot keep even small number of GL clients run smoothly under load. My test was to run make -j4 on the kernel source while running 12 glxgears. All 12 gears were smoothly running. And in the meantime, swithing workspaces worked quickly, i.e. repainting the large windows of Firefox and Thunderbird were although not instant but quite quick despite the high load. This kind of load makes the mainstream scheduler stall for several seconds which cannot be observed under Ingo Molnar's new scheduler. apps that get the gpu lockup can basicly starve other app for it i.e. we haven't any scheduling or fair sharing of the gpu. This isn't at all easy to solve and i think we kind of don't care if app can DOS gpu. best, Jerome Glisse The lockup I mentioned wasn't a complete machine lock-up. Although NumLock didn't work and the mouse pointer disappeared from the screen, the machine was still working. I.e. the kernel responded to Alt+SysRq commands (sync, remount-readonly, poweroff) So it must be some software locking problem. Best regards, Zoltán Böszörményi There was a typo in my mail, i meaned lock not lockup when i was talking about apps sending data to gpu. And if multiple instance of glxgears are successfull to make the gpulockup this is because you are then sending megs of vertex to the card and this has a highmemory bandwith usage which trigger the lockup, at leat i believe lockup happen because of that, sometimes it's only a soft lockup only the gpu die but sometimes the gpu take down with him the pci bus and you got a hard lockup. best, Jerome Glisse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GARTSize option not documented on radeon and other problems
On 5/4/07, Jerome Glisse [EMAIL PROTECTED] wrote: There was a typo in my mail, i meaned lock not lockup when i was talking about apps sending data to gpu. And if multiple instance of glxgears are successfull to make the gpulockup this is because you are then sending megs of vertex to the card and this has a highmemory bandwith usage which trigger the lockup, at leat i believe lockup happen because of that, sometimes it's only a soft lockup only the gpu die but sometimes the gpu take down with him the pci bus and you got a hard lockup. best, Jerome Glisse I'm wondering if this is some timing initialization issue. I might try to check this out with airlied's radeontool. I think this is the current theory as to why it happens. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GARTSize option not documented on radeon and other problems
On 5/3/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Hi, sorry for the crossposting, I don't know who to address. I am experimenting the new CFS scheduler on Linux and tried to start multiple glxgears to see whether they are really running smooth and have evenly distributed framerate. At first I could only start two instances of glxgears but the third didn't start saying that it cannot allocate GART memory and try to increase increase GARTSize. First problem: man radeon doesn't have anything about this option, although radeon_drv.so contains this keyword. I tried guessing whether the parameter is in MBs and have set it to 128 but it disabled DRI because of some out of memory condition. Setting it to 64 gave me working DRI and I am able to start up some more instances of glxgears. Second problem: if I start 16 of them, the last 3 behaves very strange, i.e. instead of the spinning gears I get chaotic flickering triangles. As soon as the number of glxgears goes down to 13 every window behaves normal. Third problem: starting up 32 glxgears locked up the machine almost instantly but having only 16 of them also locks up the machine after some time passed. The machine is x86-64, Athlon64 X2 4200, PCIe Radeon X700 with 128MB onboard memory, up-to-date Fedora Core 6. Best regards, Zoltán Böszörményi This is interesting. I've occasionally seen my engine just display a mess of triangles, but if I was to kill it and start it again, it would work fine. This only happened very occasionally so I could never track down the problem. If running more than 13 glxgears shows the problem then maybe it would have a chance of getting fixed. :) You might want to open a bug report on the Freedesktop Bugzilla. The lockups are nothing new, unfortionally. I think there is a bug somewhere in the R300 driver. You can also get deadlocks which are a little different... I think that these might go away after R300 uses TTM and thus doesn't grab the hardware lock anymore for texture upload, etc. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
