Originally posted by Drago
View Post
There are some other requirements like GL overlays (for floating a UI over a full screen model) but I think it's the first two that require a big development effort.
Originally posted by Drago
View Post
The key point here is that a code-shared proprietary driver allows us to write the 3D code once and use it across multiple OSes, while providing the same functionality and performance on an open source driver requires doing all the same work again on a separate implementation, and it's a *lot* of work.
Originally posted by Drago
View Post
Everyone would benefit from full dynamic power management and that's what we're working on, but we knew that would take time. I felt that in the meantime it would be possible to make some reasonable guesses for "mid" values on cards which didn't have those entries, so at least everyone would be at the same level rather than the current state.
The trap everyone falls into is thinking that it's an either-or choice, ie working on a short term solution delays a better long term solution. It would if the work was being done by the same people (and that's why I didn't ask our devs to work on improved static PM, or at least didn't push very hard), but community work on static PM would not slow down AMD work on dynamic PM.
Dave's main point (which was correct) was that community work on static PM *would* slow down work on other areas where the work would not be throwaway; he weighted the "throwaway" aspect a bit more highly than I did which is totally fair.
Leave a comment: