Xv2

Xv2 is a hypothetical family of two updates to support video displaying that isn't Xv.

• Render: Allow dest-only pictures, add YUV formats
• Randr: Add overlay objects beside CRTCs: enable, disable, property mangling, mandatory formats supported and acceptable CRTC mask properties, as well as a 'current backing Picture' property. Drivers wrap Render context creation and set ShmPutImage/Composite to their former Xv paths. Port properties become Randr overlay properties.

Rambling IRC braindump

I should clean this up and summarise, but right now it's here for posterity. Also encompasses server development, future driver API, and future render API discussions.

< ajax> exa is giving me vertigo
< daniels> maybe if we do fold the drivers into the server to start smashing up the api, people won't notice drm because it'll still be two steps.  win.
* daniels draws for the epsom salts.
< ajax> i think i'm just going to smash the api and tell people to cope
< ajax> doing shatter well essentially requires breaking the ScreenRec
< daniels> ajax: i was thinking more along the lines of actually creating an api first.
< ajax> daniels: madness.
< daniels> as opposed to, y'know, what we have now.
< ajax> yeah we should have one of those, shouldn't we.
< daniels> if we say in advance that 7.6 + 2.0 are going to be this big break and that master may not always be buildable due to active development, then i think we can more than get away with it.
< ajax> i've been hoping to slowly morph towards having something sensible, but i might be losing patience
< daniels> ajax: right, but morphing from here to there essentially requires creating an api, no?
< ajax> daniels: evolving, but yeah.  the advantage being that you don't have to hope you design it right up front
< ajax> which we are manifestly shit at
< ajax> HI MEMORY MANAGER HOW ARE YOU
< daniels> of course there are still renovations like the i2c api of shame, but most of it is going to be fbScreenInit + mangle masks + gamma init + picture init + randr init + create visuals list + OH GOD I DON'T CARE -> xorg_create_a_screen_for_the_love_of_god())
< jcristau> which one? :)
< daniels> ajax: oh god no.  it comes organically or it comes xkb.
< daniels> ajax: but i get the sense that a new api is mostly going to look like a new header file with a whole host of new functions which replace almost all the old functions (and then your mode + video + etc helpers)
< ajax> also, you're talking about driver api, and i'm talking about rendering api.  they're related but not identical.
< daniels> yes, that also.  that's not on my immediate hitlist though.
< daniels> what did you have in mind?
< daniels> (also, our input driver api is, surprisingly crap.  need to fix that, and lift a raft of stuff into the dix.)
< daniels> InputDriverRec + IDrvRec + maybe DeviceIntRec if you're lucky -> OH GOD NOT THE FACE
< ajax> we still expose basically the whole gc/picture/xvctx to the driver.  drivers shouldn't have to know about the protocol's semantics, we should be giving them a much smaller rendering task.
< daniels> \o/
< daniels> exa isn't tooo bad in that sense though.
< ajax> it's better but still not good
< ajax> the Picture is a disaster of a struct
< daniels> i don't know if you know, but in x terms, that's called a celebration.
< ajax> the _one_ thing that the core rendering model got right is that the chalkboard is not the chalk
< daniels> the what isn't the what?
< ajax> the GC isn't the Drawable
< ajax> but in the Picture they're bound together
< daniels> yeah, they did get the model right there.
< daniels> heh.  progress!
< daniels> hmm, i should fix up render-arg-reduction if we're breaking this api anyway, because seriously.
< daniels> gtkperf got something like 33% in some tests just from fb-internal arg reduction, not even the entire chain.
< ajax> render-argh-reduction
< daniels> (hi! my name is arm! please don't have 12 arguments for deeply-wrapped functions, because it makes me sad.)
< ajax> x86 doesn't like it either, for that matter
< ajax> we just hide it with l1
< daniels> sure, but the overall performance penalty isn't so bad.
< daniels> right.
< daniels> plus a hojillion more cycles per second.
< ajax> so yeah.  render and xv need proper contexts, and so does the Screen for getimage and possibly the implicit window rendering shit.
< ajax> which i'm considering tossing altogether and just forcing CompositeRedirectAutomatic
< ajax> (or equivalent semantics)
< ajax> i hate the window rendering rules so very hard
< daniels> meh, if you're doing that, just add YUV formats to Render and implement Xv as a wrapper for that.
< ajax> it's not clear how you keep the overlay fastpath for that
< daniels> plus, is there any reason _not_ to force automatic redirection? all the consumer-device kids are getting on compositing (including us), so that's the main argument gone ...
< ajax> depends how much memory pressure you're willing to accept, i guess
< daniels> ajax: overlay> how not?
< daniels> i guess you'd need a way to route to ports, but that gives us a one-extension xv.
< daniels> 'bind this render yuv texture to this overlay', which also lets you deassociate.  that's grabport and stopvideo in one, and putimage is nothing if not composite dst.
< daniels> dberkholz: oh?
< dberkholz> on one hand, we're assuming people are running distros by defaulting to black
< daniels> s/one-extension/one-request/
< daniels> okay, listports and port properties.  blah blah i'm not listening anymore.
< daniels> or, wait.  randr! aha.  every gpu gets some overlays, which can have an acceptable crtc mask.  so we punt the hard decisions to the client.  win.
< daniels> ajax: anyway, so.  render gets yuv picture support.  randr gets overlays at the same level as crtcs, and behave like them (enable/disable/props), but also have acceptable crtc & format masks.  you have one request to bind a picture to a port, and rendering is just composite.  sound okay?
< ajax> what do you composite _to_?
< ajax> i guess have an internal picture type that means "overlay port"?
< daniels> well, you've given render a GC, so at context creation time, you set Composite to your overlay path if it's an overlay.
< ajax> heh.  dest-only picture.  yeah, that sounds plausible
< marcheu> the major difference between xv and yuv render is the semantics. and we need it to optimize the upload
< ajax> you just don't expose that picture type to clients through render
< daniels> you even get to use the general fb code, because dst with no mask is easy.  if they want to alpha-blend on the client side, they can cop the slow path.
< ajax> marcheu: ShmPutImage not enough for you?
< ajax> daniels: i guess the one remaining bugbear is "magic encrypted content stream" as a picture format.  but that should be fine, just looks like another format.
< daniels> marcheu: i don't see how it's a problem if you have shm and you get a say in ctx creation? if it's on an overlay, wrap ->ShmPutImage and ->Composite and set them to your fastpaths.
< daniels> ajax: PICT_BULLSHIT32
< marcheu> ajax: getting the best performance is quite card-dependent
< daniels> ajax: specified as always passing through unmolested, and any attempt at manipulation fails.
< daniels> marcheu: ... and?
< daniels> marcheu: i just don't see how this is even remotely different from the Xv api.  you could even make it look exactly the same if you wanted.
< marcheu> well then you have to keep the xv api, basically
< daniels> ... why?
< ajax> yeah, i was anticipating leaving Xv in place as the only thing allowed to create dest-only pictures
< marcheu> because if you keep the semantics, you might as well keep the api
< daniels> marcheu: you _can_ keep the semantics.
< ajax> (well, not the only thing, but as an api compat thing it'd be desirable to keep)
< daniels> ajax: i don't see how it's too much different from render, where you already have to pay attention to the format, with the exception of some Pictures being dest-only.  i mean, the server implementation of Xv would surely be a tiny shim over render, so why do they have to be so different client-side?
< daniels> ajax: mm, you can do api compat forever by having libXv just call out to libXv2, though yeah, that doesn't solve this whole client<->server issue.
< ajax> i really can't break libXv
< ajax> though lord do i wish
< marcheu> daniels: I'm saying you have to basically keep the xv implementation driver-side anyway...
< daniels> sure, so that can just call out to the new code.  nothing saying that libXv has to implement XVIDEO.
< marcheu> yeah, but that's duplication
< daniels> marcheu: true for overlays, but it probably means a lot _less_ duplication for textured video.
< ajax> daniels: there's a small "hard problem" around making sure the XV object types exist in the protocol somewhere and can be passed around between clients, just in case someone did that.
< daniels> ajax: hmm?
< ajax> daniels: it's legal to get an XvPortID from one process and use it in another and expect them to be numerically identical
< ajax> it's crack but it's an XID
< ajax> libXv backending onto this new Render hotness would need to manage that somehow.  could be root window properties for all i care, but.
< daniels> atoms.
< daniels> do they share a space with xids?
< daniels> (i should know this.)
< ajax> not sure.  doesn't really matter that they be legal XIDs, just that the opaque value mean the same thing in all clients.
< daniels> okay, atom of (int gpuid, int portid)
< ajax> also, as a sloth argument, it's easier to compat it in the server than both: compat on client, rewrite in server
< daniels> sure, but i'm talking new driver api + new render api, not when i'm bored next week. :)
< daniels> i mean, if your argument is that it's a crap api, sure, but if your argument's that someone needs to do it, then i'll do it because i've written an xv implementation and looked into that code.
< ajax> i'm happy to see xv backended on to render, sure.  i just don't see a lot of value in moving xv api compat from the server to libXv.
< daniels> assuming that we care about the server codebase being both reasonably sized and mostly decrufted, slicing xv off can't be that bad an idea.
< daniels> and that bitrotting libraries is something no-one really cares about.
< ajax> i suppose i'm being paranoid about xv-on-the-wire mattering for someone
< ajax> but, like you said: xv compat in server would _not_ be a large chunk of code
< ajax> positing all the stuff mentioned above, it's like... thousand lines or so?  most of which is protocol banging?
< daniels> sure.
< ajax> (also, anyone doing xv on the wire is already a bit barmy, seriously just do mpeg frames, it's less work for both sides)
< ajax> i buy the decrufting argument, and --disable-xv for server should still work, but unlike a lot of the other bullshit we've deleted we're starting to approach things that people actually use
< daniels> meh, anything other than YUV in requires dealing with the DSP in the X server, and no.
< daniels> ajax: yeah.
< daniels> ajax: consider me talked over.
< ajax> also when i say "on the wire" i mean "between different machines"
< ajax> if client and server are same machine, fix the damn player
< ajax> if they're not the same machine, you're using more bandwidth than you ought to be
< ajax> hopefully in N years everyone will be using gstreamer and we can fix the bottom layer of it at will
< ajax> right, so this sounds like a plan then.
< daniels> indeed.