as for which drivers should have focus, IMO AMD should simply EOL fglrx, and work exclusively on free drivers..
if workstation graphics people wont let their applications being run on a driver simply because its opensource.. well, then they are stupid, and i dont give a damn what they think. As for DRM and such crap, that should be possible to handle in an addon to the free driver.
This way all optimizations and stuff would go into the open driver, and not some secret amd blob which people realistically have no way of properly using.
As for distribution support, OFCOURSE the drivers(fglrx right now) should work there, i agree, amd shouldnt be spending time on writing weird scripts to make it work there, but the driver should really just f****** work on _ANY_ distribution which doesent break it by itself.. what im saying is, it should work on VANILLA builds from the various projects, aka, the kernel, xorg and such. If distributions are altering things, locations, or need special packaging scripts, this is no problem, because the distribution will simply take care of that themselves.
Announcement
Collapse
No announcement yet.
AMD Catalyst 8.5 For Linux
Collapse
X
-
Originally posted by bridgman View PostI'll have to go search for your issues and system configuration (I don't keep files on you all) but there's no question that BIOS remapping is still causing a lot of hurt with 4GB or more. At first glance it seems that some BIOSes are saying memory is present in places where it really is not. A couple of people have recently reported good luck limiting the amount of memory used by the kernel to 3.5M or so; doesn't sound like an ideal solution but sure seems easier to test than pulling out DIMMs.
To limit the kernel to 3.5 gigs, would I just use mem=3584M as a kernel boot option? I remember I've tried to do that to specify the full 4GB but it wouldn't boot with that option (mem=4096M iirc), complaining about insufficient RAM, again iirc.
Originally posted by bridgman View PostI think we will get R600 3D running on open source drivers before we get an installer smart enough to work with every distro variant and patch combination out there. That said, there are only a finite number of open source developers available to help debug system-specific issues and I'm already seeing a lot of users who don't want to run open source drivers because "they have to build them and that's a big pain".
Originally posted by bridgman View PostDepends what you mean by the question. If you're saying "we should be doing testing on a Debian system now that we're targetting consumer users" then I think we're in violent agreement. If you're saying "no matter what oddball combination of system, distro and patches a customer runs you need to work on their system" that gets tricky because we reach a point of diminishing returns. Top priority is making sure we always run reliably on major out-of-box distros so at least every customer has a starting point and can easily find out what made the difference between working and not-working.
Originally posted by bridgman View PostWe have lots of hardware, but thanks. Hardware is not the problem -- good testers are expensive no matter where they are.
Originally posted by bridgman View PostDo you think enough people would bother that we would get a representative number?
I'm just going to try and touch on some of the things posted about since I last posted:
As to the question of FLOSS devs not having the time for performance optimization - I think AMD should eventually have some of their people make some efforts to optimize the open drivers. Until such a time as 3D is up and running reliably though, this can certainly (must certainly) wait. I'm not talking about engaging in a video card performance arms race with Nvidia, or optimizing to the max for every new game that comes out (hehe I guess that's not much of a concern right now on Linux), just using the experience of a decade of 3D driver work to implement performance optimizations where they'd be of use, not making them(the open drivers) quite balls-to-the-wall, screaming fast, but at least improving them performance-wise beyond the level that the FLOSS devs are prepared/able to themselves.
Once the open drivers are up to snuff, I think AMD would also do well to create a closed DRM-features driver that can augment the radeon and radeonHD drivers for those who want to playback Bluray discs but not use fglrx. I personally would have no interest in it myself, until such a time as I can strip a Bluray disc of AACS I won't touch that garbage, but as you say bridgman, if(when) Linux ever sees significant market share increases, some people will want those features. It would be great if one could just grab a DRM package and tack it on. I don't know about the viability of that, I believe it's been discussed a bit in other threads. It would certainly be a better option I think for the people who would prefer to use the open driver(s), than running the open driver except when you want to play a movie (and jumping back to my last paragraph, that would be a similar situation - I certainly have little interest in running the open driver for everything but games and then having to run fglrx to play a game with decent performance).
I also think AMD should make it possible to use hardware acceleration to decode unprotected content with the open drivers. Maybe this already in the cards? Should be a given IMHO. I guess with Stream SDK out now, we just have to wait for the MPlayer and VLC (and GStreamer and Xine) devs to implement GPU decoding?
I mentioned this a few days ago (I think earlier in this thread actually), and I realize it'll probably never happen, but I would personally love to see a line of cards that DO NOT support playback of protected content of any kind. I look at the HDCP sticker on my 3650 and it grates upon my soul. I can't help thinking I'd have a lot less issues (as would fglrx) were it not for that damn protected content BS.
bridgman you are truly to be commended. I can't motivate myself to keep writing this post even though I'm sure there are some more points I had some kind of a reply to when I read the posts after mine the first time. You just keep answering all these epic posts! Kudos eh!
edit: maybe I haven't looked in the correct spot, but one thing Nvidia has going at nvnews.net is a well defined guide to creating the appropriate logs and info for filing a bug report. They're kinda jerks about not responding to any inquiries without that info, but I presume when they get that info it helps them fixing the bugs they care to fix (the ones the staff there aren't sowing misinformation about). Are there some similar guidelines for ATI? A bug report info extraction tool would be handy...Last edited by oblivious_maximus; 31 May 2008, 05:41 PM.
Leave a comment:
-
i have found the problem... for SOME reason /usr/lib/libGL.so.1.2 was corrupted.
I now have direct rendering.
It still brings up wrong resolution though. The funny thing is, it does detect edid properly in xorg.log, but then it somehow just sets 1680x1050 as resolution.. and lists up to and including 1920x1200 in amdccle.
now applications does not crash when exiting.
HOWEVER.
it is quite buggy still.. i found that wine is somehow able to leave the opengl driver in a broken state (atleast for itself)
if i start world of warcraft with -opengl, it might or might not start (giving bad glx drawable), if i then start neverball and close neverball, i am able to start world of warcraft in wine, ONCE, if i start it again, it gives the bad glx drawable - neverball is able to fix it..
performance isnt terribly good, alot worse on this c2d 3ghz box than my amd64 2ghz with 6600gt agp. I didnt expect HD 3450 to be fast, but can you tell me if im hitting around the correct performance? (im getting ~8-10fps in wow @ 1024x768 almost full details).
im still having the "reaction" issue with 2d. if i press a window to move it, it takes like.. 0.2-0.5sec before it starts moving, and then its perfectly fluid (and no, i do not use compiz/composite/aiglx).
Ill give you this though, 2d performance beats the crap out of nvidia on 8xxx.
Leave a comment:
-
Originally posted by Redeeman View Postneverball runs fluid in 1280x1024, i do not believe a core 2 duo 3ghz is capable of software rendering that game, in this resolution
If you are getting good performance on neverball and Wine is complaining about DRI this sounds like the case.
Not sure if I asked which version of Wine you are running; there seem to be some pretty serious regressions recently and I see recommendations to go back to considerably older versions when troubleshooting.
Leave a comment:
-
Originally posted by bridgman View PostDave and Alex pushed some pretty significant fixes for RS4xx recently; have you tried the open source drivers in the last couple of weeks ? You definitely need latest DRM and Mesa, not sure about radeon and X server.
Here's one of the recent fixes : http://airlied.livejournal.com/59351.html
(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.28.0
I will try an SVN-version of X.Org if needed.Last edited by chikazuku; 31 May 2008, 12:45 PM.
Leave a comment:
-
#164:
"This sounds odd. Is there a Bugzilla ticket open for this, with log ? Is this specific to 8.5 or did it happen with previous releases as well ?"
I have not tried anything older.. will anything older work with .25?
"Is this under Wine/Cedega/whatever or native ? Any other info we could use to understand what is happening ?" well.. actually, wine is the one thing that DOESENT do this.. unfortunately wine is useless, so it probably quits before it has a chance to hit the reason.. glxinfo segfaults at one point. when i start amdccl, it works fine, but when i quit it, it segfaults. same with neverball.
"OK, something is definitely installed wrong then. Can you paste a log somewhere, ideally Bugzilla ?" xorg log says nothing wrong.
"Yeah, until you get DRI=yes it's not worth going any further."
neverball runs fluid in 1280x1024, i do not believe a core 2 duo 3ghz is capable of software rendering that game, in this resolution..
"I'm sure you followed the proper steps, but it doesn't sound like the installation is right for your specific system. If you are running WOW over Wine (are you ?) on Debian or Ubuntu there seem to be strong recommendations for installing via Envy. Not sure if it actually sets something different or is just less likely to fsck up, but it seems to be a common recommendation. "
I am reasonably skilled with these sorts of things (having dealt with fglrx before on my laptop, and nvidia on several computers), and i can tell you this, the correct libGL is in place, xorg loads fglrx correct, and it does not complain about dri (which it did untill i modprobed fglrx), and fglrx kernel module loads correctly..
i will attempt to debug this further..
Leave a comment:
-
Originally posted by Melcar View PostI'm guessing you want something like what Intel is doing? Dump money and support and keep everyone happy. Granted it works, and the Linux Intel driver is probably the best out there. However, it would be no surprise to me that once Larabee hits the streets, Intel would pursue its own Linux program and not be as supportive anymore.
The way I consider it is that right now it is Intel that is shaping the future of the linux graphics market. nVidia doesnt have a CPU. Unless nVidia comes up with a decent x86 cpu in the next 5 years they will be left in the dust. It's almost certain that nVidia is going to die. And It is Intel that is laying the ground work for the future of graphics in linux. Not ATi.
We all know ATi has the better hardware, and I personally dont think Larrabbe has anything interesting to offer. A bunch of broken down simplified x86 cores aint gonna cut it. The ISA just doesnt scale well to multicore. Especially not something so massivelly parallel. I dont think Intel has now or will have in the near future a graphics architecture capable of competing on performance or functionality. However it is beyond a doubt that Intel will take the linux market given current trends.
Leave a comment:
-
I'm guessing you want something like what Intel is doing? Dump money and support and keep everyone happy. Granted it works, and the Linux Intel driver is probably the best out there. However, it would be no surprise to me that once Larabee hits the streets, Intel would pursue its own Linux program and not be as supportive anymore.
Leave a comment:
-
Sorry Bridgeman. Not trying to be a pain or anything, I promise.
I guess, we'll have to agree to disagree. It's a shame though, becouse I'm 100% convinced that if you dropped all support for DRM today, and stopped all further development on fglrz and devoted those resources into open source you'd be able to capture the entire linux market. It wouldnt have any effect at all on your windows market. Just keep on doing what you do there...
I may not know the linux graphics subsystem very well, but I'm not entirely retarded. I do have at the very minimum at least a fundamental understanding of micro architecture and fabrication. At the very minimum I understand the fundamental idea's behind modern driver development. I'm no expert by far, but I'm not entirely naive either. I can understand why you publicly deny reverse compiling nvidia's drivers, and looking at the architecture, but come on now.... I've seen an application that could take a binary and convert it directly into C. Granted it didnt have have any comments, and reading through it was very cryptic, but you could still follow the code.
And I do understand that most of fglrx is common code. But windows drivers dont just run magically on linux. Take those precious resources and devote them to open source. You'll wind up with a much better product in the end.
And again as far as HDCP goes, I really dont want to get into it, but suffice to say that I dont have ready access to the decryption key. I can think of at least half a dozen laws that apply. And becouse of this every possible effort should be made to disable the DRM in hardware, and to circumvent the DRM in software. Those efforts are already underway. Fortunately the open source ATi drivers with Radeon and radeonhd wont support the drm in hardware. The only thing left is circumventing the software. And like I said those efforts are already underway. Sooner rather then later all of us will be able to watch and copy DRM'd content entirely with open source drivers and software. And we'll be able to do 100% transparently.Last edited by duby229; 31 May 2008, 09:16 AM.
Leave a comment:
-
Originally posted by duby229 View PostI disagree. I acnt see one instance where a closed driver would provide some kind of benefit. If you can name one instance where a closed driver might be of some benefit then you might persuade me, but I cant think of a single one.
Originally posted by duby229 View PostThe only thing I can think of is that your thinking that using a closed source driver is somehow going to "hide" something. Come now, I'm not that naive. I may be a noob, but I know full and well that the first thing nVidia does when ATi releases a new driver is reverse compile it, and you do the exact same thing with theres. When ATi releases a new chip the first thing nVidia does is put it under an electron microscope, figuratively and literally, and you guys do the same.
I don't think either of us would live long enough to pick through a disassembled copy of a modern driver. The drivers were over 2M lines of code when I joined ATI and maybe ten times that today. It's just not worth the effort to pick through a code base that size. Heck, it would be more efficient to randomly dial extensions at your competitor and ask each person who answered to explain how the technology worked. I'm sure someone would tell you
Originally posted by duby229 View PostAnd that is entirely ATi's fault. 100% they arent actually expected to work for free are they? They have to have a day job. These guys have families to feed just like everybody else. Pay them enough to make it there day job, and put the guys from fglrx working on it full time too. It's not magic. It requires some talent yes, but it also requires some funding and incentive. Bottom line it's ATi hardware and if they want to tap into this market then they need to devote the resources required to make it worthwhile.
You do understand that most of the developers who contribute to fglrx are working on common code and are not dedicated to Linux, right ? Are you asking us to shut down Windows development in order to make a better open source driver, or just have the Linux-specific people work on open source.
Originally posted by duby229 View PostI'm not much in the mood for debating DRM at the moment, but suffice to say that HDCP itself breaks at least half a dozen laws in the US alone, and by supporting it in your drivers ATi is too. It's simply not worth your time. It will be hacked. I would love someone to try and sue me for using a HDCP hack. I'm a poor person, but I'sd take it to court and run with it becouse I know for a fact beyond that shadow of a doubt that I would win by a significant margin.
Originally posted by duby229 View PostBottom line is HDCP really isnt your concern. It is currently being worked on by --far-- more capable open source projects. Your efforts arent wanted or needed.Last edited by bridgman; 31 May 2008, 03:06 AM.
Leave a comment:
Leave a comment: