For this specific issue (making dynpm work on a broader range of systems) yes, in the sense that the hardware programming is already done and the problems are related to *when* that programming is done. There are basic PM functions common across multiple generations and that information has been in use for a couple of years -- other functions are specific to single generations of GPU and are not documented yet; some are used, others are not, and we're looking at which ones are worth documenting/supporting.
Yeah, it may be that simple, at least for PM. I don't remember seeing that in the proposal but it's good advice anyways.
The existing documentation is still relevant right up to NI, and the ISA docs from the GPGPU group (former ATI btw) cover most of the shader core differences between generations. My understanding is that even with the ISA docs the information on doing attribute interpolation in the shaders is still a bit thin, so we need to go back and document some more there. SI (aka GCN) is really where we need the next big slug of documentation, and that is being worked on now.
Harsh, but good question. 'Cause it will determine my next buy, as in near future, me and friend wanna buy new comp.Are you interested in selling cards for Linux desktop market or not.
Oh, and.. 1 thing that these manufacturer doesn't seems understand (or forget, maybe?) is: LINUX {geek} here, although minority, have many people asked them for recommendation about hardware (or laptop) they ought to buy. So, you can said that 1 geek here not just represent him/herself, but, say, represent at minimum 10 person. Translate to: when these manufacturer dissapointed their LINUX {geek}, they lost 10 other at minimum..
But then again, I think they can't see it this way![]()
That means 10% instead of 1%, we are still a minority![]()
The r600 LLVM backend can be used for graphics too, and it comes fairly close to matching the current r600 compiler as far as number of piglit test passes. It is just missing support for some of the texture instructions and a few other things. It should produce much better code than the current r600g compiler once it makes use of the LLVM VLIW packetizer, which is something that I'm hoping will be done as part of the Open Source compute effort. Adding support for the texture instructions shouldn't be too difficult of a task. It is not a priority for me at the moment, but someone else from the community could easily do this if they were interested.