If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Did you read bridgman's response? Well apparently you didn't understand ANYTHING he cleverly wrote to you. They had to make fundamentally changes in the linux gfx stack, before they could even start making all the good things a modern graphic stack should be. Fundamentally changes in the linux driver stack, is not something you write in two weeks!

How can it be fanboyism having an idea how hard/long it takes to re-write the whole graphic stack of linux?

I (and everyone) already know the technical reasons why things are bad and why they are so slow, but actually this is unrelated, you have completely missed my point.

My point is that the way they have chosen to do the whole open source strategy from the beginning to end is crap, so no technical reasons of the current problems can change the facts.

When you are a leader in the graphics department, you don't follow standards that slow you down (kms, gallium crap etc) but you create your own standards and everyone else follows you. That's what nvidia does now, that's why they lead *nix graphics, and no-one cares about the unstable buggy xorg standards that change/break in each version. Nvidia does this the closed-source way, ATI could had done the same, but better and open-source if they wanted.

Right now they are following intel and kernel/xorg graphics projects. Who has better experience and knowledge in the graphics department? Intel? Kernel-dev-team? xorg-dev-team? or ATI/AMD?

The answer is easy here, but the answer is not the leader and that doesn't make sense.

Comment

It is so funny that you all took my conspiracy theory so seriously, because the point of it was that:

1. I am not gordboy ...

2. These specific users, are so ignorant, clueless and extreme fanboys that are just like they are getting paid to be so. And the fact that I am explaining this double-proves that.

well if you are not gordboy probably you have the same type of brain damage he does.

fact 1. AMD is not resposible of radeon driver lol, first time here in this forum? radeon is providing developers and IP cleared documentation of the gfx. aka most dev in the radeon driver are from other companies or communities

fact 2. if you, same as gordboy have in reality any sort of knowledge of about what really happened between the 1 or 2 years ago graphic linux stack and today's linux graphic stack. you wont be posting here these nonsense

fact 3. did you know the ddx is only a pretty damn small part of the code needed to get a fully functional driver? really for once tried to read the code and understand what your talking about first

fact 4. most ppl here arent fanboy's we just have at least the minimal knowledge of development and the massive work needed to get this far, beside the overwhelming complexity of get those tasks done, unlike you.

fact 5. you knew that most of the ideas from the current linux stack came from intel first not AMD? aka KMS, TTM, GEM, DRI2, EXA/UXA(intel was first in implementation), Gallium (at least at the beggining) or AIGLX is from RedHat mostly?

fact 6. you even knew that KMS is needed heavily for the DDX, and this one was in staging in the linux kernel until not long ago (not AMD fault, linus tend to not like to include code that he is not sure that at least work up to some point and he is happy with it, in the main kernel). you really understand that without KMS outside staging, distros wont include it by default, and there you will miss the entire feature set of having that new DDX installed?

fact 7. you knew that AIGLX and EXA requires code from the DRM/DRI/Mesa or gallium infrastructure for several accelerated operations?

fact 8. you understand up to some point that you couldnt release a functional driver with at least the basic functions without get KMS stable enough and outside staging, get DRM well integrated with the lower kernel code, that the Xorg team needed to get some pretty necesaries feature inside EXA xorg code first, get DRI2 and swap events there, get MESA and Mesa shaders compilers in good shape before try any sort of acceleration or gallium.

fact 9. you may ask why intel release quarterly? cuz they begun way earlier than AMD and they got those changes in place including KMS outside staging way before AMD, so they have 2,5 years later of intel 2.4 ddx an stable enough code enviroment in the new stack to now begin to focus in optimize the driver and finally have some sort of doable release schedule. you would knew that is you try at least to understand what are you talking about

fact 10. you have to understand we dont defend AMD per se, we show them support for stepping forward and provide the documentation and some human resources to code a driver fully opensourced, when like nvidia they could just say they dont care.

fact 11. rigth now there are around 7 communities in parallell improving the graphic stack from the DDX of several driver to Opencl, so until all these main project end the big changes in their respective stack, use git snapshots or use the current stack on your distro. and that wont change no matter what you or your other ignorant fud spreader friend do or post (since nobody here care about you or your friend at least not until you post anything smart at least). now if you patience to wait those changes, linux will get one hell of an impresive graphic stack in a not so long future

fact 12. im a commertial developer specialized in C/C++ from some years now, i dont work in any way for AMD, in fact i have my onw comapny in south america totally unrelated to AMD, so far even if im a developer im just helping reporting bug and stuff, at least until i get the knowledge enough to begin to help more actively. i really need to understand better the internal of a modern GPU and refresh my knowledge of higly optimized assembly to be at any help in that aspect, cuz the low level code of the driver is impresivelly complex. in fact i have 10 devs working with me and 2 of them are guys in their 50ish that well have worked in basically every OS and language around, even 1 of them worked t ibm in the era of the first power cpu, lol even that guy is amazed how complex is a modern gpu to code. so i show the developers my respects cuz get this far with a so complex piece of hardware is at minimal impressive

