Page 57 of 111 FirstFirst ... 747555657585967107 ... LastLast
Results 561 to 570 of 1109

Thread: "Ask ATI" dev thread

  1. #561
    Join Date
    Sep 2007
    Location
    Paris, France
    Posts
    217

    Default

    Quote Originally Posted by bridgman View Post
    Nope, I haven't answered it 'cause I don't know the answer

    I will try to find out though, but probably not today.
    Thanks a lot in advance for your search !

  2. #562

    Default

    @bridgman: Three questions i hope can legaly(and moraly) answer.

    1) Back in October UVD was enabled in the catalyst driver for linux. While you have made it evident that it isn't official yet, could you give us an estimate on when we can expect official UVD in the catalyst driver?

    Just something like "imminent, first quarter of 2009, hopefully by xmas". I'm not asking for an exact date to pin it on, just a general idea of where in the process AMD currently are.

    2) Have the UVD specs for the r700 series been released with the 3d specs? Will they be released or are there copyright/patent issues that will prevent this from happening?

    3) Have AMD made any consideraton towards moving to VA-API?
    With the current delay i'm thinking you might be changing the interface to be VA-API compatible. Which would, imho, be a good idea(shared interface with the intel drivers, is already implemented in ffmpeg/mplayer).

    Hope i'm not imposing too much with these questions.

    Sincerely
    Tobias Ussing

  3. #563
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    Quote Originally Posted by TobiasTheViking View Post
    1) Back in October UVD was enabled in the catalyst driver for linux. While you have made it evident that it isn't official yet, could you give us an estimate on when we can expect official UVD in the catalyst driver?
    Quick answer is "I don't know". Yet.

    Quote Originally Posted by TobiasTheViking View Post
    2) Have the UVD specs for the r700 series been released with the 3d specs? Will they be released or are there copyright/patent issues that will prevent this from happening?
    The recent info release was focused on the info required to use the 3D engine. This was really important because on 6xx and higher the 3D engine is used not just for video render and 3D acceleration, but for 2D acceleration as well. I have not really looked at UVD yet to determine if it is feasible to add it to the release plans; next on the list is 6xx/7xx power management, then we'll look at UVD after that. I'm trying to keep us focused on the info we said we *would* release for now

    Quote Originally Posted by TobiasTheViking View Post
    3) Have AMD made any consideraton towards moving to VA-API? With the current delay i'm thinking you might be changing the interface to be VA-API compatible. Which would, imho, be a good idea(shared interface with the intel drivers, is already implemented in ffmpeg/mplayer).
    I don't think there are any plans to change the current API for fglrx. As far as I know adding support for another API to the players/decoders is not a big deal as long as the API itself is reasonable.

  4. #564

    Default

    To all three points:

    Fair enough... thanks

    One follow up question.

    When the UVD support becomes official, i suspect that will include full API interface and instructions on how to use it. But do you know if anyone have been doing any internal patching of software(ffmpeg/mplayer) to test it out, and if so, will that be released?

    I realise you may not know the answer to that, or may not be at liberty to say. Still, i really wanna ask

    ETA: I'm very impressed with your response time.

  5. #565
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    I should probably stay away from that one, sorry.

    We generally don't talk about unreleased features in fglrx, although I will cheerfully talk about our open source plans

  6. #566

    Default

    You are just saying that to make me happy...


    But please, do go on

  7. #567
    Join Date
    Dec 2008
    Posts
    12

    Default

    I did a quick search of the thread and didn't seem to find this..

    ATI (IMO) has picked some really poor defaults for overscan.. my 1920x1080 LCD, connected over HDMI, was defaulting to a display area that was ~1776x1000, even tho I picked 1920x1080 in the resolution settings in CCC.

    The Windows version of CCC has overscan controls, none in Linux.

    a) when will linux CCC be brought to parity with the Windows version in terms on controls it offers? (and isn't overscan a pretty basic function to include, esp given the choice of default?)
    b) why would you pick such a large overscan as the default for a digital video output?!?!

    It makes quite an initial (negative) impression, especially b/c the commands (via ati-config) are not the simplest (the "tv" overscan commands look more applicable to someone new to ATI, and they have no effect)

    thanks,
    Mike

  8. #568
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    I suspect the underscan amount was picked to match the overscan amount that some TVs were using by default, to ensure that the user could always see the menu bar. We definitely need an easy way to turn the underscan off though... default underscan is a real convenience for new users but only if you can turn it off.

  9. #569
    Join Date
    Feb 2008
    Posts
    28

    Default

    Quote Originally Posted by bridgman View Post
    The ability to pop a new tab in IE by clicking on the stub tab at the right of the active windows is really nice and I use it a lot, which is a point in favor of IE/Vista over Firefox/Linux.
    Double left-click in an empty part of the tab bar on Firefox 3.x. I'm pretty sure that's configurable too.

  10. #570
    Join Date
    Dec 2007
    Posts
    25

    Default

    Hi Bridgman! I have a little question that appeared on the IRC channel while I was chating with cxo...

    Would it be posible to implement some kind of closed source library (like the intel_hal.so) with the opensource driver? AMD/Ati could put all the effort in this library instead off fglrx and also this would speed up the open source driver development.

    Personally, I think that and AMD/Ati would benefit because the driver will be compatible with all distros, very stable and you cuold implement special top secret features (like 2D and 3D Optimizations for workstation users) into the binary library (which would be optional to the normal user, except if they want to use UVD). This would be like the libva structure, an opensource api with a binary library.

    I have been thinking about this from the first time I read this article on wikipedia: http://en.wikipedia.org/wiki/Intel_GMA#intel_hal.so

    Thanks for all your attention and support to the opensource community...

    EDIT: This topic is also being deliberated on the Open-Source AMD/ATI Linux forums in this thread
    Last edited by rainbyte; 02-05-2009 at 07:03 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •