Announcement

Collapse
No announcement yet.

EXA Acceleration For The Old ATI Rage Driver

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

  • #16
    Fold into radeon driver

    What should have happened was to fold the r128 driver into the radeon driver, bringing a whole bunch of benefits at once. Alex Deucher had a whole tree dedicated to this, which to my knowledge was permanently lost after a freedesktop.org hosting failure Did anybody copy or backup that code?

    Comment


    • #17
      I have few old machines (Alpha architecture, Compaq Alphastation XP1000 to be precise) which uses Parmedia 2 chipset (Texas Instruments TVP4020), and I think this card was called ELSA Gloria. They use glint Xorg driver (with XAA acceleration). I would love to port it to EXA, but unfortunetly glint driver is very big, because it supports lots of chipsets designed by 3dlabs. Is there anybody already porting glint to EXA?

      Comment


      • #18
        Originally posted by stan View Post
        What should have happened was to fold the r128 driver into the radeon driver, bringing a whole bunch of benefits at once. Alex Deucher had a whole tree dedicated to this, which to my knowledge was permanently lost after a freedesktop.org hosting failure Did anybody copy or backup that code?
        I still had a local copy.
        http://cgit.freedesktop.org/~agd5f/x...h=r128-support

        Comment


        • #19
          Originally posted by baryluk View Post
          I have few old machines (Alpha architecture, Compaq Alphastation XP1000 to be precise) which uses Parmedia 2 chipset (Texas Instruments TVP4020), and I think this card was called ELSA Gloria. They use glint Xorg driver (with XAA acceleration). I would love to port it to EXA, but unfortunetly glint driver is very big, because it supports lots of chipsets designed by 3dlabs. Is there anybody already porting glint to EXA?
          The performance will most likely be better with shadowfb than EXA. The 3D capabilities of those cards were pretty limited. The reason XAA is pretty fast is because it's mostly software rendering because it does not provide hooks to accelerate anything modern (no ping-ponging between sw and hw).

          Comment


          • #20
            Originally posted by baryluk View Post
            I have few old machines (Alpha architecture, Compaq Alphastation XP1000 to be precise) which uses Parmedia 2 chipset (Texas Instruments TVP4020), and I think this card was called ELSA Gloria. They use glint Xorg driver (with XAA acceleration). I would love to port it to EXA, but unfortunetly glint driver is very big, because it supports lots of chipsets designed by 3dlabs. Is there anybody already porting glint to EXA?
            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.

            Comment


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

                        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