Comment

I (and everyone) already know the technical reasons why things are bad and why they are so slow, but actually this is unrelated, you have completely missed my point.

My point is that the way they have chosen to do the whole open source strategy from the beginning to end is crap, so no technical reasons of the current problems can change the facts.

When you are a leader in the graphics department, you don't follow standards that slow you down (kms, gallium crap etc) but you create your own standards and everyone else follows you. That's what nvidia does now, that's why they lead *nix graphics, and no-one cares about the unstable buggy xorg standards that change/break in each version. Nvidia does this the closed-source way, ATI could had done the same, but better and open-source if they wanted.

Right now they are following intel and kernel/xorg graphics projects. Who has better experience and knowledge in the graphics department? Intel? Kernel-dev-team? xorg-dev-team? or ATI/AMD?

The answer is easy here, but the answer is not the leader and that doesn't make sense.

this is at best stupid to do. when you do software development you have 2 choices as manager

1. do it rigth, and get you time do in it (linux way)
2. the windows way(do a piece of garbage and then will see what happens) but faster

you can imagine what a mess we had if devs choose to do that? every driver around doing everything their own way?

the OSS comunnity effort is not here to have the driver you want faster, they are creating a stack that allow much more in a near future that just a faster release in a modular standarized way (even windows at the end had to create an standard stack for their drivers in windows7 and vista).

who have the best knowledge of a graphic stack? that point of view is just lol, the answer is all of them. implement a driver in an OS require the knowledge of every lvl and specific implementations on every lvl.

unlike you think they actually talk between all of them to approves all this changes, aka kernel, intel, amd, the guys from other drivers, xorg, and any random dude wth a valid idea. is not like intel said this and amd and xorg run to implement it and kernel.org dont know anything about it.

why is slower than the old 30ish years old plataform, cuz you first implement the feature, then you optimize not backwards. but for such a recently code is already showing some strength in many sectors wich is quite promising.

dont like the new plataform? 1. use another one or 2. use another one until the new one gets at production level release

Comment

The "KMS and Gallium crap" IS the open-source implementation of what the FGLRX and nVidia blob do internally.

At the moment when AMD put the effort into the Open Source drivers, there was NO open-source infrastructure that did what needed to be done. And their binary blob could not be open-sourced for a variety of reasons.

The nVidia and ATi binary drivers consist of millions of lines of code which was made by a team of dozens of full-time programmers over more than 10 years. You are expecting three or four guys to replicate that work in a year.

You are not being realistic.

Comment

the OSS comunnity effort is not here to have the driver you want faster, they are creating a stack that allow much more in a near future that just a faster release in a modular standarized way (even windows at the end had to create an standard stack for their drivers in windows7 and vista).

On the other paw, where Linux has multiple competing video acceleration API's, Windows has a single standardized API. DXVA. They've been doing this for quite some time.

Comment

I too have created a username specially to decloak and have a rant. I would like to share my real-world experience with being a developer on an Open Source project (I worked on a fairly complex video project on Sourceforge).

I don't much believe in cloaks. It reminds me that I'm not living in some bubble world of my own when in the middle of my rant airlied on a bad mood happens to step in and disagree rather colourfully.

Comment

If you remember I asked you back in February about the "Plan" for the oss driver, i.e. what will/is going to be the schedule for development. I know that you can't give release dates for the features, but a continuously updated ETA would be still helpful. The order in which the features will be implemented is in my opinion _essential_! Having that you guys might have been able to avoid these type of threads...

I think about something like this:
...
- openGL 3.x: we first need it to be implemented in mainline mesa, afterwards it should take about 2 months so you might expect it around October
...

Comment

...
- openGL 3.x: we first need it to be implemented in mainline mesa, afterwards it should take about 2 months so you might expect it around October
...

That's way way too big as a single step if you want them ever talking to us and you have to understand what OpenGL 3.x consists of so them telling which components are ready, which are soon ready and which are a real bugger to write makes any sense to you.

Comment

That's way way too big as a single step if you want them ever talking to us and you have to understand what OpenGL 3.x consists of so them telling which components are ready, which are soon ready and which are a real bugger to write makes any sense to you.

Yeah, I'm not competent in these questions. My point was that general end-users (like me) would be interested in things like this. So a year ago it would have read something like this:
(again, I'm not too competent)

- power management: we need stable kms in the kernel and then figure out how we should implement it so expect 3-6 months after kms is out of staging