On Tue, Jan 18, 2011 at 1:57 AM, Mark Knecht <markkne...@gmail.com> wrote:
> On Mon, Jan 17, 2011 at 2:31 PM, Daniel Tihelka <dtihe...@gmail.com>
> wrote:
> > Hallo Mick.
> > Thank you very much - it helped. Removing 'video=vesafb:ywrap,mtrr:3
> > vga=792'
> > from kernel boot options, and framebuffer-related stuff in kernel config,
> > especially:
> >
> > # CONFIG_FB_DDC is not set
> > # CONFIG_FB_BOOT_VESA_SUPPORT is not set
> > # CONFIG_FB_BACKLIGHT is not set
> > # CONFIG_FB_MODE_HELPERS is not set
> > # CONFIG_FB_TILEBLITTING is not set
> > # CONFIG_FB_VESA is not set
> > # CONFIG_FB_RADEON is not set
> > # CONFIG_DISPLAY_SUPPORT is not set
> > # CONFIG_VGACON_SOFT_SCROLLBACK is not set
> > # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
> >
> > (not all the options were removed by hand, it is just diff of the
> configs,
> > and
> > maybe, some of them could be enabled without causing problems).
> >
> > Now, there are much more 'drm'-related messages in 'dmesg', and also
> X.org
> > uses the drm correctly. The 'glxinfo' returns:
> > ...
> > OpenGL vendor string: X.Org R300 Project
> > OpenGL renderer string: Gallium 0.4 on RV370
> > OpenGL version string: 2.1 Mesa 7.9
> > OpenGL shading language version string: 1.20
> > ...
> >
> > It looks good now. Thank you very much for your advice again.
> > Dan
> >
> > On Sunday 16 January 2011 16:52:30 Mick wrote:
> >> On Sunday 16 January 2011 15:18:50 Daniel Tihelka wrote:
> >> > And the kernel seems to use them (when started with boot options
> >>
> >> > 'video=vesafb:ywrap,mtrr:3 vga=792'):
> >> Dan, try removing uvesa/vesa/radeon/etc. framebuffer modules from your
> >> kernel and the above line too from grub when you boot and see if your
> KMS
> >> radeon driver can now work on its own.
> >
>
> Daniel,
> I'm seeing the same problem here and trying to follow my way
> through your kernel config changes. I don't think I have it yet on
> this box as I'm seeing a message about rendering being disabled in
> Xorg.log.0
>
> c2stable ~ # cat /var/log/Xorg.0.log | grep render
> [ 29.017] (WW) RADEON(0): Direct rendering disabled
> c2stable ~ #
>
> even though glxinfo says it's enabled:
>
> c2stable ~ # glxinfo | grep render
> direct rendering: Yes
> OpenGL renderer string: Gallium 0.4 on softpipe
> GL_NV_blend_square, GL_NV_conditional_render, GL_NV_light_max_exponent,
> c2stable ~ #
>
> I have the following now:
$cat /var/log/Xorg.0.log | grep render
[ 28.531] (II) RADEON(0): Direct rendering enabled
$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on RV370
GL_NV_blend_square, GL_NV_conditional_render, GL_NV_light_max_exponent,
The key issue was to exclude "classic" framebuffer drivers from the kernel.
Since that, everything started to work automatically.
> Anyway, I'm sure I'll figure it out but I'm curious how you measure
> that it's working up to it's potential. I'm getting less than 200FPS
> in glxgears. I get >2500 on a cheaper nvidia card so I'm certain this
> Radeon 300 can do better.
>
> What do you see in glxgears?
>
> I see this:
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
273 frames in 5.0 seconds = 54.532 FPS
299 frames in 5.0 seconds = 59.634 FPS
301 frames in 5.0 seconds = 60.037 FPS
288 frames in 5.1 seconds = 56.852 FPS
212 frames in 5.0 seconds = 42.366 FPS <-- window maximized from here
222 frames in 5.0 seconds = 44.352 FPS
216 frames in 5.0 seconds = 43.021 FPS
205 frames in 5.0 seconds = 40.716 FPS
It is not so much and I don't know if it is the top performance of the
gallium driver (btw, I really believe it has large potential), or if it
could be improved further more (e.g. by compilling lvm into it), but it is
not critical for me now.
Dan
