Page 6 of 15 FirstFirst ... 45678 ... LastLast
Results 51 to 60 of 143

Thread: Open-Source 2D, 3D For ATI Radeon HD 5000 Series GPUs

  1. #51
    Join Date
    Sep 2008
    Posts
    989

    Default

    Just changed my xrandr configuration from mirror (both monitors running at 1680x1050) to non-xinerama dual head (24" running at 1920x1200, 22" running at 1680x1050). Works like a charm.

    What the heck is this shadowfb doing providing such smooth 2d accel? It's not allowed to be faster than fglrx! :P

    Now if only I could get DRI2 to work... I guess I need to get the firmware working first, don't I.

  2. #52
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by allquixotic View Post
    What the heck is this shadowfb doing providing such smooth 2d accel? It's not allowed to be faster than fglrx! :P
    Well the point is that shadowfb is doing almost nothing; only blitting and drawing some shit on RAM and then sending it happily to the framebuffer.

    Now if you'd be doing more than just this crap it would be more efficient per time to send it all over tot the graphics card, which takes time, and let the GPU handle all that stuff.

  3. #53
    Join Date
    Sep 2008
    Posts
    989

    Default

    OK, I got the firmware to load. I guess that the firmware got excluded from the built-in kernel somehow, because it was trying to bring up the radeon driver before the ext4 was initialized... I made drm and radeon build as modules, and the firmware loads.

    However, I'm still stuck with the shadowfb, and I see no indication why in terms of the kernel. It would appear that the kernel is operating correctly.

    So then the userspace somehow is acting up. I'll ask on #radeon.

  4. #54
    Join Date
    Jan 2009
    Posts
    86

    Default

    Quote Originally Posted by V!NCENT View Post
    Well the point is that shadowfb is doing almost nothing; only blitting and drawing some shit on RAM and then sending it happily to the framebuffer.

    Now if you'd be doing more than just this crap it would be more efficient per time to send it all over tot the graphics card, which takes time, and let the GPU handle all that stuff.
    Kindof. The CPU has much less latency to system RAM than it does to gfx card RAM - so there's less latency for the CPU to rasterise graphics to main memory than to send the command to the GPU. The GPU can draw much faster once it's recieved the commands..

    Anyway, this means that for small writes(such as drawing an icon) the CPU can probably perform that operation in system RAM in less time than it would take to send that task to the GPU. Large tasks, (drawing large areas, and with complex shaders) the GPU's much higher speed at these tasks will more than compensate.

    In cairo benchmarks, the evergreen_accel gets at best half what my CPU does in shadowfb mode. I expect this will improve a bit once the drivers get beaten on a bit more.

  5. #55
    Join Date
    Sep 2008
    Posts
    989

    Default

    A few things:

    1. I got out of shadowfb mode. Turns out I was being stupid and didn't really have the evergreen_accel branch compiling. I had to rerun autogen.sh to get configure to generate Makefiles that included the evergreen translation units. Grr.

    2. Gnome/compiz compositing crashes when you minimize windows, but Kwin doesn't if you tell it to always keep thumbnails in the control center (it's the option that says "Breaks minimization"). Probably some issue related to evicting EXA pixmaps out of VRAM and into (?) system RAM when they are minimized. IMHO this is unnecessary on cards with as much VRAM as mine (1892 MB); more effort should be made to actually use the VRAM that is available. But that is neither here nor there.

    3. Workaround for corrupt mouse cursor:
    Edit your xorg.conf, under the Driver "radeon" section, and add
    Code:
    Option "RenderAccel" "off"
    This will give you a working mouse cursor, but obviously anything that uses the XRender extension will either be very slow, or won't work. Mouse cursor performance seems unaffected, as it's still using a hardware cursor.

    So now I've got EXA and a compositing manager that is relatively stable on top of a HD5970. I'd still like to see the driver stabilize, but the basic tech is visibly starting to work.

  6. #56
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by allquixotic View Post
    Just changed my xrandr configuration from mirror (both monitors running at 1680x1050) to non-xinerama dual head (24" running at 1920x1200, 22" running at 1680x1050). Works like a charm.

    What the heck is this shadowfb doing providing such smooth 2d accel? It's not allowed to be faster than fglrx! :P

    Now if only I could get DRI2 to work... I guess I need to get the firmware working first, don't I.

    "It's not allowed to be faster than fglrx! :P"

    sure shadowFB it is faster than the fglrx ;-)

    Exempel: my last try to install a 10-8 catalyst:

    Package build failed!
    Package build utility output:
    ./packages/Ubuntu/ati-packager.sh: 385: dpkg-buildpackage: not found
    [Error] Generate Package - error generating package : Ubuntu/lucid

  7. #57
    Join Date
    Nov 2008
    Posts
    781

    Default

    I've done some more detailed test in addition to my last post.

    radeon, today's git:
    mesa reverted to 7.8.2, export LIBGL_ALWAYS_SOFTWARE=1
    • glxgears works without corruption
    • xv doesn't work at all, there's nothing but slight colourful flickering in the whole window
    • screenshots I take (both ksnapshot and import -window root file.png) are still corrupted (see last post for an example)
    • kde3 still has the same corruption as before, it's not related to mesa (kde3 doesn't use opengl much, anyway)


    same as before, but added to my xorg.conf: Option "RenderAccel" "off":
    • no changes with glxgears and xv
    • screenshots I take with import are still corrupted, ksnapshot started to work though.
    • corruption in kde3 is gone, even with composition (it's not opengl-based, anyway)
    • more extensive tests revealed corruption in Seamonkey, but not in firefox or other GTK-apps I tested
    • flash (firefox) worked right until I clicked the "fullscreen" button, let's blame flash for that


    If I had to take a wild guess, reading from the framebuffer is broken in some way. Not just because of the screenshots, but also because most pseudo-transparency effects (yakuake, crystal window decorations) are corrupted.
    On the other hand, compositing and true transparency effect work fine, so vram->vram blits appear to work.
    The mouse pointer and some icons are displayed wrong, too. The corruption looks similar to the screenshot/transparency bugs, so it may or may not have the same root cause.


    xv worked fine last week (until x crashed), should I try to bisect?

    reinstalled mesa master (today), enabled hardware 3d.
    • xv still broken
    • glxgears still messes with parts of the video memory it shouldn't mess with, resulting in corruption in the form of horizontal lines (not neccessarily in the framebuffer, but this time in my wallpaper's pixmap).
      With RenderAccel off, glxgears appeared to work fine, save for some horizontal red lines that appeared in glxgear's window from time to time.
    • neverball still doesn't start with r600 (as mentioned in my last post)
    • kde 4.5: seems to work fine with compositing disabled, had corruption with XRender compositing (even with RenderAccel off), kwin4 crashes immediately when opengl compositing is active, each time this appears in dmesg:
      Code:
      [ 3877.649234] radeon 0000:02:00.0: forbidden register 0x00009508 at 10
      [ 3877.649237] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !


    in other words, as far as I'm concerned, r600's status is "glxgears barely works" :/

  8. #58
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote Originally Posted by rohcQaH View Post
    I've done some more detailed test in addition to my last post.

    radeon, today's git:
    mesa reverted to 7.8.2, export LIBGL_ALWAYS_SOFTWARE=1
    • glxgears works without corruption
    • xv doesn't work at all, there's nothing but slight colourful flickering in the whole window
    • screenshots I take (both ksnapshot and import -window root file.png) are still corrupted (see last post for an example)
    • kde3 still has the same corruption as before, it's not related to mesa (kde3 doesn't use opengl much, anyway)


    same as before, but added to my xorg.conf: Option "RenderAccel" "off":
    • no changes with glxgears and xv
    • screenshots I take with import are still corrupted, ksnapshot started to work though.
    • corruption in kde3 is gone, even with composition (it's not opengl-based, anyway)
    • more extensive tests revealed corruption in Seamonkey, but not in firefox or other GTK-apps I tested
    • flash (firefox) worked right until I clicked the "fullscreen" button, let's blame flash for that


    If I had to take a wild guess, reading from the framebuffer is broken in some way. Not just because of the screenshots, but also because most pseudo-transparency effects (yakuake, crystal window decorations) are corrupted.
    On the other hand, compositing and true transparency effect work fine, so vram->vram blits appear to work.
    The mouse pointer and some icons are displayed wrong, too. The corruption looks similar to the screenshot/transparency bugs, so it may or may not have the same root cause.


    xv worked fine last week (until x crashed), should I try to bisect?

    reinstalled mesa master (today), enabled hardware 3d.
    • xv still broken
    • glxgears still messes with parts of the video memory it shouldn't mess with, resulting in corruption in the form of horizontal lines (not neccessarily in the framebuffer, but this time in my wallpaper's pixmap).
      With RenderAccel off, glxgears appeared to work fine, save for some horizontal red lines that appeared in glxgear's window from time to time.
    • neverball still doesn't start with r600 (as mentioned in my last post)
    • kde 4.5: seems to work fine with compositing disabled, had corruption with XRender compositing (even with RenderAccel off), kwin4 crashes immediately when opengl compositing is active, each time this appears in dmesg:
      Code:
      [ 3877.649234] radeon 0000:02:00.0: forbidden register 0x00009508 at 10
      [ 3877.649237] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !


    in other words, as far as I'm concerned, r600's status is "glxgears barely works" :/
    It needs a lot of work still. I may be seeing bugs in unrelated components like the kernel or the X server, but I can't even get the driver to load up DRI2 today. It just falls back to software without any explanation as to why.

  9. #59
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,758

    Default

    Very much sounds like your kernel and Mesa aren't compatible with each other. "forbidden register" is a good hint of this. There's security functionality in kernel DRM, afaik mostly written by glisse, that causes that kind of stuff to be outputted. If the register should be usable, updating kernel might fix it. If not, updating Mesa might fix it. But since you don't know, could as well update both.

  10. #60
    Join Date
    Nov 2008
    Posts
    781

    Default

    I was using the latest mesa git and the latest stable kernel (2.6.35). It's supposed to work with .35, so I don't want to risk further trouble by using a .36-RC-kernel.

    Besides, the trouble in 2d-land certainly isn't related to mesa.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •