Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • allquixotic
    replied
    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.

    Leave a comment:


  • rohcQaH
    replied
    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" :/

    Leave a comment:


  • allquixotic
    replied
    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.

    Leave a comment:


  • DuSTman
    replied
    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.

    Leave a comment:


  • allquixotic
    replied
    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.

    Leave a comment:


  • V!NCENT
    replied
    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.

    Leave a comment:


  • allquixotic
    replied
    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.

    Leave a comment:


  • allquixotic
    replied
    Using today's git master of all Xorg libs, protos, server, mesa drm, and mesa/mesa. Linux 2.6.36-rc2-git3. Have a HD5970. Fully preemptible 1000 Hz. drm and radeon modules built-in to kernel.

    Boot-up takes an extremely long time to switch to the KMS framebuffer. On the dmesg I see:

    Code:
    [   62.288248] r600_cp: Failed to load firmware "radeon/CYPRESS_pfp.bin"
    [   62.288309] [drm:evergreen_startup] *ERROR* Failed to load firmware!
    [  123.205570] r600_cp: Failed to load firmware "radeon/CYPRESS_pfp.bin"
    [  123.205611] [drm:evergreen_startup] *ERROR* Failed to load firmware!
    [  123.205645] radeon 0000:05:00.0: disabling GPU acceleration
    [  123.206744] radeon 0000:05:00.0: ffff8801b653b400 unpin not necessary
    [  123.206769] radeon 0000:05:00.0: ffff8801b653b400 unpin not necessary
    [  123.206799] failed to evaluate ATIF got AE_BAD_PARAMETER
    Later on, in Xorg.0.log, I see

    Code:
    [   464.362] (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS
    [   464.362] (II) Loading sub module "shadow"
    [   464.362] (II) LoadModule: "shadow"
    [   464.362] (II) Loading /usr/lib64/xorg/modules/libshadow.so
    [   464.368] (II) Module shadow: vendor="X.Org Foundation"
    [   464.545] (II) RADEON(1): GPU accel disabled or not working, using shadowfb for KMS
    [   464.545] (II) Loading sub module "shadow"
    [   464.545] (II) LoadModule: "shadow"
    [   464.546] (II) Reloading /usr/lib64/xorg/modules/libshadow.so
    I've therefore got no 3d accel, but 2d accel is nice and stable, and actually quite fast, even with the core set to its minimum clock frequency using the power management profiles. Verified:

    Code:
    # cat /sys/kernel/debug/dri/0/radeon_pm_info
    default engine clock: 725000 kHz
    current engine clock: 399990 kHz
    default memory clock: 1000000 kHz
    current memory clock: 1000000 kHz
    voltage: 1000 mV
    I've got both DVI outputs plugged into an LCD; could this be related to using dual monitors?

    FWIW, the firmware seemed to have worked with 2.6.35.3, but I was still stuck in software rendering. I had a lot of different variables there though, such as building drm and radeon as modules.

    Right now I'm going on 45 minutes running X without a crash, but since it's a shadowfb on top of KMS, this isn't very surprising; developers have presumably been testing this configuration for months while 2d/3d support was in the works.

    And yes I'm using evergreen_accel. No xorg.conf.

    Leave a comment:


  • nanonyme
    replied
    Probably local alias for checkout. Used for changing active branch in git.

    Leave a comment:


  • psychok9
    replied
    Originally posted by rohcQaH View Post
    git co evergreen_accel
    Code:
    /xf86-video-ati$ git co evergreen_accel
    git: 'co' is not a git command. See 'git --help'.
    What do you mean with "co"?

    Leave a comment:

Working...
X