IRC Logs of #dri-devel on irc.freenode.net for 2013-05-23

01:17 #dri-devel: < danvet> mlankhorst, http://paste.debian.net/5931/
01:19 #dri-devel: < mlankhorst> danvet: yeah I'll grab it, but I'm waiting on peterz, if he wants the interface his way, I'm not going to stand between a man and his bikeshed :)
01:19 #dri-devel: < danvet> imo his way is objectively worse
01:19 #dri-devel: < danvet> so not a bikeshed
01:19 #dri-devel: < mlankhorst> ok
01:20 #dri-devel: < danvet> i.e. I think adding the doc stuff + the little fixes in the implementation and then resend to keep things going sounds better
01:21 #dri-devel: < mlankhorst> I'm still waiting for a reply though, I'm really interested if the smp_mbb is really needed or not
01:28 #dri-devel: < danvet> hm, my impression is that core kernel people seem to resend pretty quickly, annotating any leftover open issues in the commit message
01:28 #dri-devel: < danvet> lkml drowns you way too quickly otherwise
01:31 #dri-devel: < danvet> mlankhorst, atomic_read is fully unordered in the l-k memory model
01:31 #dri-devel: < danvet> not on x86 though
01:32 #dri-devel: < danvet> so I don't think you can drop that barrier
01:32 #dri-devel: < mlankhorst> :(
01:33 #dri-devel: < mlankhorst> could it be lowered to a wmb?
01:33 #dri-devel: < mlankhorst> or could that cause the atomic_read to be reordered
01:33 #dri-devel: < danvet> yeah, I think wmb will allow the read to move up
01:34 #dri-devel: < mlankhorst> screw it, all other ways suck. :P
01:34 #dri-devel: < mlankhorst> I'll just leave it in
01:34 #dri-devel: < danvet> essentially we're hand-rolling an cmpxchg (ctx | contended)
01:35 #dri-devel: < mlankhorst> yeah
02:00 #dri-devel: < mlankhorst> danvet: actually we could probably drop the _slow ones without losing debugging information, the _single ones perhaps too.
02:01 #dri-devel: < mlankhorst> but I'd still like to keep lock_single at least
02:01 #dri-devel: < danvet> the cool thing with _single is that you don't need an acquire_ctx
02:01 #dri-devel: < mlankhorst> yeah but if we only have a single unlock function we have no unlock_single unlock mismatches
02:01 #dri-devel: < mlankhorst> so that becomes moot
02:02 #dri-devel: < mlankhorst> now that ctx is no longer an atomic_long it should be harmless
02:03 #dri-devel: < danvet> how can we keep the debug stuff without _slow?
02:03 #dri-devel: < danvet> I've tried but failed
02:03 #dri-devel: < mlankhorst> we already enforce that the next lock to be taken is the one that fails with -EDEADLK
02:03 #dri-devel: < mlankhorst> ww_acquired == 0 is good enough too
02:04 #dri-devel: < danvet> oh
02:04 #dri-devel: < mlankhorst> WARN_ON(ctx->lock && ctx->lock != lock); WARN_ON(ctx->lock && ctx->acquired > 0)
02:04 #dri-devel: < danvet> I should read the code next time around
02:05 #dri-devel: < mlankhorst> soomething like that
02:05 #dri-devel: < danvet> so it boils down to __must_check int vs. void
02:13 #dri-devel: < mlankhorst> yeah I sent a mail just now
02:20 #dri-devel: < danvet> mlankhorst, do you mean ctx->contending_lock instead of ctx->lock?
02:28 #dri-devel: < mlankhorst> yeah
02:28 #dri-devel: * mlankhorst was busy with mesa updates, xxv-intel updates and mesa paperwork
04:27 #dri-devel: < fabe> :x
04:28 #dri-devel: < fabe> oops, wrong window :$
04:55 #dri-devel: * danvet makes another stab at trying to understand inki ...
05:05 #dri-devel: < vrodic> how can i switch from nvidia proprietary driver to Nouveau quickly?
05:15 #dri-devel: < robclark> danvet, good luck :-P
05:15 #dri-devel: < danvet> robclark, I had a new idea where the misunderstandings are from
05:15 #dri-devel: < mlankhorst> vrodic: depends on how you installed the nvidia driver
05:15 #dri-devel: < mlankhorst> and distro
05:16 #dri-devel: < vrodic> mlankhorst: ubuntu 13.04, im using xorg edgers
05:16 #dri-devel: < robclark> danvet, it might be worth explaining *why* dma blocked on userspace is a bad thing.. for ex, I guess it would trigger gpu hang detection if you had gpu waiting on a semaphore in the cmdstream
05:16 #dri-devel: < vrodic> mlankhorst: so installed with apt-get install
05:17 #dri-devel: < mlankhorst> vrodic: apt-get autoremove .*nvidia-3.* ?
05:17 #dri-devel: < mlankhorst> or something
05:17 #dri-devel: < mlankhorst> then probably reboot
05:18 #dri-devel: < vrodic> mlankhorst: ill try, thanks
06:16 #dri-devel: < mlankhorst> robclark: .. does that REALLY need an explanation?
06:24 #dri-devel: < nido> depends how advanced you expect your developers to be I guess
06:26 #dri-devel: < robclark> mlankhorst, well, he isn't a gpu guy (afaik), so perhaps yes
06:44 #dri-devel: <+ajax> aaw. if you disable X's crash handler and the server segfaults, kms doesn't recover to a working console
06:45 #dri-devel: <+ajax> where's my flying car
06:48 #dri-devel: < danvet> ajax, it's the graphics mode the vt is in I think
06:48 #dri-devel: < danvet> imre just recently solved the inverse problem where fbcon was wreaking havoc while running i-g-ts
06:50 #dri-devel: < danvet> add it to the list of things fbcon totally gets wrong
06:51 #dri-devel: <+ajax> i like how we're still using fbcon
06:51 #dri-devel: <+ajax> by which i mean why in the crap do we still put up with fbcon
06:51 #dri-devel: < robclark> time to start shipping kmscon in fedora :-P
06:51 #dri-devel: < mlankhorst> there are still people writing new fbdev drivers :(
06:52 #dri-devel: <+ajax> and they can continue to use fbcon all they like
06:52 #dri-devel: <+ajax> the rest of us with real drivers ought to be using something that isn't a fundamental mismatch
06:53 #dri-devel: < danvet> I fear that at least in the kernel we won't get around some fbcon cleanup
06:53 #dri-devel: < robclark> hmm, someone should start NAK'ing new fbdev drivers..
06:53 #dri-devel: < danvet> since the disease seems to spread ...
06:53 #dri-devel: < danvet> at least saner locking would be nice
06:58 #dri-devel: < Prf_Jakob> kernel kmscon or userspace kmscon?
07:27 #dri-devel: < danvet> so noob time: assume I understand stuff correctly gallium egl and classic egl are different worlds
07:27 #dri-devel: < danvet> (reading through this with the wayland backend)
07:27 #dri-devel: < danvet> now I have a hard time figuring out where the runtime split happens
07:29 #dri-devel: < mlankhorst> danvet/robclark: can you review http://paste.debian.net/6014/ ?
07:29 #dri-devel: < mlankhorst> I'll probably send it out if it boots on my test system
08:14 #dri-devel: < danvet> airlied, can you pls take a look at "[PATCH 0/7] drm/i915: fbdev mode restoration improvements" and ack the drm parts?
08:14 #dri-devel: < danvet> specifically "[PATCH 1/7] drm: Add fb_helper->restore_fbdev_mode hook"
08:14 #dri-devel: < danvet> and there's also "[Intel-gfx] [PATCH v2] drm: Remove some unused stuff from drm_plane"
08:14 #dri-devel: < danvet> both have an r-b from pinchartl already
13:38 #dri-devel: <+airlied> danvet: gallium egl and dri2 egl are different but you can load gallium drivers using either method, for extra confuse
13:39 #dri-devel: < danvet> oh ...
13:39 #dri-devel: < danvet> I kinda got stuck trying to figure that part out
13:39 #dri-devel: < Kayden> AFAIK the only reason for egl_gallium to exist is OpenVG
13:39 #dri-devel: < Kayden> or at least that was the case at one point
13:40 #dri-devel: < danvet> somehow only the intel driver implements the dri image loader extension
13:40 #dri-devel: < danvet> how does that work on gallium drivers with the dri egl loader?
13:42 #dri-devel: <+airlied> I think RAOF was implementing gallium support for osme of that stuff
13:46 #dri-devel: < danvet> yeah, I think I've lost myself earlier today and chase the wrong functions
13:54 #dri-devel: < okias> Hello guys
13:55 #dri-devel: < okias> I hit some compilation problem with ilo and classic intel enabled.. no dri except swrast build :(
13:56 #dri-devel: < okias> does mesa-9999 needs some llvm-9999 ? or llvm-3.2 is enough?
13:56 #dri-devel: <+airlied> okias: if 9999 means git then yes/no
13:57 #dri-devel: < okias> git = 9999\
13:57 #dri-devel: < okias> I didn't see any error, but no drivers except swrast is build :(
13:58 #dri-devel: < okias> recompiling without ilo, if it fix issue
13:59 #dri-devel: < okias> well, without ilo build passed
14:03 #dri-devel: < tstellar> okias: radeonsi and r600g require LLVM >= 3.3, but if you aren't building those drivers 3.2 should be fine.
14:04 #dri-devel: < okias> what about ilo?
14:18 #dri-devel: * robclark discovers a new way to validate input from userspace... BUG_ON()!
14:18 #dri-devel: < robclark> so many valuable tips to learn from kernel-msm
14:18 #dri-devel: * calim can't tell if robclark is being serious
14:19 #dri-devel: < jcristau> i can tell he's not
14:19 #dri-devel: < robclark> opps, I guess I missed the </sarcasm> :-P
14:20 #dri-devel: < calim> oh, good
14:33 #dri-devel: < okias> well, I found problem. When is build i915 and i915g with i965 and i965g it fails. When is build only "i915* i965" it works, with "i965*" it works too... so somewhere is .. problem :D
15:09 #dri-devel: < okias> why there is i965 and i965g which are equals?
15:09 #dri-devel: < calim> mareko: hm, do we need separate scissor enables ?
15:09 #dri-devel: < calim> the patch doesn't seem to have that
15:11 #dri-devel: < calim> we can just make it disable == (0,0)-(ffffffff,ffffffff) for all I care
15:11 #dri-devel: < calim> (since if the blob always leaves all scissor rectangles on it can't be such a bad idea on NV cards)
15:12 #dri-devel: < calim> make that ffff
15:12 #dri-devel: <+airlied> okias: there is no i965g, why you building ilo?
15:13 #dri-devel: < okias> airlied: well, I'd like to check if I can fix some trivial issues, I'm aware it's can be problematic.
15:14 #dri-devel: <+airlied> okias: not sure why you say i965g then
15:15 #dri-devel: < okias> airlied: well seems that exist ebuild do something bad :(
15:15 #dri-devel: <+airlied> okias: don't use ebuilds
15:15 #dri-devel: < okias> airlied: and copyied i965 as i965g
15:15 #dri-devel: < okias> airlied: well, I rather fix ebuild than check it myself ;-)
15:15 #dri-devel: <+airlied> ilo is't i965g
15:15 #dri-devel: <+airlied> i965g was removed from mesa ages ago
15:16 #dri-devel: <+airlied> but doesn't sound like our problem
15:17 #dri-devel: < okias> I know, I though it's named ilo and builds i965g, it's okey, trying fix it :)
15:17 #dri-devel: < danvet> airlied, take a look at vsyrjala 's ->restore_fbdev_mode patches already?
15:20 #dri-devel: < okias> airlied: well, anyway, ilo is not build, but it's mentioned in config summary as : Target dirs: dri-ilo dri-swrast egl-static gvm pipe-loader
15:20 #dri-devel: < okias> airlied: no file is build :(
15:34 #dri-devel: < Kayden> okias: i965g and ilo aren't equal to i965...they pretty much barely work at this point, and there's about 1/10th of the people working on it
15:34 #dri-devel: < Kayden> (I say "pretty much barely work" based on the kinds of patches I've seen floating by on the mailing list...things like enabling basic depth/stencil)
15:34 #dri-devel: <+airlied> danvet: seems fine, ack
15:35 #dri-devel: < danvet> ta
15:41 #dri-devel: < fabe> Hi! Can someone give me some feedback on http://lists.freedesktop.org/archives/mesa-dev/2013-May/039228.html and the following patches, please?
15:44 #dri-devel: < mattst88> fabe: I'll send idr an email. I think he should review those that are outstanding.
15:45 #dri-devel: < mattst88> fabe: I reviewed some though. want me to go ahead and commit them?
15:45 #dri-devel: < fabe> i'd appreciate that :)
15:46 #dri-devel: < mattst88> okay, will commit 1/5 and 3/5
15:46 #dri-devel: < mattst88> (we just talked at length about how bad we've been about patch review in our weekly meeting :)
15:48 #dri-devel: < fabe> I guess my patches to mesa are somewhat bikesheddy and i understand if they are not a high priority
15:48 #dri-devel: < K`den> mattst88: Don't push 3
15:48 #dri-devel: < mattst88> oh?
15:48 #dri-devel: < K`den> it relies on 2
15:48 #dri-devel: < K`den> (I'm not saying it's bad, just picking only 1 and 3 probably won't compile :))
15:48 #dri-devel: < mattst88> fabe: seems to me that a lot of the problem with piglit at least is that people don't feel like they own parts of the code
15:49 #dri-devel: < Kayden> fabe: no no, it's not anything wrong with your code...we've just been terribly overwhelmed. I -just- finished reviewing stuff from Jordan from a few months ago :(
15:49 #dri-devel: < mattst88> oh, I was looking at a different 5 patch series from you :P
15:49 #dri-devel: < Kayden> Oh :)
15:50 #dri-devel: < mattst88> I was looking at the 5 patch piglit series
15:50 #dri-devel: < mattst88> will push patches 1 and 3 (all independent) of the piglit series
16:29 #dri-devel: < mareko> calim: I'm undecided, radeons only have one enable bit for all 16 scissors
16:30 #dri-devel: < mareko> and r6xx doesn't even have a scissor enable bit... this will be fun
16:36 #dri-devel: < calim> mareko: well then, we can just ignore the bit in OpenGL altogether and always set it 1 ...
16:37 #dri-devel: < calim> otoh I guess other drivers like the bit
16:37 #dri-devel: < calim> where by "other" I mean "old"
16:39 #dri-devel: < calim> I do like the fine-grained update, I wouldn't want to re-emit or memcmp all 16 rectangles if only, say, the last one ever changes