GARTSize option not documented on radeon and other problems

Jerome Glisse j.glisse at gmail.com
Fri May 4 00:49:49 PDT 2007


On 5/4/07, Zoltan Boszormenyi <zboszor at dunaweb.hu> wrote:
> Oliver McFadden írta:
> > On 5/3/07, Zoltan Boszormenyi <zboszor at dunaweb.hu> 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



More information about the xorg mailing list