Announcement

Collapse
No announcement yet.

Limited ATI support?

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

  • #31
    Originally posted by archibald View Post
    You can use ATI cards in BSD - they all come with the open source classic driver.

    They don't meet all the requirements for the latest (Gallium3D) drivers, but they're perfectly usable with the classic drivers (obviously depending on what you actually want to do with them).
    That's not exactly 100% accurate. You can only use the 'classic' (FOSS?) drivers and ONLY up until the HD Radeon 4xxx series/generation of cards. So Radeon R700.

    If what I read is still applicable today, if you install BSD w/ an Evergreen or North Islands card, you can only use VESA (graphics).

    Comment


    • #32
      Originally posted by darkbasic View Post
      Only <= Evergreen cards.
      April: four/five months ago?



      Go to PC-BSD or FreeBSD forums, fairly recent posts have people asking how to get their Evergreen card to work.... Answer is you have to use VESA for now.

      Edit: I notice that 2D is alleged to work. But, who wants a card with no 3D?
      Last edited by Panix; 24 September 2011, 12:53 PM.

      Comment


      • #33
        I'm pretty sure some BSD guys started porting the kernel infrastructure for Gallium3d. This is not a simple task, considering that Gallium3d is a moving target, but it should help reduce the support gap.

        That said, drivers don't write themselves. Unless enough manpower can be gathered to work on drivers (paid or volunteers), then the driver situation will remain dire.

        Linux (the kernel) has managed to attract commercial and non-commercial developers in a way that BSDs haven't. It would be interesting to investigate the reasons behind this difference.

        Comment


        • #34
          Originally posted by BlackStar View Post
          I'm pretty sure some BSD guys started porting the kernel infrastructure for Gallium3d. This is not a simple task, considering that Gallium3d is a moving target, but it should help reduce the support gap.

          That said, drivers don't write themselves. Unless enough manpower can be gathered to work on drivers (paid or volunteers), then the driver situation will remain dire.

          Linux (the kernel) has managed to attract commercial and non-commercial developers in a way that BSDs haven't. It would be interesting to investigate the reasons behind this difference.
          Gallium itself has nothing to do with the kernel infrastructure. The kernel infrastructure for a gallium radeon driver and a gallium nouveau driver are completely different. You can write a classic driver that requires all the new kernel interfaces. Saying gallium has anything to do with it is really just wrong.

          The kernel interfaces required haven't really moved in 2-3 years for radeon, the kernel is ABI stable so its not like there is major churn on that interface.

          Dave.

          Comment


          • #35
            Originally posted by airlied View Post
            I'm pretty sure some BSD guys started porting the kernel infrastructure for Gallium3d. This is not a simple task, considering that Gallium3d is a moving target, but it should help reduce the support gap.
            Gallium itself has nothing to do with the kernel infrastructure. The kernel infrastructure for a gallium radeon driver and a gallium nouveau driver are completely different. You can write a classic driver that requires all the new kernel interfaces. Saying gallium has anything to do with it is really just wrong.

            The kernel interfaces required haven't really moved in 2-3 years for radeon, the kernel is ABI stable so its not like there is major churn on that interface.

            Dave.
            You are saying that you need to port the kernel infrastructure in order to use Gallium3d nouveau/radeon on BSD. I am saying... the same thing? I'm not sure where your disagreement lies.

            Just to make this clear, what would one need to do in order to run R600g on BSD?

            (My understanding was that you'd need to write/port a kernel driver that exposes the ABI expected by Gallium3d. If you wanted to add a new feature, like e.g. tesselation shaders, you'd have to update both Gallium3d and all relevant kernel drivers - no?)
            Last edited by BlackStar; 25 September 2011, 10:55 AM.

            Comment


            • #36
              Originally posted by BlackStar View Post
              You are saying that you need to port the kernel infrastructure in order to use Gallium3d nouveau/radeon on BSD. I am saying... the same thing? I'm not sure where your disagreement lies.

              Just to make this clear, what would one need to do in order to run R600g on BSD?

              (My understanding was that you'd need to write/port a kernel driver that exposes the ABI expected by Gallium3d. If you wanted to add a new feature, like e.g. tesselation shaders, you'd have to update both Gallium3d and all relevant kernel drivers - no?)

              Gallium3d isn't a generic thing. Its just a bunch of driver internals API inside the mesa driver. The problem with your statements are they are very unspecific and misleading.

              To get r600g working on BSD the kernel needs to expose the radeon DRM interfaces necessary for r600g, i.e. the radeon GEM API.

              To get nouveau working on BSD the kernel needs to expose the nouveau DRM interfaces necessary for nouveau, i.e. the nouveau GEM API.

              Gallium is only an abstraction layer. To add new features for new GL things, you have to update the gallium abstraction layer, the Mesa state tracker that talks to it, and then the individual drivers for each hw component. If one of the individual driver components (r600g, nouveau) needs a new kernel interface to expose a feature, then you need to add a new kernel API, not every feature will need a new API exposed, and every hw driver is different.

              Dave.

              Comment


              • #37
                Originally posted by airlied View Post
                Gallium3d isn't a generic thing. Its just a bunch of driver internals API inside the mesa driver.
                To a driver developer, maybe; to the rest of teh world, not really. Everyone (beside you) is speaking about "Gallium3d drivers" not "Gallium3d internals API inside the Mesa driver".

                The problem with your statements are they are very unspecific and misleading.
                I stated exactly four things:
                (a) "some BSD developers have started porting the necessary kernel infrastructure"
                (b) "this requires manpower"
                (c) "Gallium3d is a moving target"
                (d) "BSD support for modern 3d is worse than Linux"

                To get r600g working on BSD the kernel needs to expose the radeon DRM interfaces necessary for r600g, i.e. the radeon GEM API.

                To get nouveau working on BSD the kernel needs to expose the nouveau DRM interfaces necessary for nouveau, i.e. the nouveau GEM API.
                You confirm that (a) is necessary and I recall Phoronix reporting on this work a few months ago.

                Gallium is only an abstraction layer. To add new features for new GL things, you have to update the gallium abstraction layer, the Mesa state tracker that talks to it, and then the individual drivers for each hw component. If one of the individual driver components (r600g, nouveau) needs a new kernel interface to expose a feature, then you need to add a new kernel API, not every feature will need a new API exposed, and every hw driver is different.
                You confirm that (c) is a fact. (New features may entail changes to Gallium3d, the kernel drivers and the state tracker).

                (b) and (d) are conjectures based on evidence.

                This is getting silly.
                Last edited by BlackStar; 25 September 2011, 11:56 AM.

                Comment


                • #38
                  Companies invest in what will give the best return on their money. Unless there is some incentive (major market, lucrative contract, good PR, etc.) to port your driver to another OS, it's a lot of effort with little return. Linux barely has enough desktop market share to make it worthwhile, *BSDs have even less. The open source drivers are X11 licensed so any OS can pick them up and port them if you are willing to put in the effort. Where do you draw the line? *BSDs? BeOS? Joe's custom OS? Karen's OS?

                  The main reason the *BSDs had support in the past is because the old DRI infrastructure was so limited it was relatively easy to port (limited hard coded vram and dma allocations); as it evolved into a modern gfx stack with KMS, the bar got much higher. Unfortunately, that old limited interface was barely adequate 10 years ago. It's nearly impossible to support new asics with the old DRI stack which is why we only support them with KMS.

                  Comment


                  • #39
                    Originally posted by Panix View Post
                    I notice that 2D is alleged to work. But, who wants a card with no 3D?
                    People setting up a server where the display will ultimately be a putty terminal. Which, coincidently, is the best interface for Linux as well.

                    Comment


                    • #40
                      Originally posted by agd5f View Post
                      Linux barely has enough desktop market share to make it worthwhile, *BSDs have even less.
                      I think you are very wrong ! There is a huge ever-growing-amount of linux users, and the same, maybe not as-big-as-linux-but-huge-nevertheless, for bsd.

                      Originally posted by agd5f View Post
                      Where do you draw the line?
                      Exactly where Nvidia draws their line too, support for (free)bsd.


                      obviously at this point bsd users are better-off with a nvidia card,
                      but im hoping you will use your ability to change this.

                      Comment

                      Working...
                      X