More GLAMOR Changes Pushing For Performance Wins
Phoronix: More GLAMOR Changes Pushing For Performance Wins
Eric Anholt has published another major series of patches for GLAMOR...
For everyone who wants to know which changes are likely to come next, just check out anholt's glamor-server branch: http://cgit.freedesktop.org/~anholt/...=glamor-server
question about X future
Please tell me if I am more or less groking these developments correctly:
I have been an avid X follower since I first tried to run X back in '94. What a long strange trip it's been. With these latest changes in GLAMOR it seems as if the new entry level bar for X is whether or not one has a driver/hardware with a conformant OPENGL/EGL implementation. Given that now most drivers/hardware have such a conformant implementation the X devs can now start to re-write X from the ground (apparently starting with the old fixed function X primitives). A lot of us have been worried about the shitft to wayland, X looking more and more like something being relegated to the dustbin of history. Despite reassurance that "nothing of value was lost"(TM) a lot of us have been left wondering what, if any, future X has. This latest work seems to indicate that perhaps X still has a future. Gone are the days of fixed-funtion hardware sprites. 2D is at best an after-thought in modern GPU's, everything having shifted to programmable 3D functionalty. But old X was still bit banging primitives via horifficaly complicated DDX's(the older generation of X drivers for fix function 2D graphics cards). Toolkit authors (QT/GTK+/EFL etc) had effectively done an end-run around X, relegating X to at most an outdated network protocol for pumping out the finished results(all the drawing nowadays appears to be done in offscreen memory and only the finalized image gets written to the display after being composited). So X had been left standing in the cold as modern GPU's went totally 3D and toolkit authors cirumvented all the original X primitives in lieu of composited rendering. But now that conformant OPENGL/EGL implementations are commonplace, it is time to throw out the cruft and re-architect how X works. Wayland struck me as throwing out the baby with the bathwater. But if via GLAMOR now all the old 2D infrastructure can now be relpaced with OPENGL/EGL, could this not lead the way to a new rennaisance of X?
From my understanding it seems as if these developments could lead to radical simplification of driver design and in general just a whole lot less work for driver developers, X maintainers and toolkit authors. If I am right about this this seems to be an absolutely awesome development. Now folks just have to make sure they get a conformant OPENGL/EGL implementation. If X is re-written to use this and the X protocol is adapted to reflect these changes(perhaps someday X12?) then the toolkit devs will be using the same tool chest that the X uses, potentially meaning much much less work for toolkit authors. I know that X on the network has been breaking, so many unnecessary round-trips and horribly out-of-date image formats and format conversions, having worked for years with LTSP and the GNOME desktop things still worked but not as efficiently or smoothly as should have been the case. Not exactly surprising considering how the only thing left on modern systems running 2D primitives was the X server, for neither modern GPU's nor toolkit authors made use of that stuff anymore. But with a new high-level implementation of all the old 2D stuff using 3D OPENGL/EGL could we not re-archictect the protocol to be much much smarter and more efficient?
Just really curious if this kind of work heralds the second comming of X? could we, perhaps in 2-3 years, be looking at X as an again current viable model for the next x years ? Nothing really against Wayland, but it would be so awesome if we could keep the legacy of X going forward. Again this seems to be possible because the manpower required to do so seems to be infinitesimally small going forward-no more arcane DDX's for hundreds of different legacy fixed function hardware devices, no more total disconnect between toolkit authors and the "native" language of X (ie. it's primitives), could this not mean that the work previously done by perhaps 100 or more so dev's could be handled by a mere handful?
I am probaly missing a lot, and overly enthusiastic but it seems these developments bode well for the future.
Please chime in If I am sorely off base.
I think you're looking at the results of things and positing certain forward development rather than seeing these results as having occurred because of development moving in a different direction.
Originally Posted by iwbcman
X isn't going away but, in a sense, X has been gone awhile already. They've stripped so much out of X that it is far from conformant with the X of 15 years ago. There seems to be a strong effort to give X users an experience to Wayland that is as close as possible in result. You see this with the use of dmabuf, dri3 and present. However, don't take this to mean the plan is to sick with X. As the developers have said, you can think of Wayland as X12 since that is how it is intended.
X12 is never coming. The entire point of staying with X is to keep backwards compatibility. Once you break that, you may as well fix all the broken stuff that's been around forever and you end up with Wayland.
Originally Posted by iwbcman
So in that sense, Wayland is X12.
I do think there's been an effort lately to port back a lot of Wayland's benefits into X11. DRI3 and Glamor are important parts of that.
I think there is a faction of people who aren't sold on Wayland yet, and think that even if it does happen X is going to be important for at least another decade, and they are probably right about that from an enterprise OS standpoint. It's really the linux desktop market that Wayland is going to quickly become important in, and it's very questionable how important that market segment really is.
iwbcman: imo glamor isn't and shouldn't be the next X11. There is no need in this kind of 2d acceleration api which itself is implemented on top of OpenGL. Just use eg cairo for such application. But this is a way to still support all old x11 application when nobody else care about x11 at all.
Not in the way, you're suggesting it.. What you forget is that you must think first about the developers not the SW.
Originally Posted by iwbcman
Current X developers want
1) to fix X "as it is" for compatibility: to make it work with minimum modifications: so they simplify code, etc.
2) to replace it by going with a much simpler framework (Wayland) pushing the complexities in the toolkits, as the toolkits doesn't use X features as they should and re-invent the wheel instead it's not really a change..
It's a bit of oversimplification as there is DRI3, but they still want to make minimum changes in X, I don't remember any X developers pushing for X12..
Going from X to Wayland, network transparency may be less efficient, *IF* it is really an issue (to be seen) and *IF* some developers want to fix it then they will have to add remote rendering features in the toolkits (cannot be in Wayland as it doesn't have the information needed), *that* would be 'X12'.
Oh X and its network transparency.....
The only thing that is network transparent on X is the commandline.
-X for virtually any program results in X sending uncompressed bitmaps over the network.
With wayland they are working on it sending delta changes only while also using compression for sending graphical program data over the network.
Wayland should actually work better (when they finish it) for accessing remote graphical applications than X.
Thank you ua=42...
Originally Posted by renox
Renox, they already have Network Forwarding under development for Wayland, furthermore Network Transparency is actually X's absolute worst usecase given how latency heavy X is and how many round-trips it has to do. Also X is FAR from Network "transparent" as any application that uses DRI2 or DRI3 cannot forwarded in the 'usual X way.' Modern X is network capable, it is not network transparent.
1) this is more a toolkit issue than an X issue.
Originally Posted by ua=42
2) there are different ways to send bitmap over the network: for text X can send the bitmap of each glyph used once and then reuse them each time you print text,
Wayland cannot do this.
Is-this particular optimization important or not? We'll have to wait and see..
Doing a diff between bitmaps is a "brute force" solution heavy on CPU/GPU use,
sometimes brute force solutions works well though.
Is-it going to be good enough or will toolkit level solution be needed?
Same we have to wait&see..