Page 2 of 9 FirstFirst 1234 ... LastLast
Results 11 to 20 of 88

Thread: XAA In X.Org Has Finally Met Its Executioner

  1. #11
    Join Date
    Jul 2009
    Posts
    261

    Default

    Quote Originally Posted by curaga View Post
    In other words, any last shreds of acceleration are being removed for any cards in that list. Way to make even more hardware unusable.
    In practical terms, you're not getting acceleration anyway. XaaNoOffscreenPixmaps has been the default since 2008, which means that XAA will only accelerate operations where the only drawable referenced is the screen pixmap. For GTK and Qt, this means nothing ever, since they do all their rendering to an offscreen pixmap first, and then copy that to the screen pixmap. If you're running in a composited environment -- it's all offscreen. So, about the only effect this really has is making xtank and Motif apps in a non-composited environment slower.

  2. #12
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    555

    Default

    Gaah.
    Hopefully someone will notice that besides QXL (that's still being activally developed) cirrus is the default virtualized graphics card in qemu / qemu-kvm.
    I'd hate to move all my non-QXL VM's to vesa because of this...

    - Gilboa
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX680, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  3. #13
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by gilboa View Post
    Gaah.
    Hopefully someone will notice that besides QXL (that's still being activally developed) cirrus is the default virtualized graphics card in qemu / qemu-kvm.
    I'd hate to move all my non-QXL VM's to vesa because of this...

    - Gilboa
    I hope someone will learn how to read.

    Dave.

  4. #14
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    555

    Default

    I assume that I misread something.
    Feel free to explain what I missed (as opposed to mocking my failing intelligence).

    - Gilboa
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX680, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  5. #15
    Join Date
    Jan 2008
    Posts
    772

    Default

    Quote Originally Posted by gilboa View Post
    I assume that I misread something.
    Feel free to explain what I missed (as opposed to mocking my failing intelligence).
    What you missed is that the cirrus driver is not actually being dropped, it will just be temporarily broken in git by the removal of XAA, which wouldn't have accelerated much anyway on any system released in the past ~4 years.

  6. #16
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,991

    Default

    Quote Originally Posted by daniels View Post
    In practical terms, you're not getting acceleration anyway. XaaNoOffscreenPixmaps has been the default since 2008, which means that XAA will only accelerate operations where the only drawable referenced is the screen pixmap. For GTK and Qt, this means nothing ever, since they do all their rendering to an offscreen pixmap first, and then copy that to the screen pixmap. If you're running in a composited environment -- it's all offscreen. So, about the only effect this really has is making xtank and Motif apps in a non-composited environment slower.
    No such system will run a compositing environment. We are talking mostly laptops with integrated neomagic, trident, whatever.

    Operations as basic as moving a window will become slow, no? Oh, and the loved behavior of MS Windows too will appear, where moving a window will peak one core.

  7. #17
    Join Date
    Jan 2008
    Posts
    772

    Default

    Quote Originally Posted by curaga View Post
    No such system will run a compositing environment. We are talking mostly laptops with integrated neomagic, trident, whatever.

    Operations as basic as moving a window will become slow, no? Oh, and the loved behavior of MS Windows too will appear, where moving a window will peak one core.
    I'd be surprised if moving a window isn't already slow on this hardware. When most of it came out, it was still standard practice to only show an outline when moving a window.

  8. #18
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,991

    Default

    MGA should be included in the list. The only driver version supporting EXA is the experimental 1.9, and it works worse than the stable, XAA-using one.

  9. #19
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    555

    Default

    Quote Originally Posted by Ex-Cyber View Post
    What you missed is that the cirrus driver is not actually being dropped, it will just be temporarily broken in git by the removal of XAA, which wouldn't have accelerated much anyway on any system released in the past ~4 years.
    1. Don't be rude. Period.
    2. There's no doubt that cirrus and old, and should be have taken behind the shed and shot; but as long as qxl has yet to reach the same stability (as cirrus), I can only hope the X-devs will take the time to maintain with some-type-of-working-acceleration.

    Are we done?
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX680, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  10. #20
    Join Date
    Jan 2008
    Posts
    297

    Default

    Quote Originally Posted by Veerappan View Post
    Yeah, it's sad... I have an Alpha that I was going to set up with a 3DFX Voodoo3 in the near future. Looks like I'll have to restrict myself to older versions of X.org if I want a working non-VESA driver. That, or I finally have to learn X driver development and figure out how to port the voodoo driver to EXA, and possibly KMS/DRI2...

    Wasn't someone actually working on a KMS driver for 3dfx cards a few years back as part of a documentation GSoC project?
    I did a GSoC project writing a KMS driver for 3DLabs video cards, and James Simmons was working on KMS for 3dfx video cards, so you're combining the two.

Posting Permissions

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