Reply
 
Thread Tools Display Modes
  #1  
Old 09-03-2011, 12:03 PM
Black_N Black_N is offline
Junior Member
 
Join Date: Sep 2011
Location: Ukraine
Posts: 5
Thanks: 4
Thanked 0 Times in 0 Posts
Default Help us to AMD Graphics see a lot of users want better drivers!
Hi guys.
Take action, please

Public request to better AMD Graphics (before ATI) support on FreeBSD >>>>>

Quote:
To: Advanced Micro Devices, Inc. (AMD)

Public request to better AMD Graphics (before ATI) support on FreeBSD
- KMS/TTM
- X.org privative drivers

It isn't good that AMD only wants to invest in Linux and Windows because they see those as big markets. Only open source drivers exist (such as xf86-video-radeonhd) and not all graphics cards are supported.

Sign the petition to let AMD know you want better support in FreeBSD! Help prove to them how large our market really is, and how much we desire to use their hardware.
Reply With Quote
  #2  
Old 09-03-2011, 09:05 PM
yaneurabeya yaneurabeya is offline
Member
 
Join Date: Nov 2008
Location: Sunnyvale, CA
Posts: 48
Thanks: 0
Thanked 0 Times in 0 Posts
Default
The problem is lack of DRM support in FreeBSD, not necessarily driver support.

rnoland used to manage this, but got busy with $LIFE. kib has been working on GEM (at least) with 9-CURRENT. More effort might be required for ATI (I don't remember OTOH if they program their drivers under the GEM infrastructure or if it's just Intel).
__________________
gcooper@
--------
FreeBSD - The Power to Serve

Server Workstation - Intel W3520 / 12GB RAM / FreeBSD CURRENT amd64
Test Workstation - Intel W3520 / 12GB RAM / FreeBSD CURRENT, NetBSD amd64, Windows 7 x64
Reply With Quote
  #3  
Old 10-09-2011, 02:34 PM
supercobrajet supercobrajet is offline
Senior Member
 
Join Date: Aug 2007
Posts: 170
Thanks: 12
Thanked 8 Times in 4 Posts
Default
Yes, absolutely, lets ALL sign the petition/requiest: (the more the merrier)

The DRM issue is true, but just look at the crap drivers ATI gives us. ?

DRM has very little to do with the general "...lack of support from AMD to the general Linux ecosystem.." -you might as well add the *BSD's to that statement.

http://www.archlinux.org/news/ati-ca...pport-dropped/

It's not just the *BSD's, many Linux distro's are getting fed up with AMD/ATI lackadazical way for dealing with their Driver issues, for the last few years now in both camps.

There is no legitamate reason why (AMD)ATI's driver's could not be as good, if not better, than nvidia's by now.
__________________
"the BSD things in life are Free"

Last edited by supercobrajet; 10-09-2011 at 02:41 PM.
Reply With Quote
  #4  
Old 11-21-2011, 04:47 AM
DaemonFC DaemonFC is offline
Junior Member
 
Join Date: Nov 2011
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
Default
Perhaps I can help here. First I should point out I don't use BSD anything, I use Linux, but perhaps I can explain what is going on from the Linux side and from what I've read regarding the BSDs. Some of the BSD related stuff might be a little off, I haven't done much with them because they don't support my video cards.

AMD has two sets of drivers for Linux. One is the Catalyst bundle which is proprietary. Much of the code is shared with their Windows drivers. The kernel glue layer is called fglrx, it is Linux-specific. I assume they could port it to BSD if they felt like that was a priority, but they don't. You will probably never see this on a BSD.

