Limited ATI support?

[darkbasic]

Only <= Evergreen cards.

[Panix]

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).

[Panix]

Only <= Evergreen cards.

April: four/five months ago?

http://wiki.freebsd.org/DriDrivers

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?

[BlackStar]

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.

[airlied]

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.

[BlackStar]

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?)

[airlied]

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.

[BlackStar]

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.

[agd5f]

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.

[yogi_berra]

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.