Page 7 of 9 FirstFirst ... 56789 LastLast
Results 61 to 70 of 88

Thread: AMD Has Open-Source Driver For HD 8000 Series

  1. #61
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    936

    Default

    New (real) HD8000 ASICs delayed to Q4/13? O_o

    http://www.tomshardware.com/news/Rad...000,20979.html

    That at least should give AMD the relastic chance for first-day (FOSS) driver support... :/

  2. #62
    Join Date
    Aug 2012
    Posts
    245

    Default

    Quote Originally Posted by curaga View Post
    It's an unnecessary layer, therefore always causing a lag of at least one frame compared to not using one.

    Being a programmer I don't like unnecessary layers in general - being sensitive to latency I don't like unneeded delays.


    To put it in another way: an unnecessary layer that has only downsides to me, I have no use for wobbly windows, shadows, or any other effect of the week.
    It happens that Wayland is not a compositor, but a display protocol and a library with the implementation of said protocol. While I haven't been involved in its creation or anything, it is my understanding after watching various videos of presentations from its developers and doing some reading on it, that is of no concern to Wayland how it is created, but it expects an image/buffer to display to the screen. Whether extra layers are involved is up to the so called "compositor"(this is basically the new X). Currently you have the X server and a window manager(except if you run X alone, which I doubt). What the window manager does is basically the role of a second display server. If that is not an added layer, I don't know what is ..(Btw, you should watch some of the videos regarding Wayland that were posted recently). The window manager has to communicate with the X server to do its thing, then get a reply(which may or may not come fast) and then communicate again, adding many unneeded delays, as well as the X server doing thing it doesn't need, like painting on regions where it shouldn't in a buffer because the wm is going to paint right after anyway. Xorg seems to be the king of delays. For example tests with Chromium show a delay of at least ~500 ms in startup, only because it waits for Xorg doing nothing, but it is blocked because of Xorg doing random thing it doesn't need to do.(That's an example, not a corner case, in case you think that) And as mentioned, this a minimum, this delay is variable, and can easily reach 1500 ms. (There are actually issues with Xorg that have been deemed as impossible to solve by its developers).
    If it is delays you are concerned of, you should in fact welcome Wayland, since it takes as many of those away as possible. My limited testing shows that Wayland with compositing is actually faster(not talking about frames per second) and more responsive than a wm without compositing under Xorg.
    Also Vsync and tearing seem to be much better in Wayland. Practically no tearing with much less overhead.
    Because Xorg is not good at all at compositing, doesn't mean that compositing is bad in any way. And Wayland can still run fine with software rendering. Besides, if we were to not add any "layers" that we don't need, every program would be an OS too. In the case of Wayland you practically have less layers. Now, if what concerns you is not that, but something like the name of Wayland or whatever, that another issue. Wayland is Xorg developers correcting their mistakes basically.

  3. #63
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,329

    Default

    @Rigaldo

    Please note I was not comparing X to wayland - I was comparing apples with apples, ie compositor on X vs no compositor on X.

    Wayland likely does outperform non-composited X, but that does not mean compositing is not an extra layer. But since wayland forces compositing, we have no way to compare a compositing wayland and a non-compositing wayland.


    But back to the point.

    Without a compositor, when an app draws, it goes straight up the pipeline. With a compositor, the app's window contents go up to the compositor, which then decides whether to send it along or to do some effect with it. This is the definition of a compositor, pretty much. Do you not agree that it's extra lag when one does not need the effects? Purely as an approach, not involving X, wayland or anything else in the question at hand.

  4. #64
    Join Date
    Aug 2012
    Posts
    245

    Default

    @curaga
    I guess I went too far. Under X, indeed, compositing would bring more lag(at least most of the time).
    My point was that is more of an X limitation than a compositing one though. Compositing can ba faster with a good implementation. It's not exactly an extra layer on top, you don't take into account a good deal of things simplying it like that cause it's quite different and leverages the GPU better(I'd rather it doesn't sit around when I have it) and even "solves" some issues that don't have to do with effects, like better control over syncing(and tearing).
    But anyways, (in regards to the initial comment, to write something more constructive too) a wm like xfwm4 could likely help, which can do compositing and be pretty lightweight and fast still. I haven't extensively tested it, but I tried it(a few weeks ago was last time) and I recall it doesn't have any effects by default and shouldn't lag more than a stacking window manager(many wm's can have effects disabled though, but this one should be faster). Maybe it would be better in regards to tearing for now. You are forced to you a compositor, but it shouldn't be too bad.
    I'm personally "forced" to use much worse stuff to have a decent linux experience.

  5. #65
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,570

    Default

    Quote Originally Posted by curaga View Post
    Without a compositor, when an app draws, it goes straight up the pipeline. With a compositor, the app's window contents go up to the compositor, which then decides whether to send it along or to do some effect with it. This is the definition of a compositor, pretty much. Do you not agree that it's extra lag when one does not need the effects? Purely as an approach, not involving X, wayland or anything else in the question at hand.
    Making a tear-free driver that works without a compositor involves doing pretty much the same thing -- either implementing what amounts to triple buffer support (one being drawn, one being displayed, and one waiting for the next flip) or delaying drawing operations until an appropriate window in the display refresh cycle. Either way you're getting lag, the only question is whether you get "straight" lag or hide composition in the lag that pretty much has to happen anyways.

  6. #66
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,329

    Default

    Quote Originally Posted by bridgman View Post
    Making a tear-free driver that works without a compositor involves doing pretty much the same thing -- either implementing what amounts to triple buffer support (one being drawn, one being displayed, and one waiting for the next flip) or delaying drawing operations until an appropriate window in the display refresh cycle. Either way you're getting lag, the only question is whether you get "straight" lag or hide composition in the lag that pretty much has to happen anyways.
    Having the driver wait for scanline is less lag than a compositor, because in the earlier case there is no extra mem copy. With a compositor, there is.

    The lag of a mem copy should nearly always be greater than that of waiting for the scan line to pass.

  7. #67
    Join Date
    Aug 2008
    Location
    Tokyo, Japan
    Posts
    39

    Default

    Exactly, there is no way to completely avoid tearing without some form of compositing. So 'no tearing' and 'no compositing' are conflicting requirements.

  8. #68
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,329

    Default

    Quote Originally Posted by MrCooper View Post
    Exactly, there is no way to completely avoid tearing without some form of compositing. So 'no tearing' and 'no compositing' are conflicting requirements.
    Perhaps you missed my post above - the scanline wait removes tearing, while being lighter than a compositor, no?

  9. #69
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    542

    Default

    Quote Originally Posted by curaga View Post
    Perhaps you missed my post above - the scanline wait removes tearing, while being lighter than a compositor, no?
    What about scan line is about to start, but the app haven't refreshed its entire framebuffer. You still have tearing, this time it is per app.

  10. #70
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,329

    Default

    Quote Originally Posted by Drago View Post
    What about scan line is about to start, but the app haven't refreshed its entire framebuffer. You still have tearing, this time it is per app.
    I assume the scanline wait code is smart enough to calculate the needed time and to avoid the scanline catching up in the middle of a transfer.

Posting Permissions

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