Recent Features
| |||||||||||||
LCA: The ways of WaylandLCA: The ways of WaylandPosted Mar 17, 2013 9:51 UTC (Sun) by Serge (guest, #84957)In reply to: LCA: The ways of Wayland by Cyberax Parent article: LCA: The ways of Wayland
>> They have 2D XRender acceleration if they can be used to accelerate XRender drawing compared to CPU-based software rendering.
That was supposed to be a definition of "acceleration".
> No. They. Don't.
Obviously you have your own understanding of the word "acceleration" too. Can you explain what would you call "accelerated xrender" then?
> Besides, you've missed the part about threading - XRender in X.org works in a single thread for ALL clients. Do you think it's a good design?
First, as long as you have a single videoadapter having a single thread to work with it is perfectly fine. Second, as long as Xorg uses less than 100% CPU, yes, single-threading is the best design, because it makes X-server faster. Third, that's not a limitation of X11 protocol, you know? And finally, Wayland/Weston is also single-threaded.
> I think that X should be killed with fire as soon as possible. It was THE greatest stumbling block for Linux users for a long, long time (XF86Config - ugh).
Yeah, I understand that, but I don't understand your reasons. If the problem was in Xorg bugs then the best option would be to fix Xorg or write another implementation of X11 protocol (there're many of them). Since you prefer Wayland instead there should be some fundamental limitation of the X11 protocol itself that can't be fixed by different implementation.
You should be saying where Wayland is better, instead you're mainly saying what you don't like (or rather don't know) about X. Every time you said that Wayland has some feature while X has not, it appeared that X actually has it but you didn't knew that. Or worse, that X has it, while Wayland has not or it's useless there. The rest of your reasons were just childish excuses like: "Look, at the Wayland code! 'd->gbm'. Do you think that calling variable 'd' is a good design? Wayland should be killed with fire!"
If all your reasons were wrong then why do you still hate X? Have one of X devs stepped on your foot?
(Log in to post comments)
LCA: The ways of Wayland Posted Mar 17, 2013 10:15 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
> Obviously you have your own understanding of the word "acceleration" too. Can you explain what would you call "accelerated xrender" then?
Something that doesn't really exist. Modern videocards don't have any intrinsic way to accelerate drawing of thick lines (especially with antialiasing), so X-server has to do it in software. Of course, thick lines and everything else can be emulated in shaders but as far as I know, no driver in X.org does this.
> First, as long as you have a single videoadapter having a single thread to work with it is perfectly fine. Second, as long as Xorg uses less than 100% CPU, yes, single-threading is the best design, because it makes X-server faster.
>Third, that's not a limitation of X11 protocol, you know?
>And finally, Wayland/Weston is also single-threaded.
>The rest of your reasons were just childish excuses like:
LCA: The ways of Wayland Posted Mar 17, 2013 13:24 UTC (Sun) by Serge (guest, #84957) [Link]
>> Can you explain what would you call "accelerated xrender" then?
> Something that doesn't really exist. Modern videocards don't have any intrinsic way to accelerate drawing of thick lines (especially with antialiasing), so X-server has to do it in software. Of course, thick lines and everything else can be emulated in shaders but as far as I know, no driver in X.org does this.
Many (most?) Xorg drivers use shaders. And that's not a problem of X11 protocol, not even Xorg problem, that's a problem of good drivers implementation. Drivers are the best place to implement hardware-specific optimisations. It's much better than having every software to carry all the possible hacks for all video adapters in the world. Unfortunately you don't have such option in Wayland.
> X.org can use 100% of CPU in graphics-intensive apps.
Sure. If it was multithreaded it could use 1600% CPU. But in real world it does not. So single-threaded design is better here. "Do not add new functionality unless you know of some real application that will require it."
> It is. There is exactly ONE implementation of X protocol with XRender extension.
Really? Xfree86, Xorg, Kdrive, Xwin32, there're even VNC servers supporting it.
> clients can happily render the next frame while Wayland is processing the request to render the current frame.
You can use Xorg this way too. The difference is that you CAN do that on Xorg, but you HAVE TO do that on Wayland.
> If you haven't noticed, I've just used your logic for these reasons.
I haven't. My logic is simple: Wayland adds more work to people, lacks lots of features, but fixes no X11 problems and nobody wins from Wayland.
LCA: The ways of Wayland Posted Mar 17, 2013 18:09 UTC (Sun) by jrn (subscriber, #64214) [Link]
> nobody wins from Wayland
Clearly its developers win, or they wouldn't be developing it. ;-) It looks like a neat project and I am happy to see it move forward.
LCA: The ways of Wayland Posted Mar 18, 2013 10:25 UTC (Mon) by nix (subscriber, #2304) [Link]
The project could do with better defenders than Cyberax though. He doesn't know what he's talking about and his debating strategy appears to consist mostly of goalpost-shifting.
LCA: The ways of Wayland Posted Mar 18, 2013 11:40 UTC (Mon) by anselm (subscriber, #2796) [Link] Possibly the people who are really knowledgeable about X11 and Wayland and the state and roadmaps of the respective projects have more important things to do with their time than to engage into pointless back-and-forth on random web sites. It's not as if Serge was a much better debater than Cyberax, either.
LCA: The ways of Wayland Posted Mar 18, 2013 21:43 UTC (Mon) by nix (subscriber, #2304) [Link]
True enough! I'm not saying that choosing to do actual development rather than comment wars isn't a totally sensible decision :)
LCA: The ways of Wayland Posted Mar 18, 2013 12:10 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
> [...]his debating strategy appears to consist mostly of goalpost-shifting.
this coming from you is more than ironic ;). pot meet kettle!
LCA: The ways of Wayland Posted Mar 18, 2013 21:44 UTC (Mon) by nix (subscriber, #2304) [Link]
I don't shift goalposts intentionally. I just have a crap memory for these conversations and don't check past posts often enough. :)
LCA: The ways of Wayland Posted Mar 18, 2013 10:24 UTC (Mon) by nix (subscriber, #2304) [Link] Something that doesn't really exist. Modern videocards don't have any intrinsic way to accelerate drawing of thick lines (especially with antialiasing), so X-server has to do it in software. Of course, thick lines and everything else can be emulated in shaders but as far as I know, no driver in X.org does this.There's a reason for that. It's pointless. Almost no applications draw thick lines anymore, just as almost no applications use the ROPpery in the core protocol. TBH, while it would be nice for my BARTS Radeon card here to have XRender acceleration as good as my old Matrox had, it's also pointless: the card is so fast that except in its lowest-power mode a full-screen refresh of two 1680x1050 monitors filled with tiny text composited onto a bitmap backdrop is instantaneous (I clocked it at 35fps in medium-performance mode, 60fps in high). Visible latencies happen only if the glyph cache fills up -- which hardly ever happens these days, I notice it once every few months -- and that's a latency imposed by the sloth of moving data into the GPU, which can hardly be fixed by ditching XRender's glyph caching and moving even more data across the bus. You appear to be saying that XRender should be killed with fire because it can't be accelerated, even though I would require a prosthetic visual cortex to see the results of any such acceleration, and even though the only thing you've recommended replacing it with would exacerbate the only thing left in XRender that ever causes visible delays in my experience. Thanks, but no thanks. >Third, that's not a limitation of X11 protocol, you know?You clearly didn't understand Serge's point. The protocol does not mandate lack of acceleration: indeed, in the past, at least one driver has implemented it. So the current ONE implementation does not make it impossible to accelerate XRender. (In fact, one of the problems with XRender is that it needs too much support code inside the drivers. If there was "ONE implementation" this would actually be better than what we have now.)
LCA: The ways of Wayland Posted Mar 18, 2013 22:06 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> So the current ONE implementation does not make it impossible to accelerate XRender.
No, but it's the exception that proves the rule, that XRender isn't a good fit for how GPUs work.
LCA: The ways of Wayland Posted Mar 18, 2013 10:16 UTC (Mon) by nix (subscriber, #2304) [Link] First, as long as you have a single videoadapter having a single thread to work with it is perfectly fine. Second, as long as Xorg uses less than 100% CPU, yes, single-threading is the best design, because it makes X-server faster.This is guaranteed true only if the GPU is also single-threaded and the X server does nothing but talk to it: but the GPU is massively parallel, and the X server does a lot of things other than talk to it. However, in practice, locking overhead seems to dominate if you try to parallelize the existing server. (It's been done, in the 1990s. It didn't scale, even then, when the memory hierarchy was less hostile to such things than it is now. There's a reason that even the mouse driver works as it has always worked, via SIGIO in a single thread.)
|
|||||||||||||