Page 4 of 15 FirstFirst ... 2345614 ... LastLast
Results 31 to 40 of 143

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

  1. #31
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    Hi Kano;

    Is there a real-world use case for switching between fglrx and radeon other than testing ? I understand the desire for fglrx-to-fglrx and radeon-to-radeon (basically "update the driver without rebooting just like Windows") but not sure how to argue for switching between open source and proprietary without reboot.

    If your measurement of "betterness" is "programs the same registers the same way" then presumably a reverse-engineered driver is going to win every time. In fairness though, that's not a common way to determine a "good driver".

    "It works just like fglrx so it must be the best" ?

  2. #32
    Join Date
    Aug 2007
    Posts
    6,626

    Default

    Well in theory it is possible to install fglrx in live mode when you add

    radeon.modeset=0

    and an option to stop X from loading. Then you can install fglrx. But usually thats a bit hard to remember for most people. Use full for example for a games live image which does not require hd install. Why do you think it is needed to do a hd install all the time just for REBOOTING after a driver install, that must be a joke...

  3. #33
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    @Bridgman,
    There is definately a real world use case:
    There are millions of people installing Linux by themselves. Even if they bought a pre-loaded Linux computer, they might want to upgrade to newer versions.

    Ubuntu, for example, doesn't ship with fglrx by default. So what that means is that users first have to reboot after the install, but then install fglrx and then reboot again. After they found out that for example standby isn't working out of the box and so they switch back. Reboot again.

    Then their son wants to play a game. Oops, fglrx again so reboot. But now daddy wants his standby back.

    Stupid use case maybe, but these things do happen =x

  4. #34
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,599

    Default

    Quote Originally Posted by bridgman View Post
    but not sure how to argue for switching between open source and proprietary without reboot
    In good old days this usually resulted in a hardlock because registers values have been changed since boot to something unexpected. Dunno whether that's still an issue. Iirc cold booting was even sometimes necessary to clear them up.

  5. #35
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,599

    Default

    Dammit, edit timeout.
    Still sleepy apparently, didn't notice who that was to.
    Anyway, I recall hearing ages ago that to set the registers to the value on boot you'd need to record the values on boot and restore on module unload. It gave me the impression some of the registers might not have guaranteed generic default values.

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

    Default

    Quote Originally Posted by bridgman View Post
    Precise and Correct is fine.

    Precise and Incorrect, not so much

    If you drop the precision a bit your chances of being correct go up.
    i think the trick is do not try to be right and true is what the people want it to come true.

  7. #37
    Join Date
    Nov 2008
    Posts
    768

    Default

    Quote Originally Posted by bridgman View Post
    http://www.overclock.net/linux-unix/...on-driver.html

    Note the new instructions starting with 2.6.35. There is also a "mid" profile now IIRC.
    thanks.

    "dynpm" didn't seem to do anything. Setting the profile to "low" immediately lowered the fan speed, but fglrx is still more silent.
    I didn't find a method to output current frequencies, though, so my only measurement is fan noise.

    there's a lot of lines during 2d activity (namely xterm):
    Code:
    CS section size missmatch start at (evergreen_accel.c,evergreen_set_default_state,871) 42 vs 45
    CS section end at (evergreen_accel.c,evergreen_set_default_state,912)
    CS section size missmatch start at (evergreen_accel.c,evergreen_set_default_state,981) 45 vs 46
    CS section end at (evergreen_accel.c,evergreen_set_default_state,1023)
    These messages can be silenced by changing the numbers in BEGIN_BATCH in the lines indicated, though I'm not sure if that's a proper fix.

    glxgears works (~2015 fps), but causes gfx corruption, as if parts were rendered to the wrong parts of the framebuffer, visible as horizontal lines.

    Taking a screenshot doesn't quite work. I tried both import and ksnapshot, both result in something like this, which is far more corrupted than what appears onscreen.

    Code:
    ~> neverball
    neverball: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion 'boi->space_accounted' failed.
    Aborted
    ioquake displays it's brown background, then appears to hang.

    startkde3 runs (compositing disabled), but there's corruption at some icons, all window borders and the mouse pointer.

    Watching a movie (xv) worked halfway through, then X crashed. Last lines of xorg.conf:
    Code:
    vs const buffer map failed
    ps const buffer map failed
    ps const buffer map failed
    ps const buffer map failed
    ps const buffer map failed
    ps const buffer map failed
    
    Fatal server error:
    failed to map pixmap -12
    x86_64 smp
    HD 5770
    X Server 1.7.7
    kernel 2.6.35-gentoo-r1
    libdrm-2.4.21
    xf86-video-ati, current evergreen branch
    mesa git from yesterday

    no error messages im dmesg.

  8. #38
    Join Date
    Nov 2008
    Posts
    768

    Default

    /edit

    of course the question of my first post remains: which of those issues are worth turning into proper bug reports, and what additional information is needed to make those useful?

  9. #39
    Join Date
    Aug 2010
    Posts
    10

    Default

    If you open bugs, link them and I'll confirm what I can.

    Quote Originally Posted by rohcQaH View Post
    there's a lot of lines during 2d activity (namely xterm):
    Code:
    CS section size missmatch start at (evergreen_accel.c,evergreen_set_default_state,871) 42 vs 45
    CS section end at (evergreen_accel.c,evergreen_set_default_state,912)
    CS section size missmatch start at (evergreen_accel.c,evergreen_set_default_state,981) 45 vs 46
    CS section end at (evergreen_accel.c,evergreen_set_default_state,1023)
    I can confirm this on my setup.

    Quote Originally Posted by rohcQaH View Post
    glxgears works (~2015 fps), but causes gfx corruption, as if parts were rendered to the wrong parts of the framebuffer, visible as horizontal lines.
    Ditto.

    Quote Originally Posted by rohcQaH View Post
    Watching a movie (xv) worked halfway through, then X crashed. Last lines of xorg.conf:
    Code:
    vs const buffer map failed
    ps const buffer map failed
    ps const buffer map failed
    ps const buffer map failed
    ps const buffer map failed
    ps const buffer map failed
    
    Fatal server error:
    failed to map pixmap -12
    This too. I don't get the buffer map fail messages, but the failure to map pixmap is how X dies after several minutes of use. Mplayer (Xv) or Firefox seem to be surefire ways to kill X within a minute or so, but I've seen this once scrolling in urxvt.

    Core 2 Quad Q8300, Running 64 bit kernel and X.
    Intel G43 Chipset
    Sapphire HD 5770 (0x68B8)
    X Server 1.8.1.902
    kernel 2.6.35.3
    libdrm from this morning's git
    xf86-video-ati from this morning's evergreen_accel branch
    mesa git from this morning

  10. #40
    Join Date
    Nov 2008
    Posts
    768

    Default

    The "CS section size missmatch"-errors are already fixed in latest git. Apparently it WAS enough to just change the numbers.

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
  •