Announcement

Collapse
No announcement yet.

Avivo Linux R500 Driver v0.1.0 Coming

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

  • chrisr
    replied
    It depends how much functionality gets reverse-engineered.

    Originally posted by yoshi314 View Post
    i wonder how is ati going to react to this. people are definitely more enthusiastic towards new driver, than they ever were towards fglrx :]
    The current Open Source radeon drivers still don't support things like hardware-accelerated DVD playback (XvMC) even though cards as old as the Radeon 9200 are capable of doing so. And there's TV-OUT support, too. So I don't think ATI are going to be worried for a long, long time.

    Leave a comment:


  • sundown
    replied
    Originally posted by yoshi314 View Post
    i wonder how is ati going to react to this. people are definitely more enthusiastic towards new driver, than they ever were towards fglrx :]

    avivo driver might become serious competition for their fglrx someday (which doesn't seem that hard ;-) ).
    I'd say neither will live up to my expectations.

    Leave a comment:


  • yoshi314
    replied
    i wonder how is ati going to react to this. people are definitely more enthusiastic towards new driver, than they ever were towards fglrx :]

    avivo driver might become serious competition for their fglrx someday (which doesn't seem that hard ;-) ). nvidia decided not to help and not to interfere with nouveau. i wonder what does ati will ati say about avivo once it matures a bit.

    Leave a comment:


  • d2kx
    replied
    chrisr, just hold on a week.

    Leave a comment:


  • chrisr
    replied
    Good news for Fedora 7 users!

    I've just bought a Thinkpad T60p Widescreen laptop with a Mobility FireGL V5250 chip (M56GL, I think), and was very annoyed to discover that the fglrx driver is currently incompatible with Fedora 7. So seeing as I'm stuck using the Vesa driver at ATI/AMDs pleasure, the Avivo driver doesn't have a particularly high hurdle to leap for it to become my new default.

    All Avivo needs to do for me right now is:
    a) Support the native 1680x1050 resolution. The VESA driver is limiting me to 1400x1050, so the screen looks stretched slightly horizontally. Doesn't 1680x1050 count as a "VESA-compatible" mode, or something? The log suggests that DDC is providing the correct mode-lines.
    b) Be as fast as VESA
    c) Not crash ;-)
    d) Provide DPMS support so that the backlight can be powered down.

    I'll probably provide radeondumps just as soon as I get fglrx working too.

    Leave a comment:


  • yoshi314
    replied
    Originally posted by glisse View Post
    In our case its a lot more simple than that from vesa manpage:
    Option "ShadowFB" "boolean" Enable or disable use of the shadow framebuffer layer. Default: on. This option is recommended for performance reasons.

    Basicly there is a copy of the framebuffer in ram and all rendering happen in ram and only part that need to be updated are memcpy to VRAM. As currently there is no acceleration (blitting or filling) used in avivo this help a lot.
    i read it somewhere in irc logs some time ago, and i just couldn't recall that name. so my mind jumped into shadowbuffers, somehow :]

    my bad.

    Leave a comment:


  • glisse
    replied
    Originally posted by yoshi314 View Post
    well it was a closest thing involving shadow in the name.

    shadowbuffering is a method of detecting 3d objects overlapping, but it's too early to implement it in avivo driver.

    i'm not sure how quickly will they figure it out.

    i'll have to review the r300 opensource driver development history, as it was a similar process (a bit rev.engineered, and a bit known (from previous generation specs) )

    well if your card loves to lock up when it receives incorrect commands - figuring it out is not fast. that's what <=r500 cards do, and what r600 (and nvidia) supposedly don't.

    if i were to rev.eng. such a nasty card - i would not make big progress quickly.
    In our case its a lot more simple than that from vesa manpage:
    Option "ShadowFB" "boolean" Enable or disable use of the shadow framebuffer layer. Default: on. This option is recommended for performance reasons.

    Basicly there is a copy of the framebuffer in ram and all rendering happen in ram and only part that need to be updated are memcpy to VRAM. As currently there is no acceleration (blitting or filling) used in avivo this help a lot.

    Leave a comment:


  • d2kx
    replied
    AVIVO now supports nearly all cards (git) and more...

    Leave a comment:


  • Michael
    replied
    Jerome called it "shadow things" so that is what was mentioned in the news posting

    Jerome is quite busy right now with his masters thesis, but he is still getting some good progress done. I have been supplying him a number of dumps, etc.

    Leave a comment:


  • yoshi314
    replied
    well it was a closest thing involving shadow in the name.

    shadowbuffering is a method of detecting 3d objects overlapping, but it's too early to implement it in avivo driver.

    i'm not sure how quickly will they figure it out.

    i'll have to review the r300 opensource driver development history, as it was a similar process (a bit rev.engineered, and a bit known (from previous generation specs) )

    well if your card loves to lock up when it receives incorrect commands - figuring it out is not fast. that's what <=r500 cards do, and what r600 (and nvidia) supposedly don't.

    if i were to rev.eng. such a nasty card - i would not make big progress quickly.
    Last edited by yoshi314; 07-10-2007, 04:08 PM.

    Leave a comment:

Working...
X