IRC Logs of #dri-devel on for 2014-07-24

Choose date

00:19 #dri-devel: < danvet> airlied, for atomic there's also the political component that google is ramping up pressure for adf
00:19 #dri-devel: < danvet> I've heard noises that they'll make it mandatory for android ...
00:19 #dri-devel: < danvet> still think that the current approach to handling legacy ioctls isn't good
00:55 #dri-devel: < danvet> airlied, and ping again for the ack on the ums removal ...
01:46 #dri-devel: <+airlied> imirkin: oh yeah nobody handles that tset, I sent it to the list ages ago
01:46 #dri-devel: <+airlied> danvet: yeah go for it, just get ready to revert it :-P
01:46 #dri-devel: <+airlied> someone out there is booting kernels on RHEL5 I'm sure
01:46 #dri-devel: <+airlied> danvet: yeah I think I'd like to get something merged for atomic
01:47 #dri-devel: <+airlied> and tweak it in tree, its not like Rob can disappear :-P
01:47 #dri-devel: <+airlied> or has managers who will transfer him to start a new task once something is merged :-)
01:56 #dri-devel: < danvet> airlied, well it's the split between interface and helpers really
01:58 #dri-devel: < danvet> thus far kms has a rather solid split in that area with core just doing the marshalling
01:58 #dri-devel: < danvet> with atomic that's now all over the place
01:59 #dri-devel: < danvet> airlied, for the ums we don't fail actually
02:00 #dri-devel: < danvet> we just don't set up the driver
02:00 #dri-devel: < danvet> so userspace silently falls back
02:00 #dri-devel: < danvet> of the very few reporters who complained about something no one noticed that yet
02:00 #dri-devel: < danvet> so still hopeful that I don't have to revert
02:01 #dri-devel: < danvet> and it's been CONFIG_BROKEN since a while now
02:01 #dri-devel: <+airlied> ah if people just get no dri they probably won't notice
02:02 #dri-devel: <+airlied> yeah I do quite like how clean the split we have now is
02:02 #dri-devel: < danvet> yeah we totally silently fail
02:02 #dri-devel: < danvet> only if you enable drm.debug we'll put a notice in for developers
02:02 #dri-devel: < danvet> so people really need to check whether dri1 still works
02:02 #dri-devel: < danvet> and most don't notice
02:03 #dri-devel: < danvet> since all those who care have a modern stack
02:03 #dri-devel: < danvet> so most = hopefully all
02:04 #dri-devel: < danvet> airlied, the problem is that undoing it will be painful
02:04 #dri-devel: < danvet> and there's little chance imo that all the drivers will get converted to atomic soon
02:04 #dri-devel: < danvet> where all = all those that either implement cursor or page_flip
02:04 #dri-devel: < danvet> since those are the tricky bits in the conversion from legacy to atomic
02:04 #dri-devel: < danvet> so imo doing those two the other way round would be good
02:05 #dri-devel: < danvet> well cursor is actually not converted at all
02:05 #dri-devel: < danvet> so dropping the pageflip stuff would imo be really good
02:05 #dri-devel: < danvet> and instead provide a helper to implement pageflip using atomic as I laid out (i.e. needs the change around for the event handling)
02:05 #dri-devel: < danvet> msm would still work as well
02:05 #dri-devel: < danvet> since really you can't do atomic with the current page_flip function, that one just doesn't fit
02:06 #dri-devel: < danvet> the helper vs. core untangling can imo be fixed easier
02:06 #dri-devel: < danvet> but page_flip looks to me like an expensive mistake
02:07 #dri-devel: < danvet> airlied, robclark so what about just that?
02:07 #dri-devel: < danvet> i.e. drop the pageflip conversion and the call to ->page_flip in the commit helper
02:07 #dri-devel: < danvet> and then I throw a grumpy ack on it?
02:08 #dri-devel: < danvet> then we could do the page_flip -> atomic helper on top ...
02:08 #dri-devel: < danvet> and I just gulp down my irks around the helper split, nolock and nonblock ;-)
02:10 #dri-devel: < danvet> this change should simply amount to deleting a bit of code
02:10 #dri-devel: < danvet> and the page_flip helper can be done late without ill effects since it will only affect msm plus a shiny new drm_atomic_helper.c
02:11 #dri-devel: < danvet> thinking about the i915 conversion getting page_flip out of the picture should really help
02:13 #dri-devel: < danvet> now let's see what dvdhrm__ has done ..
02:14 #dri-devel: < dvdhrm__> danvet, the bulk of changes is still hiding in my tree
02:14 #dri-devel: < danvet> dvdhrm__, the prep stuff from yesterday looks scary enough
02:14 #dri-devel: < danvet> ;-)
02:15 #dri-devel: < dvdhrm__> That's why I put patches like "drop unused 'struct drm_queue'" in between. Makes reviewers happy!
02:16 #dri-devel: <+airlied> I picked 2 or 3 of the easy ones in -next today
02:16 #dri-devel: <+airlied> danvet: my issue is, isn't page-flip one of the main reasons for atomic?
02:17 #dri-devel: < danvet> airlied, the legacy pageflip is completely useles for atomic
02:17 #dri-devel: < danvet> that's why we need atomic
02:18 #dri-devel: < danvet> so maybe I'll even want to keep the old pageflip around since likely we'll only have true atomic on gen5+
02:18 #dri-devel: < danvet> if ville doesn't go completely nuts and fixes up gen2-4 too
02:18 #dri-devel: < danvet> so keeping page_flip outside of atomic (with the helper opt-in ofc) would be nice for conversion
02:19 #dri-devel: < danvet> afaics there's two reasons for atomic: multi-pipe (because shared dpll) and async flips over primary + plane + cursor
02:19 #dri-devel: < dvdhrm__> danvet, your concern is just about converting the legacy page-flip ioctl to use the new atomic-infrastructure as backend?
02:20 #dri-devel: < danvet> first is trivial on anything earlier than gen6 due to lack of shared resources
02:20 #dri-devel: < danvet> so we'll have it everywhere
02:20 #dri-devel: < danvet> 2nd one needs ville's insane nuclear flip implementation on i915 (because the hw sucks)
02:20 #dri-devel: < danvet> and atm we only have code for pch-split platforms
02:20 #dri-devel: < danvet> so no pre-gen5 and no vlv/chv
02:20 #dri-devel: < danvet> dvdhrm__, yeah
02:21 #dri-devel: < danvet> dvdhrm__, I think going the other way like we've done for cursor plane is better
02:21 #dri-devel: < danvet> i.e. leave current entry-point unchanged
02:21 #dri-devel: < danvet> but give drivers a helper to implement page_flip in terms of atomic
02:21 #dri-devel: < danvet> instead of forcing everyone to implement atomic page_flips half-assed
02:22 #dri-devel: < dvdhrm__> struct drm_driver my_driver = { .page_flip = drm_page_flip_via_atomic() };? sounds good to me.
02:22 #dri-devel: < danvet> atomic modesets are imo less of a concern since almost everywhere it's trivial to implement
02:23 #dri-devel: < danvet> and the real work will boil down to pimping crtc helpers a bit
02:23 #dri-devel: < danvet> dvdhrm__, yup, that's the idea
02:23 #dri-devel: < danvet> so drop all the code that touches page_flip or calls the driver function from the patches
02:23 #dri-devel: < danvet> then implement drm_page_flip_via_atomic in drm_atomic_helper.c and use it in msm
02:24 #dri-devel: < danvet> won't make me happy about rushing this into 3.17, but addresses my biggest concerns really
02:24 #dri-devel: < danvet> and we seem to need to rush to out-game google's adf
02:25 #dri-devel: < danvet> I'd prefer we actually do the same trick with update_plane to make cursors and sprites a bit easier ...
02:25 #dri-devel: < danvet> but update_plane/cursors don't make guarantees about async or not, so not that bad
02:26 #dri-devel: < ickle> which was stupid
02:27 #dri-devel: < danvet> having a drm_update_plane_via_atomic would make cursor support doable, together with the universal cursor plane stuff
02:27 #dri-devel: < ickle> and complained about since the start
02:28 #dri-devel: < danvet> well it's kinda best effort ...
02:28 #dri-devel: < danvet> with little effort
02:38 #dri-devel: < dvdhrm__> danvet, airlied:
02:38 #dri-devel: < dvdhrm__> pretty straightforward
02:41 #dri-devel: < danvet> dvdhrm__, oh, this is pretty
02:41 #dri-devel: < danvet> really, really pretty
02:41 #dri-devel: < danvet> whatever horrorshows lead up to this, I like it
03:24 #dri-devel: < robclark> danvet, airlied, yeah, I suspect we'll have to somehow implement adf on top of kms, similar to fbdev helpers now..
03:25 #dri-devel: < robclark> danvet, fwiw, part of the reason for atomic-on-top approach is that a big chunk of atomic is basically dealing (indirectly atm) with interface from userspace..
03:25 #dri-devel: < robclark> ie. tracking the state that is requested..
03:25 #dri-devel: < robclark> the part where we actually apply the state to driver is the main spot I see changes going forward..
03:25 #dri-devel: < danvet> well you can still push that exact code into the drm_page_flip_via_atomic helper ..
03:26 #dri-devel: < robclark> I can try dropping the page_flip part..
03:26 #dri-devel: < robclark> that shouldn't actually be needed now that I think about it..
03:26 #dri-devel: < danvet> dropping the update_plane won't work since that will kill the current commit helpers
03:26 #dri-devel: < robclark> not dropping update_plane..
03:26 #dri-devel: < danvet> yeah msm doesn't really need it I guess
03:27 #dri-devel: < robclark> yeah, msm does the async bit in commit, so by time you get to page_flip you don't need it..
03:27 #dri-devel: < robclark> I wasn't really thinking of that last night
03:27 #dri-devel: < danvet> robclark, for update_plane I think we should move that into a plane_helper_funcs pointer
03:27 #dri-devel: < danvet> since it won't be main interface any more
03:27 #dri-devel: < danvet> but that can be a cleanup on top
03:27 #dri-devel: < robclark> (but to be fair, this stuff has been on a branch so long, it takes me a little while to page it all back into my head :-P)
03:28 #dri-devel: < danvet> well same here
03:28 #dri-devel: < danvet> paging in enough context for review I mean
03:30 #dri-devel: < glennk> argh, i just spent an hour debugging an fbo incomplete issue just to realize i had swapped w/h and border params to glTexImage2D...
03:30 #dri-devel: < robclark> I guess I'll have to re-work the event stuff a bit in order to drop page_flip..
03:31 #dri-devel: < robclark> but maybe it is not so bad
03:32 #dri-devel: < robclark> ie. I think I'll just grab the events in ->atomic_commit().. and that would let us attach a pending event to the crtc a plane is attached to for (overlay) plane-only updates..
03:33 #dri-devel: < danvet> robclark, we can move the event handling into ->page_flip too imo
03:33 #dri-devel: < danvet> then ->atomic_commit could do it all, using helpers
03:33 #dri-devel: < vignesh> Hi. Like glxinfo can we run eglinfo to find the supported extensions?
03:34 #dri-devel: < robclark> I'm kinda thinking in msm_atomic.c in commit_sync() that I'll just grab all the crtcstate->event's and internally call my own crtc fxn to set event on crtc (and then null out crtcstate->event)..
03:34 #dri-devel: < robclark> so I basically keep the event handling logic in crtc, just change how I call it slightly
03:36 #dri-devel: < danvet> robclark, I don't have the details in mind really
03:36 #dri-devel: < danvet> don't we have per-plane event's?
03:36 #dri-devel: < robclark> currently no
03:36 #dri-devel: < danvet> I've thought userspace wants that to keep track of their planes
03:36 #dri-devel: < robclark> I mean no existing ioctl exposes that
03:36 #dri-devel: < robclark> yes we *want* plane events..
03:37 #dri-devel: < danvet> well asked about the atomic state stuff
03:37 #dri-devel: < robclark> ahh, sorry
03:37 #dri-devel: < robclark> so yes, the state is that, today, we don't have per plane events simply because we haven't added new ioctl yet..
03:37 #dri-devel: < robclark> if you take existing atomic ioctl patch, you can request an event on an atomic update which doesn't change the primary layer
03:37 #dri-devel: < robclark> (ie. no page_flip())
03:38 #dri-devel: < robclark> we do need to decide whether to introduce a new event type for userspace (carrying back more info, hopefully).. and we do need to decide how to handle that in atomic stuff..
03:39 #dri-devel: < robclark> could be either an _EVENT flag to ->atomic_begin().. or maybe arg to ->atomic_commit(), or driver just grabs it out state object in it's ->atomic_commit()..
03:39 #dri-devel: < danvet> robclark, so maybe keep off the event stuff until we add the page_flip stuff back in?
03:40 #dri-devel: < robclark> do we need to add it back in?
03:40 #dri-devel: < robclark> hmm, well, I guess I need to think how primary plane helpers would work..
03:42 #dri-devel: < danvet> robclark, btw for update_plane
03:42 #dri-devel: < danvet> if we add atomic helper funcs we could move the msm update_plane into a plane_commit callback
03:42 #dri-devel: < danvet> same with crtc maybe
03:43 #dri-devel: < danvet> then use the existing update_plane unchanged and wire up msm with a drm_atomic_helper_update_plane
03:43 #dri-devel: < daniels> danvet: fwiw, is our path towards i915 atomic - currently totally totally broken, mind
03:43 #dri-devel: < danvet> tagr seems to see some concerns about whether everything is really converted
03:43 #dri-devel: < danvet> would fix that
03:44 #dri-devel: < daniels> danvet: but roughly, first having split everything into check/commit (near-on done), then building an actual global atomic_check to handle the dpll dance in particular, then later doing actual atomic flips
03:44 #dri-devel: < danvet> daniels, this is for nuclear flips mostly I guess?
03:44 #dri-devel: < daniels> danvet: i've had to drop out of that since i've been dragged off to doing it for exynos for a bit, but padovan is continuing to work on it
03:44 #dri-devel: < danvet> ok, lunchtime now, then mtg
03:44 #dri-devel: < danvet> bbl
03:45 #dri-devel: < daniels> danvet: yeah, our aim is really to get nuclear flips & plane reconfiguration - i honestly don't give two shits about the dpll kind of thing, but obviously it'd be great to make that work :)
03:45 #dri-devel: < robclark> danvet, I think for planes, update_plane == plane_commit..
03:45 #dri-devel: < daniels> danvet: really though we just need to get it merged for intel to push it forward, since realistically that's everyone's development platform
03:46 #dri-devel: < pq> per-plane events= surely you mean per-commit event?
03:47 #dri-devel: < pq> s/=/?/
03:47 #dri-devel: < daniels> yeah, i really don't see much use in per-plane events - a per-ioctl event would be good
03:47 #dri-devel: < daniels> one ioctl -> one event
03:48 #dri-devel: < daniels> if they all flip together, great, send that timestamp; if they don't, just pick a random one and set event->was_atomic=0
03:48 #dri-devel: < daniels> though i realise you probably need multiple events if you're flipping multiple crtcs simultaneously ... hmm
03:49 #dri-devel: < pq> daniels, robclark, as someone who added nuclear support to Weston's DRM backend, I really would like a per-commit event when it's *all* done. I don't have any use for per-plane events.
03:49 #dri-devel: < daniels> ... can you tell my usecases are almost entirely single-crtc? :)
03:49 #dri-devel: < pq> *danvet ^
03:49 #dri-devel: < daniels> fwiw, is the above
03:49 #dri-devel: < glennk> grr, apparently there is no way in GL to avoid glGetTexImage clamping float values to [0-1] range?
03:49 #dri-devel: < pq> I don't see a difference to multi-crtc... if I do a multi-crtc commit, I would probably want to know when they *all* are done.
03:49 #dri-devel: < robclark> pq, I guess I should s/per-plane/per-effected-crtc-per-commit/ events..
03:50 #dri-devel: < pq> if I really want per-crtc or per-plane events, I can do multiple commits
03:50 #dri-devel: < robclark> ie. you can get an event for a commit that only touches planes
03:50 #dri-devel: < robclark> so per-commit is really more accurate.. but it would be per-commit-per-crtc
03:50 #dri-devel: < robclark> (at least that is my thinking)
03:51 #dri-devel: < robclark> if weston is treating each crtc w/ it's own thread/loop then it is effectively a per-commit event
03:51 #dri-devel: < pq> robclark, yes, that would probably be the best case, thinking about timings.
03:52 #dri-devel: < robclark> right
03:52 #dri-devel: < pq> robclark, I assume all changes for one crtc happen at the same time anyway, but different crtcs update at different times. Right?
03:52 #dri-devel: < robclark> right
03:53 #dri-devel: < robclark> you may be able to sync lock multiple crtcs, but that is kind of a special case
03:53 #dri-devel: < pq> so if you have an event per commit&crtc, then you also avoid the problem "what timestamp to send"
03:53 #dri-devel: < robclark> (so.. two events w/ same timestamp)
03:53 #dri-devel: < robclark> right
03:53 #dri-devel: < pq> yes
03:53 #dri-devel: < daniels> robclark: please tell me you're up early rather than late btw ...
03:53 #dri-devel: < robclark> heheh, early
03:53 #dri-devel: < robclark> it gets light too early here :-P
03:53 #dri-devel: < daniels> yeah, tell me about it
03:54 #dri-devel: < daniels> agreed that per-crtc-per-commit is the way forward
03:54 #dri-devel: < pq> sun rising before 4am was a problem - then we bought some curtains
03:54 #dri-devel: < daniels> pq: YOU DIDN'T HAVE THEM BEFORE?!
03:54 #dri-devel: < daniels> pq: madman.
03:54 #dri-devel: * robclark just needs thinker ones..
03:54 #dri-devel: < pq> daniels, well, not that good curtains, just those standard white
03:54 #dri-devel: < daniels> tbf, i didn't have curtains for my 2.5 years in hki, but i a) had some blinds already, b) was 20, and c) was really lazy (see b)
03:55 #dri-devel: < daniels> also i was up all night bashing on input-hotplug and avivo anyway ... ah, those were the days
03:55 #dri-devel: < daniels> pq: gotcha
03:55 #dri-devel: < robclark> heheh
03:55 #dri-devel: < daniels> robclark: one thing that would make it easier for userspace would be if it was guaranteed that all the events were always delivered together
03:55 #dri-devel: < pq> daniels, which more like reflect the light all around rather than block it :-P
03:55 #dri-devel: < daniels> robclark: since 'when has this entire ioctl finished so i can crack on with things' is a very valid usecase for people who care about atomicity, but not the per-crtc timings per se
03:56 #dri-devel: < robclark> hmm..
03:56 #dri-devel: < robclark> can't userspace keep a counter?
03:56 #dri-devel: < robclark> is if (num_events_left-- == 0) ...
03:56 #dri-devel: < daniels> yeah, i guess that isn't unreasonable
03:56 #dri-devel: < daniels> or we could embed events_left_for_provoking_ioctl in the event?
03:56 #dri-devel: < robclark> seems at least a lot simpler :-P
03:56 #dri-devel: < pq> I'd rather have a unique userdata pointer go with each event...
03:57 #dri-devel: < daniels> (the latter is one of those things that core x11 proto actually did right)
03:57 #dri-devel: * robclark assumes any new event would still have userdata
03:57 #dri-devel: < daniels> ++
03:57 #dri-devel: < pq> hmm... but I suppose a counter and crtc id is ok too
03:58 #dri-devel: < robclark> events_left_for_submit might be possible.. still more complexity in kernel compared to doing it in userspace.. if someone was proposing a new event I'd suggest a placeholder initialized in kernel to ~0 or something like that for now..
03:58 #dri-devel: < pq> robclark, but how would you send N_crtcs number of userdata pointers with commit? I thought that might be a bit much.
03:59 #dri-devel: < pq> also associate with crtcs... nah, one userdata per commit, and userdata+crtc_id in each event, and probably that events_left_for_provoking_ioctl would be very useful
03:59 #dri-devel: < robclark> hmm, yeah, ok.. we do need something for that in atomic ioctl somehow.. one idea I had was an EVENT (?name?) property.. userspace can write userdate to that property..
03:59 #dri-devel: < robclark> and get an event back
04:00 #dri-devel: < robclark> (or maybe EVENTDATA or something)
04:00 #dri-devel: < robclark> property would be on the crtc (fwiw)
04:01 #dri-devel: < daniels> one-userdata-per-commit would be best i think, since your other option is bashing userdata into cstate through a prop, which is kinda eww
04:01 #dri-devel: < daniels> heh, snap
04:01 #dri-devel: < daniels> it'd work, i guess
04:02 #dri-devel: < pq> yeah, it sounds like it would work, but is a bit strange IMHO
04:02 #dri-devel: < robclark> it would be, I think, easier for the driver just to do event per crtc pre commit, then it doesn't have to do much bookkeeping.. but I suppose on kernel side if we somehow kept a pointer to the state object per event we could perhaps do something more sophisticated..
04:03 #dri-devel: < robclark> (the state object is refcnt'd and all that, so it would work I suppose)
04:03 #dri-devel: < pq> the userdata_per_commit+crtc_id+events_left_to_send in the event feels good to me, from user space PoV
04:03 #dri-devel: < daniels> yeah, surely having the state live until it's completely dealt with - which is bookended by the commit _occurring_ and the event being sent, rather than the commit being scheduling and the ioctl returning (modulo blocking mode) - makes driver life much easier
04:04 #dri-devel: < robclark> yeah
04:04 #dri-devel: < daniels> *scheduled
04:05 #dri-devel: < daniels> pq: btw, the 3d thing was that if you sent a single-plane mode with two bos, it would assume that the first was left and the second was right
04:08 #dri-devel: < pq> yeah, I recall something like that
04:08 #dri-devel: < pq> I've forgot where I made the comment :-D
04:10 #dri-devel: < daniels> pq: (re your gbm_multi_bo commit message)
04:11 #dri-devel: < pq> ahh, that's where it was
04:14 #dri-devel: * daniels goes back to yelling at exynos_drm
04:42 #dri-devel: < dvdhrm__> unsigned long handle; /**< handle */
04:42 #dri-devel: < dvdhrm__> I love KernelDoc!
04:46 #dri-devel: < glennk> at least its not unsigned long handle; /**< this is not a handle */
04:48 #dri-devel: < mgottschlag> heh, isn't that actually better than the average amount of documentation?
04:51 #dri-devel: < robclark> hmm, dropping ->page_flip is a lot more intrusive on the driver.. I mean, it is closer to where we want to end up, but looks like shuffling a lot around between plane and crtc for me.. twice! (mdp4 & mdp5)
05:03 #dri-devel: < danvet> robclark, I'm writing a proposal atm
05:03 #dri-devel: < danvet> takes a bit of time
05:10 #dri-devel: < robclark> well, I actually like the dropping ->page_flip idea.. it is just more work than I was planning to do in first step ;-)
05:13 #dri-devel: < danvet> robclark, you're going to hate my mail then ...
05:14 #dri-devel: < danvet> well not because of page_flip, but because of more work
05:14 #dri-devel: < robclark> grmbl..
05:15 #dri-devel: < robclark> not sure about your proposal.. at least what I started here.. it is the right direction, I want the plane's to be tracking ref to buffer pending vblank rather than having that in the crtc..
05:16 #dri-devel: < robclark> but getting rid of page_flip saves a few lines in drm_atomic and makes me move all that stuff around in msm now instead of later :-P
05:26 #dri-devel: < danvet> robclark, hit sent
05:52 #dri-devel: < daniels> danvet: i think for i915, a three-stage conversion really makes sense, which is what we've been working to - first use the atomic api but with the exact same limitations in terms of userspace api (e.g. to do the dpll dance, you need to disable then re-enable separately); then complete out atomic_check() so you have all the _capabilities_ of atomic but not
05:52 #dri-devel: < daniels> the presentation; then lastly, make the actual presentation atomic
05:52 #dri-devel: < daniels> danvet:
05:52 #dri-devel: < daniels> grr
05:52 #dri-devel: < daniels> danvet: anything else i think is going to just be a stop-the-world-rewrite-the-driver in one go
05:52 #dri-devel: < danvet> daniels, actually we can go a bit more fine-grained even
05:53 #dri-devel: < danvet> step one would be atomic modeset, only wire up to set_prop and set_crtc
05:53 #dri-devel: < danvet> hm, that's less fine-grained even ;-)
05:53 #dri-devel: < danvet> anyway, agreed that nuclear flips should be a separate step
05:53 #dri-devel: < danvet> iirc ville's plan is to have a light version of that in the modeset code
05:54 #dri-devel: < danvet> just for the black <-> on transitions
05:54 #dri-devel: < daniels> is that posted anywhere?
05:54 #dri-devel: < danvet> not yet I think ...
05:54 #dri-devel: < daniels> k
05:54 #dri-devel: < danvet> since on -> on needs some crazy stuff for intermediate stages
05:54 #dri-devel: < daniels> like i said, our main targets for actual usage are mainly arm-based - which is right now exynos because it has far and away the most competent kms driver that rob isn't writing ;)
05:55 #dri-devel: < danvet> nice qualifier there ;-)
05:55 #dri-devel: < daniels> i915 is just to bring it up so we can start using it on dev machines everywhere - so we'll fit in with whatever you guys decide is best, rather than just dumping something and leaving you another four years to rewrite it
05:56 #dri-devel: < danvet> daniels, I think for the actual nuclear flip we'll probably have some abstraction in the driver for it
05:56 #dri-devel: < danvet> since bdw+1 will make big hw changes for this
05:56 #dri-devel: < daniels> danvet: howso?
05:56 #dri-devel: < danvet> well probably shouldn't spill the beans
05:56 #dri-devel: < danvet> but they rework it to be sane and fit for atomic
05:56 #dri-devel: < danvet> there's really only one solution for that that fits
05:58 #dri-devel: < daniels> danvet: hm, any indication of what that would look like wrt driver commit model? like are we talking adf-style boshing the entire state into the driver at once?
05:58 #dri-devel: < daniels> danvet: i also didn't realise the flip-via-mmio thing until damien_l pointed it out a couple of weeks ago
05:59 #dri-devel: < daniels> but that seems totally sane, and fits in with my mental model as well
05:59 #dri-devel: < danvet> daniels, I mean at the hw level
05:59 #dri-devel: < danvet> adf is just interface

Written by Christoph Brill © 2007-2014

Valid XHTML 1.0 Transitional

Available in Android Market