Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 32

Thread: EXA Acceleration For The Old ATI Rage Driver

  1. #21
    Join Date
    Jul 2010
    Posts
    69

    Default

    Quote Originally Posted by mattst88 View Post
    No. It's really better worth your time to buy a PCI Radeon instead of using a Permedia 2. You can even get a PCI Radeon HD 5450.

    If for some reason someone actually cared significantly about glint, they should probably start with a KMS driver.

    Yes, I know i can find easly PCI cards with better performance and support, just wondering what I can do with this cards. It could be some motivation digg deeper into kernel and xorg code. How much more work needs your KMS code to be operational on at least one card?

  2. #22
    Join Date
    Sep 2011
    Posts
    688

    Default

    Less then 4k lines

  3. #23
    Join Date
    Sep 2011
    Posts
    688

    Default

    Is there a reason we don't have KMS for VESA?

  4. #24
    Join Date
    Jan 2008
    Posts
    299

    Default

    Quote Originally Posted by baryluk View Post
    Yes, I know i can find easly PCI cards with better performance and support, just wondering what I can do with this cards. It could be some motivation digg deeper into kernel and xorg code. How much more work needs your KMS code to be operational on at least one card?
    It's already functional on at least one card. When I finished the project, I had a working framebuffer on a Permedia 3.

    The next things to do (I had a TODO list somewhere. Can't find it now) are
    - i2c/ddc (currently the driver is hard coded to a 1024x768 resolution)
    - TTM (only has enough TTM support to allocate the framebuffer)
    - support for Permedia 2, 2V, and 4 cards
    - update xf86-video-glint to work with KMS

    There were some other things on the TODO list, but I can't remember them.

    All the docs I have for Permedia cards are here: http://mattst88.com/permedia/

    Quote Originally Posted by AJenbo View Post
    Is there a reason we don't have KMS for VESA?
    Because that doesn't make any sense.

  5. #25
    Join Date
    Jun 2006
    Location
    Portugal
    Posts
    527

    Default

    Quote Originally Posted by mattst88 View Post
    Originally Posted by AJenbo View Post
    Is there a reason we don't have KMS for VESA?

    Because that doesn't make any sense.
    Could you expand a little on that? I'm curious too. For older cards, you end up running vesa on the kernel, and vesa/fbdev on Xorg, but they normally will have different resolutions and tty switching will be slow, and you don't get kernel panics visible, etc.
    Wouldn't getting KMS for VESA solve this?

  6. #26
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    I thought the issue with KMS VESA was that it would require running video bios code (real mode x86) in the kernel, which is problematic at best and probably forbidden. Presumably the code could be run on a sandboxed x86 emulator, but not sure if that would be enough to give an acceptable level of robustness.

  7. #27
    Join Date
    Dec 2007
    Posts
    2,371

    Default

    vesa requires real mode bios calls to set modes (plus you are limited to the vesa mode numbers exposed by the bios which do not always match a monitor's native mode) which is not allowed in the kernel. We already have uvesafb which is a vesa kernel fb driver and it has to call into userspace helpers to set modes so it starts to turn into a mess. With native drivers for most hardware already, it doesn't really gain you much for the amount of work required. Plus vesa/vbe goes away with EFI (real mode vbe calls are not allowed with secure boot), replaced by a native EFI GOP driver. There is already an efifb kernel fb driver for the EFI framebuffers, and native drivers for most modern hardware. A KMS driver for GOP is not really an option because once the OS loads, the GOP driver is gone and you can't change the video mode so you are stuck with what the GOP driver set until you load a native driver.

  8. #28
    Join Date
    Sep 2011
    Posts
    688

    Default

    Thank you, that was very informative.

  9. #29
    Join Date
    Jun 2006
    Location
    Portugal
    Posts
    527

    Default

    Indeed, thanks for clearing that up.

  10. #30
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    874

    Default

    Quote Originally Posted by mattst88 View Post
    R100 and R200 support wasn't dropped. These drivers are "classic" drivers, but they're DRI*2*. It was the DRI1 drivers (all of which happened to be "classic" that were dropped.)

    Yes. R300g and R600g work on Alpha.

    3DFX cards are not Gallium-compatible. Gallium assumes that the card has programmable shaders, which Voodoos don't have.

    If you're interested in Alphas, join #alpha and #gentoo-alpha on Freenode. I'm always there and I'm a Gentoo/Alpha developer. I would set my title to Gentoo Developer (instead of "Senior Member") or something, but I don't know how.
    Yeah, don't ask me why I stated that r100-r200 was dropped from Mesa. I was wrong, and admitting that hurts a little

    I am mostly hoping that someone (possibly me if I'm feeling adventurous) can update the 3dfx mesa/kernel drivers to DRI2/kms so that the cards can at least continue to be used with their existing capabilities.

    I was asking about Gallium+Alpha partially because I could drop a PCI GeForce 8400 or higher (or the radeon equivalent) in that machine if I was feeling like actually extending the life of that machine. At the moment, my PCI stockpile just consists of Trident, Matrox Millenium, and 3dfx Voodoo 3's, but I've got a GF8400 GS in a HTPC I'm building for my brother-in-law that I could test with for the next few weeks.

Posting Permissions

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