# So long xf86-video-ati UMS support



## adamk (Jun 15, 2012)

From #radeon on IRC this morning.


```
<airlied> 71 files changed, 728 insertions(+), 57306 deletions(-)
<airlied> ums go bye bye
<airlied> now to test it runs :)
<carli2> airlied: 71 files changed... where? in xorg?
<airlied> carli2: -ati driver
<carli2> airlied: what exactly did you improve?
<airlied> carli2: my life :)
<airlied> no more UMS
```

User modesetting will continue to exist in a separate branch, but unless someone steps up to maintain the UMS codebase, it will likely cease to work with future versions of the X server, and start suffering (more than it already has) from bit rot.

Adam


----------



## ahavatar (Jun 15, 2012)

Is there a project going on for ATI KMS driver for FreeBSD?


----------



## zeissoctopus (Jun 15, 2012)

ahavatar said:
			
		

> Is there a project going on for ATI KMS driver for FreeBSD?



No ATI KMS project for FreeBSD.


----------



## wblock@ (Jun 15, 2012)

Not yet, anyway.


----------



## greenpoise (Feb 14, 2013)

wblock@ said:
			
		

> Not yet, anyway.



I found this. Any support for KMS/Radeon yet? I am new to Freebsd. Got almost everything working except for my card. I get poor resolution. Any Xorg.conf would not work because of KMS error message. Any workaround?


Thanks


----------



## wblock@ (Feb 14, 2013)

No, there is no support for it yet.


----------



## greenpoise (Feb 14, 2013)

wblock@ said:
			
		

> No, there is no support for it yet.



*I*s there a way around it? *A* nightly build that supports it? *W*hat I don*'*t get is that if it*'*s not available yet, why can*'*t I use the old ATI drivers? Thanks!


----------



## wblock@ (Feb 14, 2013)

The old (existing) drivers fully support Radeon cards up to the 4000-series.  Some 5000-series cards have partial support, enough to be useful for desktop-type stuff.  

The driver requires KMS support for later cards.  Thanks to a Foundation-funded effort, we now have Intel KMS support in the FreeBSD kernel.  To support the KMS Radeon code, much more work needs to be done.  The Foundation has offered to fund the AMD/ATI porting/conversion effort, but so far there have been no takers.  It's a complicated job that requires knowledge in several different areas.


----------



## greenpoise (Feb 14, 2013)

wblock@ said:
			
		

> The old (existing) drivers fully support Radeon cards up to the 4000-series.  Some 5000-series cards have partial support, enough to be useful for desktop-type stuff.
> 
> The driver requires KMS support for later cards.  Thanks to a Foundation-funded effort, we now have Intel KMS support in the FreeBSD kernel.  To support the KMS Radeon code, much more work needs to be done.  The Foundation has offered to fund the AMD/ATI porting/conversion effort, but so far there have been no takers.  It's a complicated job that requires knowledge in several different areas.



I see. Thanks for the explanation. I hope something comes up. I wish I could be part of any of it but I don*'*t think my skills are sufficient. Coming from L*nix background, I think I had enough of so many changes in L*nix which in part don*'*t make sense. FreeBSD is the purest form of Unix making it a system I would like to stick with. Having said that, I really hope that it keeps growing! *I*t deserves all the attention. Thanks again!


----------



## Nukama (Feb 14, 2013)

There is some porting effort for AMD_GPU.


----------



## ORTO-DOX (Feb 15, 2013)

Many forces and enough time for *Jean-SÃ©bastien PÃ©dron* in his titanic and very needed work!!!


----------



## tingo (Feb 16, 2013)

Nukama said:
			
		

> There is some porting effort for AMD_GPU.



Interesting. I wonder if this  will work for integrated Radeons in APUs too?
Like my A8-5600K:

```
root@kg-quiet# dmesg | grep CPU
CPU: AMD A8-5600K APU with Radeon(tm) HD Graphics    (3618.07-MHz K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
```


