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... :/
Printable View
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... :/
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).Quote:
Originally Posted by curaga
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.
@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.
@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. :cool:
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.Quote:
Originally Posted by curaga
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.Quote:
Originally Posted by bridgman
The lag of a mem copy should nearly always be greater than that of waiting for the scan line to pass.
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?Quote:
Originally Posted by MrCooper
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.Quote:
Originally Posted by curaga
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.Quote:
Originally Posted by Drago