Page 10 of 15 FirstFirst ... 89101112 ... LastLast
Results 91 to 100 of 143

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

  1. #91
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by bridgman View Post
    Hey, I just sit in the big chair and read what they put in front of me

    Thanks go to to agd5f for digging through multiple layers of "the problem seems to be XYZ but that doesn't make sense" investigation to find the underlying problems, monraaf for pointing out the "run fglrx first" workaround (which gave agd5f a starting point), the other folks here who posted about their experiences with the code, and the internal AMD folks (HW and SW teams) who helped agd5f understand what else had changed in the hardware.
    really Awesome... Good job!

  2. #92
    Join Date
    Jun 2009
    Posts
    2,933

    Default

    w00t w00t! Great job!

  3. #93
    Join Date
    Dec 2008
    Posts
    1,002

    Default

    Awesome, no more GPU lockups with that patch. Xv is also working again and it seems the low power profile is enough to render videos at 720p.

  4. #94
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by monraaf View Post
    Awesome, no more GPU lockups with that patch. Xv is also working again and it seems the low power profile is enough to render videos at 720p.
    Time to put my HD5770 back in or not? (and learn doing lego yeah-yeah-yeah )

  5. #95
    Join Date
    Apr 2009
    Posts
    66

    Default

    Excellent stuff! I get no crashes now.

    New summary:
    In KDE, using openGL compositing with RenderAccel disabled, I get almost no corruption at all! Prefectly usable. Though, most of the icons in the taskbar and on the desktop are corrupted.

    E17 still won't start up at all with its compositing module (either with or without RenderAccel).

    Xv is very slow (but works). When displaying a video scaled up to full-screen, there are a lot of blocking-type artefacts that don't seem to be there when displaying at the native size (though I can't be sure) and motion is choppy. But it works, which is a huge step forward.

    glxgears still introduces the horizontal lines (across the background/wallpaper, in my case) mentioned by others. In KDE, dragging windows around sees the frame-rate go pretty low (lower than when software does it) and, as ever, resizing a window takes *forever*. Probably cranks out a new frame every 6-7 seconds or so.

    Some niggles, to be sure, but a huge improvement overall! Thanks to all the devs for their fantastic work.

  6. #96
    Join Date
    Nov 2008
    Posts
    780

    Default

    New summary (compare to my last post):

    2D:
    • xv works again in latest git (-> bug)
    • haven't seen any flaws in 2D operations since applying the patch from this bug. RenderAccel is on and works.

    Will try to use the oss drivers to get some real work done, let's see how that turns out.

    3D, mesa classic:
    • neverball starts now, but some of the colours are slightly wrong. Geometry appears correct.
    • glxgears still overwrites parts of the VRAM it shouldn't touch
    • still got
      Code:
      radeon 0000:02:00.0: forbidden register 0x00009508 at 10
      [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
      same register as reported before, different app this time, more recent kernel (2.6.36-rc3). I'll try to figure out if I can consistently reproduce it and file a bug.
    • haven't tried anything else after the crash


    3D, gallium3d:
    Code:
    ~> glxinfo | grep render
    direct rendering: Yes
    OpenGL renderer string: Gallium 0.4 on EVERGREEN
    • glxgears runs without any kind of corruption, but after a while it stalls with this being spammed through my dmesg a few hundred times:
      Code:
      [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -22!
    • neverball: different problems than r600c: both colours and geometry are correct, but the menu text is invisible. It's seems slower than on r600c. Stalls after a few seconds with the above dmesg-spam.
    • geartrain runs, but it appears that either the viewport isn't set correctly or some transformations failed; only parts of the scene are visible zoomed-in.
    • ioquake3 starts, but glyphs in the menu are broken, textures appear to be missing. Didn't start a game though.


    somewhere along the way my second monitor turned itself off, despite xrandr claiming it was running. Not sure what happened there, but it was fixed by xrandr --output DVI-1 --off; xrandr --output DVI-1 --auto --right-of DVI-0

    I wish there was memory downclocking, because the card runs a bit louder than on fglrx.

  7. #97
    Join Date
    Dec 2007
    Posts
    2,402

    Default

    I just pushed a bunch of evergreen patches to r600c in mesa. They should fix at least some of the issues you are seeing. Also, changing the memory clocks on evergreen works just fine; same as other asics. See this page for more on the pm options:
    http://wiki.x.org/wiki/RadeonFeature

  8. #98
    Join Date
    Nov 2008
    Posts
    780

    Default

    thanks, just updated mesa, let's see..
    • glxgears: I don't see corruption.
    • neverball: colours still wrong -> screenshot. Even though glxgears behaved this time, neverball seemed to corrupt others (see the red stripes in the window border for example)
    • geartrain didn't crash the system, but it took a trip to the 60s: screenshot. Those colours change, synchronized to the turning of the gears (normal- and colour-buffers mixed up or something? Then again, why don't we see non-saturated colors?). Those red stripes weren't visible, they turned up sometime during making and copy/pasting the screenshot around.
    • When I tried to do stuff with geartrain running, X crashed. The backtrace lacks debugging symbols, I'll see if I can fix that. Maybe xorg doesn't like splitdebug? Hmm..
    • kde4: quickly got a segfault similar to the above


    Those red stripe-corruption only appears when 3d apps are running. Using a pure 2d desktop (or using xv) seems to work quite well so far.


    My second screen turning black: happened again, reproducible. Switch to a VT, back to X, second screen is off. As said, a workaround is to re-issue
    xrandr --output DVI-1 --off; xrandr --output DVI-1 --auto --right-of DVI-0
    Now where would I report that bug? kernel/KMS? Xorg? xf86-radeon? Or is it known already?


    Power Management:
    Code:
     ~> echo "low" > /sys/class/drm/card0/device/power_profile
     ~> cat /sys/kernel/debug/dri/0/radeon_pm_info 
    default engine clock: 850000 kHz
    current engine clock: 399990 kHz
    default memory clock: 1200000 kHz
    current memory clock: 1200000 kHz
    voltage: 950 mV
    doesn't look like it's working. I'm using a dual-head system, but even with one monitor switched off (xrandr --output DVI-1 --off), the memory clocks won't go down.

  9. #99
    Join Date
    Dec 2007
    Posts
    2,402

    Default

    Not all power tables specify lower memory clocks (especially on desktop cards and in multi-head power states).

  10. #100
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,544

    Default

    Quote Originally Posted by rohcQaH View Post
    [*]geartrain didn't crash the system, but it took a trip to the 60s: screenshot. Those colours change, synchronized to the turning of the gears (normal- and colour-buffers mixed up or something? Then again, why don't we see non-saturated colors?). Those red stripes weren't visible, they turned up sometime during making and copy/pasting the screenshot around.
    Whoa, that's a funky looking geartrain...

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
  •