----------



## wblock@ (Feb 16, 2013)

May not be all that is needed, but certainly a requirement.


----------



## kpedersen (Feb 16, 2013)

I heard that for their latest series of GPUs, AMD is releasing the drivers open-source?

Perhaps this will allow FreeBSD to benefit? Or is the majority of work for the KMS aspect first before any work on the driver can be done.

This might be the point of KMS but surely it will some day need to be written in a generic way so future drivers requiring KMS will be able to use it? Since Intel gfx cards can now use KMS, doesn't this mean that the majority of work is already done?

Or does the KMS requirement really just mean that drivers are becoming really complex and invasive to the kernel? This is surely going to make it very hard for completely new graphics card makers to enter the market :/


----------



## wblock@ (Feb 16, 2013)

AMD pays people to work on the xorg Radeon driver.  Last I knew, they were even trying to hire someone.  The newest driver is supposed to have support for hardware that is either brand new or has not yet been released.  So yes, it's open source.

There are layers to the KMS stuff.  Intel drivers do things one way, and that is done.  Some of that work is useful for the Radeon drivers, but they do things in a different way, and need additional pieces.  I posted a link to an article that described some of the pieces a while back, and if I can find that, will post it here.

Edit: here it is: http://blog.mecheye.net/2012/06/the-linux-graphics-stack/


----------



## adamk (Feb 16, 2013)

kpedersen said:
			
		

> I heard that for their latest series of GPUs, AMD is releasing the drivers open-source?



They have been working on open source drivers for years now.  That's the driver airlied was talking about in my original post here.



> Perhaps this will allow FreeBSD to benefit? Or is the majority of work for the KMS aspect before any work on the driver can be done.



KMS is a requirement for newer GPUs to even use the open source radeon driver.



> This might be the point of KMS but surely it will some day need to written in a generic way so future drivers requiring KMS will be able to use it? Since Intel gfx cards can now use KMS, doesn't this mean that the majority of work is already done?



Some of the work is done, but I don't think one could say it's the majority.  The intel and radeon drivers use two completely different memory managers, with the intel one (GEM geared exclusively to intel integrated GPUs.  The one used by the radeon driver (TTM) is supposed to be a little more generic, something other drivers (such as nouveau) can use more easily.



> Or does the KMS requirement really just mean that drivers are becoming really complex and invasive to the kernel?



Yes, they are certainly more invasive to the kernel, with the tradeoff being better performance.  And more features, such as the ability to show a kernel panic message even if X is running, a high resolution console running at my monitors native resolution, etc.



> This is surely going to make it very hard for completely new graphics card makers to enter the market :/



I don't make that connection, personally...  New graphics card manufacturers are going to have to write new drivers...  What difference does it make to them if the drivers are UMS or KMS? In fact, the development of the TTM memory manager, and the gallium3d infrastructure, are supposed it easier for developers of new drivers.

Adam


----------



## kpa (Feb 17, 2013)

adamk said:
			
		

> I don't make that connection, personally...  New graphics card manufacturers are going to have to write new drivers...  What difference does it make to them if the drivers are UMS or KMS? In fact, the development of the TTM memory manager, and the gallium3d infrastructure, are supposed it easier for developers of new drivers.
> 
> Adam



I don't get it either.  Right now the situation is that there's no API for modeswitching and related stuff in X, every driver has implemented those in their own way in a very hardware dependent way. The KMS and related APIs are going to help tremendously by simplifying the driver development when there is no longer a need to talk to the hardware directly for such simple operation as a mode switch.


----------



## kpedersen (Feb 17, 2013)

Perhaps not then. I assumed that writing the KMS related stuff as well as the driver itself was going to be a lot more work for a card manufacturer to catch up with Intel, AMD and Nvidia.


----------



## kpa (Feb 17, 2013)

There's also the point of making virtualized gfx hardware easier to implement when the userspace components don't have to know anything about the dirty details of the hardware.


----------