The other is a set of open source components. The Linux kernel module, called "radeon" is what manages the video card's mode and memory. When you see the term "kernel" mode setting, it means it is setting the video mode from the kernel, as opposed to what is going on in the older radeons that the BSDs support, where X must run as root and set the video mode itself, without the kernel knowing what is going on. It's why the console resolution might be different from the resolution in X11, why switching virtual terminals can be slow and broken, and why X is more of a security hazard than it should be (though to be fair, most Linux distributions still run X as root no matter what driver you use for a variety of legacy reasons, this will eventually change though.

By setting the video mode from the kernel rather than X you get:

Consistent display resolution on virtual terminals and X. (This is also what enables those pretty splash screens via Plymouth on Linux.)

Fast and stable switching between X and virtual terminals.

More reliable resume from S3 suspend, since the kernel knows the video mode to come back to and X doesn't always get it right.

Less flickering during boot. Yay, less flickering during boot!

Plenty of other stuff, but there's your elevator pitch on why KMS is good and why UMS (setting the video mode from X) is bad.

Onto your comments about GEM. Implementing GEM won't ever get your radeon to do anything for you. GEM is an Intel thing they NIH'd because they're Intel and Intel doesn't like the thought of anyone else being able to make use of their code. Nouveau (the open source Nvidia driver) and radeon both use TTM, or Translation Table Maps. Unless this works with FreeBSD, don't count on your Radeon being able to do anything very useful. It may work as a frame buffer, but that's about it. I'm not for sure, but since you don't have TTM support, I think X11 is doing the memory management itself on the BSDs, for the r700 and earlier chipsets they support. This is scary and ugly and Linux moved away from this one when they went to the kernel managing the hardware.

In userland, there is a ddx driver that needs the DRI 2 extension, it is my understanding that the guy FreeBSD paid to write support for Intel stuff will be getting the X11 DRI 2 module working with FreeBSD, if so yay, if not, boo, no radeon past the r700 series will have EXA 2d acceleration (also means no XRender or 3d accelerated OpenGL.

The older radeons have UMS and DRI1 support in the BSDs through legacy code paths that nobody has maintained in years. I think the last code for either one that AMD landed was back in early 2009. These have been deprecated for a long time, and the support for them in the Mesa3d (OpenGL) project was deleted entirely in Mesa 7.12-git, 7.11 is going to be the last 3d acceleration you get on any radeon on a BSD unless something changes and BSD's video card support framework gets brought up to speed in the next several months.

It's not AMD's fault that the BSD situation is like this. The code from start to end is under the MIT X11 license. Even the drm and radeon kernel modules from Linux are, Linux simply wraps the GPL around the modules for distribution purposes but they are maintained outside the kernel, so everyone has access to the same up to date code.

If anyone from FreeBSD wants to port this stuff, nobody stops them, AMD simply doesn't care and I don't suspect they will anytime soon. FreeBSD already had to pay someone to make Intel stuff work, which tells me Intel doesn't particularly care what their GMA chipsets are doing on the BSDs either.

Of course, Nouveau has never worked on the BSDs because it has had mandatory KMS and DRI 2 from the start. You guys have the Nvidia proprietary driver as long as Nvidia cares to keep compiling it. They could change their mind tomorrow and then you wouldn't have anything that worked well on BSD. Here's hoping that BSD gets this sorted out soon, for the sake of their users.

Note: A "fun fact", the proprietary Catalyst bundle is essentially using UMS and DRI 1 with some creative patching to work around some of the problems they bring. As for what work arounds they use, I don't know, I've just been told by someone at AMD that it's "not exactly" DRI 1, but its more like it than it is DRI 2. Linux users sometimes have reliability problems with Catalyst, but some tolerate it because it handles OpenGL 4.1 (Mesa only handles 2.1) and its OpenGL performance is fast.

The downside to this is their proprietary driver is not as stable, you get all the UMS and most of the DRI 1 issues, it has problems in the vsync code that cause issues with using direct rendering and vsync at the same time, etc. It's also out of sync with X11 and the kernel since it is done outside both of them obviously, which means many a time I've gotten stuck on an older version of my Linux distribution because of their *just a seconds* #%#$@$@# mess *I'm better now*.

The open source stack is less buggy, and has better 2d acceleration, is more secure, and has the advantages DRI 2 and KMS bring. The main complaint with this is not stability, it is OpenGL support and speed not being on par with Catalyst.

Last edited by DaemonFC; 11-21-2011 at 05:00 AM.
Reply With Quote
  #5  
Old 01-05-2012, 09:25 AM
rockworldmi rockworldmi is offline
Junior Member
 
Join Date: Nov 2011
Posts: 24
Thanks: 1
Thanked 0 Times in 0 Posts
Default
That petition won't work .. but filling and submitting this form will do ..i already filled it and got reply that if more user base requests for drivers they will support it until no one will do anything. And by the way freeBSD is planing to support for AMD in FreeBSD 10..


http://emailcustomercare.amd.com/
Reply With Quote
  #6  
Old 01-05-2012, 01:53 PM
adamk adamk is offline
Member
 
Join Date: Dec 2011
Posts: 99
Thanks: 0
Thanked 1 Time in 1 Post
Default
Originally Posted by rockworldmi View Post
And by the way freeBSD is planing to support for AMD in FreeBSD 10..
You're referring to AMD HD video cards? Where did you hear this?
Reply With Quote
  #7  
Old 01-07-2012, 07:09 PM
DaemonFC DaemonFC is offline
Junior Member
 
Join Date: Nov 2011
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
Default
I think that having userspace talk to hardware without telling the kernel what is happening is so incredibly stupid that if I didn't know that having X set the video mode to begin with was a sacrifice on the altar of compatibility, I'd really wonder who thought of that and if they would pass their really great drugs.

:P

This is one of the things Linux absolutely got right, moving direct hardware access back into the kernel where it belongs. Nothing else should be touching hardware directly. This isn't a pro-Linux anti-BSD rant, it's a question of good design.

I really do hope that FreeBSD works on kernel mode setting, but without TTM as well, RadeonHD cards aren't going to do anything. Intel did with GEM what they're always doing. Taking existing interfaces and trimming out whatever their hardware isn't using for the time being. They have GEM so dumbed down that it can't do memory management for card with dedicated vram. This probably works out fine for Intel since that's all they sell, but once you plug in a real GPU, you're screwed because GEM will do nothing for you.

I'm cautiously optimistic that FreeBSD is moving in the right direction. I'd probably be running it more if it supported my Radeons properly. A desktop system with framebuffer graphics isn't doing anything for me. *sigh*

Before anyone says Nvidia blob...just don't.
Reply With Quote
  #8  
Old 01-14-2012, 03:15 PM
supercobrajet supercobrajet is offline
Senior Member
 
Join Date: Aug 2007
Posts: 170
Thanks: 12
Thanked 8 Times in 4 Posts
Default
Originally Posted by DaemonFC View Post
I think that having userspace talk to hardware without telling the kernel what is happening is so incredibly stupid that if I didn't know that having X set the video mode to begin with was a sacrifice on the altar of compatibility, I'd really wonder who thought of that and if they would pass their really great drugs.

:P

This is one of the things Linux absolutely got right, moving direct hardware access back into the kernel where it belongs. Nothing else should be touching hardware directly. This isn't a pro-Linux anti-BSD rant, it's a question of good design.

I really do hope that FreeBSD works on kernel mode setting, but without TTM as well, RadeonHD cards aren't going to do anything. Intel did with GEM what they're always doing. Taking existing interfaces and trimming out whatever their hardware isn't using for the time being. They have GEM so dumbed down that it can't do memory management for card with dedicated vram. This probably works out fine for Intel since that's all they sell, but once you plug in a real GPU, you're screwed because GEM will do nothing for you.

I'm cautiously optimistic that FreeBSD is moving in the right direction. I'd probably be running it more if it supported my Radeons properly. A desktop system with framebuffer graphics isn't doing anything for me. *sigh*

Before anyone says Nvidia blob...just don't.

"...Nvidia blob ...."
oh, you mean that absolute MESS nvidia/intel created with Nvidia OptiMESS ?
:P
http://www.aigarius.com/blog/2011/05...-optimus-fail/

all is definitely not that well over at your Linux/Nvidia camp either bud, The Bumblebee project still has a LOT of buggies, ie vdpau, power setting problems; the switching is far from complete. and it may never be.
The "ONLY" reason nvidia / ati works a little better in general in Linux, is because, as a "desktop", Linux is obviously more popular than Freebsd, hence why hardware makers want to sell "more" hardware ? capish ?
I'm sure if we (BSD/Linux) actually had an "OpenHardware 3D Graphics" solution that we could actually purchase, then we wouldn't have to worry about anything, except maybe even better "progress" !

It has much less to do with your "...userland..." rantings than the simple fact that it is extremely hard, if not impossible, to reverse-engineer a proprietary/closed hardware device.... not matter how anyone else wants to try to "pretend" to explain it?
This is just one of the reason's, along with kernel security,..., why OpenBSD simply said "NO" to them.

And, as far as your "This is one of the things Linux absolutely got right, moving direct hardware access back into the kernel where it belongs..."
again, that doesn't matter much against proprietary closed hardware devices now does it ?, unless you're UBUMtu/Unity and you actually want to move into an iPad, or an Android,... and then forcing you to re-purchase their newer junk every 6 months, just like Cell phones -Lol, because they do NOT want you "fussing" with it. (it kinda makes me wonder just how "pliable" that GPL* is in the 1st place ?, and I'm not defending either one)

I sorrowfully wish we had some good news regarding AMD/ATI drivers' (on *BSD/Linux) too, we'll still just have to wait and see,
BUT, "bitchin;" at them, all the time, is ALWAYS a good thing to do, either way.
In other words, "..the squeaky wheels, gets the grease...", Or, the shaft, but let's NOT just worry about the latter.

Cheers.
__________________
"the BSD things in life are Free"

Last edited by supercobrajet; 01-14-2012 at 07:43 PM.
Reply With Quote
  #9  
Old 03-17-2012, 11:06 AM
Marco Marco is offline
Senior Member
 
Join Date: Aug 2011
Location: Germany BW-Stuttgart
Posts: 282
Thanks: 36
Thanked 11 Times in 11 Posts
Default
KANO has made a comment on the forums thread Phoronix.com*Goodbye ATI ... well a goodbye from me too ^^

Good NEWS from nVidia Happyface c' dibbe_

NVIDIA Is Joining The Linux Foundation
Reply With Quote
  #10  
Old 03-17-2012, 12:30 PM
adamk adamk is offline
Member
 
Join Date: Dec 2011
Posts: 99
Thanks: 0
Thanked 1 Time in 1 Post
Default
Unfortunately nvidia still refuses to support development of any open source drivers for their GPUs. I refuse to support such a company.

But due to the declining nature of xf86-video-ati on FreeBSD, I find I'm using my favorite operating system less and less, spending more time in Slackware.

Adam
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 04:18 AM.


Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.

Copyright 2005-2010, The PC-BSD Project. PC-BSD and the PC-BSD logo are registered trademarks of iXsystems.
All other content is freely available for sharing under the terms of the Creative Commons Attribution License.