Announcement

Collapse
No announcement yet.

EXA Acceleration For The Old ATI Rage Driver

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

  • #21
    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?

    Comment


    • #22
      Less then 4k lines

      Comment


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

        Comment


        • #24
          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/

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

          Comment


          • #25
            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?

            Comment


            • #26
              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.
              Test signature

              Comment


              • #27
                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.

                Comment


                • #28
                  Thank you, that was very informative.

                  Comment


                  • #29
                    Indeed, thanks for clearing that up.

                    Comment


                    • #30
                      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.

                      Comment

                      Working...
                      X