Well, along comes Intel, who believes the hype and releases the source code for their graphics cards. It has mostly worked out, and there have been few issues (I have still heard people report Suspend issues with Intel cards). However, Intel GPUs have a reputation for being simple and not meant for high-end performance.
Well, that is just dandy. Now, AMD/ATI comes along and says, "well, if Intel is going to give in to a <1% markeshare os, then we will too!" They opened up a bunch of their docs and let the freetards loose on them. Some of these docs have been available since September 2007. Most of them have been available for nearly a year.
Let's check up on the progress, shall we?
Wow! Support for textures and pixel shaders is at best mostly done on R500 and later cards. Those are hardly necessary for modern games (or any 3d application), though. Are there any other problems?
The following subsystems have not been implemented yet or show some limitations:
- 3D acceleration is only implemented on R5xx and RS6xx upto now. Also no XVideo on newer chips (needs 3D engine for scaling). Still, fullscreen video is working fluently with shadowfb for many users. An experimental 3D bringup tool is now available for testing.
- No TV and Component connector support so far.
- Suspend & Resume isn't completely tested, but works on a variety of hardware. Your mileage may vary. Note that typically you need some BIOS workarounds on the kernel command line, ask your distribution for that.
- No powermanagement yet. Depending on your hardware, the fan might run at full speed. This turned out to be really tricky.
Well, the freetards have managed to create a little 3d acceleration, and they have not fully managed to fix the major problems with the fglrx drivers: bad ACPI support. It only took them 15 months to do it! I feel freer already!
16 comments:
What are you trying to prove to everyone how big of a Idiot you are.
AMD only started releasing there doc in Septemeber 2007. Note starting. Every released doc has had to go through AMD legal department. Final documents on the r300 should be released in another months time.
Yes final documents for R600 and R700 are not released either most likely by middle of year. Sorry until final documents are released they cannot Leave WIP status.
"XVideo on newer chips (needs 3D engine for scaling)."
So please do your research. Notice that GLSL is TODO all the way across get what its not released. Some things depend on it. GLSL is need to build the 3d engine for XVideo.
Lot what you list please down load the documents and find where it describes doing it. Yep no docs no code that simple. The open source drivers currently do everything the release documents provide information to do.
Another case of being a complete idiot and not doing research so lazy to look at a web page and just write up article claiming a stack of things. It would have taken a few days to do the research correctly.
When all specs are released, it will be the fucking year of the linux desktop!
Big yawn. See ya again in 2030.
Another research lacking idiot. AMD is on time table. They said it would take about 2 years to process all the documents. So September 2009. To be correct AMD is ahead of time table on document release. After that legal team will work on inspecting and passing documents of anything in development for release. So after that point documents will be released before the devices exist anywhere other than prototypes.
Turns out to be AMD legal advantage.
That's the nicest thing about Linux: all come things wait those good to who.
Lot what you list please down load the documents and find where it describes doing it. Yep no docs no code that simple. The open source drivers currently do everything the release documents provide information to do.
ORLY? Even a cursory glance at the documentation showed that the R500 documentation was much more extensive than the R300 documentation, but texture and fragment shader support is only 'mostly complete' for the R500. Just looking at the table of contents for both show the R500 is at least as documented as the R300. As an example, I looked at the list of Texture Registers for the R300 and R500, and it seems the R500 has everything the R300 has. The MMReg's also seemed to have the same hex values on both cards! Keep in mind that the documentation for the R500 was released last April!
Regarding GLSL, what exactly have they not released? The GLSL specification is readily available. The documentation for all the cards covers the Fragment Shader Registers. I do not know if the 'Vertex Registers' include the 'Vertex Shader Registers', but the FSRs should serve as a starting point.
u bookmarked LH on Chrome? That piece of google spyware! LMAO
Fragment shader is only mostly complete. Censored document was released last April. There still could be more releases to allow more use of the cards features yet. Sections of the uncensored 500 document are still in AMD legal department.
Issue here is that 500 cards can do more Fragment shader operations than 300 cards. So yes its mostly complete. It complete to the level of a 300 card. It is not complete to the level a 500 card can truly do. Neither is the openly released documentation yet.
You have to be aware person creating that table has access to the full Uncensored documentation. Some of the coders working on the open source drivers have that right. Its the reason why inside hours of the documentation to do X being released the code is released. Some cases released before the documentation is due to the documentation needing formating clean up.
You just showed your programmer inexperience. GLSL document at opengl.org is userspace interface information to use GLSL. Not how you get from user interface to GPU processing for GLSL. The documentation to build GLSL to GPU is missing.
Basically you have dug yourself into a hole with no why out this time Linux Hater's Redux. You failed to do your homework completely first so you cannot read what the site information is presenting you with and are making hugely incorrect presumes.
If you had done your homework first you would have never written this complete section. Because your starting article is basically completely wrong.
Name the reason why AMD is opening ATI specs. It has nothing to do with Open Source. Remember AMD always has released there specs. There is something important there you have missed. Even if open source developers were not building drivers the specs still would have been released.
oiaohm,
I would not go along with LHR this time, because for me the problem is obviously different.
Linux can't get itself a decent video driver because OSS can't have neither the resources, nor sufficient up-to-date documentation on the chips.
Further, the constant moving target that the kernel is, which its constantly changing API/ABI and breaking drivers, makes it quite of a problem for ATI / NVIDIA to create stable drivers, which just work, without having to recompile them. Then, how a regular, non-technie user can expect that the next system update won't break its system?
Sad future, I would say - poor drivers, which never support the newest of hardware properly.
@Nik, following the kernel api/abi is not a big deal for a graphical driver developer.
there is a kernel driver for direct hw access. and there is a driver on top of X.org. the first one is required for hardware acceleration, at least for now.
adapting to new kernel requires work in the first driver, not the second one.
as far as binary drivers go - kernel developers do not care about them.
kernel breaks its api often, because there is always a good technical reason for it.
if those changes were held back by trying to keep compatible with proprietary drivers it would hinder its development. it is the proprietary driver developers responsibility to adapt to the kernel, not the other way around.
Wait...does this mean that the core claim of FOSS advocates, that a "bazaar" of free-wheeling volunteer programmers will always code circles around a "catherdral" full of PHBs and marketroids, is not true?
FOSS produces broken, bloated, fragile products that are usually years behind the closed-source products that they are desperately trying to emulate.
Watching oiaohm spin and twist and whine and complain and shift blame and offer excuses for why his beloved OS is such a festering shitpile of bugs after 15 years of non-stop desktop development is always good for a laugh in these trying times. Never change, oioahm.
And I don't think you could find a sentence more perfectly suited to explain why Linux will never, ever, ever get beyond 1% of the consumer desktop than "kernel breaks its api often, because there is always a good technical reason for it."
GLSL is need to build the 3d engine for XVideo.
Uhh! I did not care why it was listed as an issue. I had just copied all of the issues it listed. I noticed that you have not mentioned anything about its admitted flaky ACPI support.
Issue here is that 500 cards can do more Fragment shader operations than 300 cards.
You just showed your programmer inexperience. GLSL document at opengl.org is userspace interface information to use GLSL. Not how you get from user interface to GPU processing for GLSL.
Where did I say that the GLSL spec has any info on implementing hardware support for it? I was talking about all the documentation needed for GLSL support. Pay attention next time!
The documentation to build GLSL to GPU is missing.
ORLY? Remember when you told me to download that document and read it? Well, I did, and what I found was quite intriguing. I would especially recommend reading chapters 6 & 7. From what I read of Chapter 6, AMD has given pretty much everything needed to implement GLSL. I am not just talking about how to pass vertices and textures to the graphics card, but they even have support for flow control on the card! I did not read chapter 7 as much, but I assume it is similarly well documented. The commands seem to follow the protocols detailed in chapters 2-5, and they have quite a bit of advice for driver developers. If you want to continue this discussion, I urge you to go read that document very carefully and then tell me just what more any semi-decent developer would need to implement GLSL for those cards IN ADDITION TO the information given in that manual.
Now, let's just pretend all that did not exist and had not been released last April. The list of features on the main indicates that Vertex & Fragment Shader support is mostly done on the R500. Even if they could not provide full acceleration, it appears that they have enough information to at least accelerate SOME of it.
Linux Hater's Redux what is missing is so simple but also so important and does take ages to generate. Did you see any timings on how long any of those instructions should take normally measured in clock cycles.
You are reading a incomplete spec sheet. Of course having the timing data released makes building a GLSL that truly performs possible. Without the timing sheets they either have to be generated that takes a lot of time or pot luck.
Basically to make a system to translate from GLSL to GPU with high performance you need the tables. As with a lot of Open Source driver development its either done right or not at all.
GLSL translation engine also lives in Mesa3d.org and sorry mesa if it has fragment shaders with access to it and not a GLSL system it does use them and does translate sections into fragment shaders. So yes it is currently partly accelerated.
Its not like GLSL does not work at all even that its marked as TODO. Marked as TODO because it not working perfectly where GLSL instructions are translated and processed by GPU. Yep translation from GLSL to GPU code done by GPU.
This is the problem Linux Hater's Redux you have Zero understanding of what has to be in the documents so stuff can be done correctly.
Nik Amd is design there way out kernel problems. Kernel driver of AMD is quite bare really. Same with VIA and Intel. They will cease to be effected by kernel alterations. Resources have been a issue. Notice VIA is moving to shutting down there closed source driver development for Linux. Simply because it was not long after the Open Source developers got full spec that the open source driver was far more complete than the VIA one was.
Also as Linux Hater's Redux noted ATI does not change there card instructions massively between versions. So yes once you have caught up keeping up is simpler. Neither do Nvidia's. Reversing is a very slow process. Legal processing of documents is also a slow process.
Anno 15 years of Linux Desktop? Ok first 10 years of Linux X11 server and its drivers basically were in bit rot no major coders working on them at all.
So no there has not been 15 years of solid development on making the Linux Desktop work. Last about 6 years focus on the Desktop started heavily.
Issue you have to wake up to Anno is that by end of year most drivers for Linux will be able to be made without ever touching there Kernel ABI. Pure Userspace drivers. So the complete Kernel ABI issue is basically a joke. The official answer is Userspace driver API.
Developers of drivers could choose to develop a driver using unstable ABI or a stable one.
Please remember that X11 was never designed in the first place to have Kernel Level drivers. So Nvidia and ATI drivers have both been non formal hacks to the standard that were partly formalised in DRI 1 yet DRI 1 was never designed to handle more than 1 opengl application at a time. Yes 1 opengl program only. DRI2 is designed to be a true desktop base and sees simplicity returned.
DRI1 all instructions going to gpu has to be translated to DRI1 then translated at DRI1 to gpu and going back the other way same thing happened.
Yes ATI and Intel and VIA drivers followed standard and have been slow on Linux due to majorly too much translation. Video card competition will return on Linux Nvidia will no longer be twice as fast as ATI on Linux. DRI2 massivelly levels the field.
DRI2 Application encodes information as the GPU understands and sends it to the GPU threw a que system so supporting multiable 3d programs side by side. Also DRI2 application running Local talks straight to GPU completely by passing X11. X11 only sets where screen section will be displayed.
We are talking about a different the size of MS implementing Direct X. Yes its been bumpy.
Here is the funny one DRI2 is not only about Linux the work they are doing is also about Windows and Mac. This is leading to a merge of code base. If you are coding GPU control without using any platform dependant instructions code can be used on any platform. Welcome to the future graphic system for everyone testing ground it currently on Linux.
@oiaohm
Damm, if it all works as you describe I can't wait!
Lintards always say "things are being worked out" and "everything will be resolved" and "stick with us guys"
Don't be fooled by their lies and their delusion. It's the same mantra they have been repeating for years.
Difference here nothing said by me is not in the development trees and mailing lists. Most under 6 months to full release. Most video cards using the new system max of 12 months. Some of the drivers are already released.
Yes there was 2 years of planing and about 2 years of code development. So yes its been talked about for the last 4 years.
Its not like crap up that is vista took less than 4 years to develop. Windows 7 is not developed over night either.
The idea that stuff happens by magic it does not. Developers talk about a design and so call lintard and MStards take it that it should be done like a click of fingers. So then peoples expectations get dashed.
Linux Desktop claims every year has been a case of that. Design was formed to get there. No one really bothers time lining it. So they are doing X so this year will be great. Yep not going to happen. Anyone who had wrote a list of requirements then timelined the development need to get there would have never claimed Linux Year of Desktop yet.
Linux kernel only reaches a desktop style kernel this year. Now does that mean the rest of the graphical interface ie windows managers, applications... will be ready for a full year of desktop this year. Most likely no. Will conditions improve on the desktop yes.
That is where all you disappoint comes from. Even for us who do time line events like first memory manager for video cards having to be scraped and rebuilt was unforeseeable thinking the first one was passing all tests that had be put before it before the supper big bug was found. Price of that failure was a extra 12 months delay in the process to build and test a new one.
IE development is not a far process.
Come on really go back and time line all the stuff you though the developers promised you. Some cases what the developers said was miss understood other cases developers said no time line ie its done when it done and people have though it was that year.
If you have expectations problems about time you correct them. Even MS misses dead lines Windows is almost never released on time.
When the code moves from a development tree to mainline tree release of that feature is close. I am restrict myself mostly to items that have cross from development tree to mainline. When its in mainline it will be included in the next release of the application/kernel in most cases. At worse delayed for another 2 to 3 versions.
Only step a little outside to development branches.
anybody heard of this one? http://www.theregister.co.uk/2009/02/12/cuba_does_linux/
GNU/Guevarra time! Or fedelix! Or Cubix!
Post a Comment