IRC Logs of #dri-devel on for 2014-10-31

Previous dayChoose dateNext day Show menu

00:43 #dri-devel: < chrisf> may or may not be useful, but im publishing my (currently small) collection of mesa/piglit boilerplate automation scripts here:
00:45 #dri-devel: < chrisf> nasty hacks, but boring to do by hand
02:00 #dri-devel: < danvet> seanpaul_, btw if you want to help get the atomic stuff in asap ...
02:00 #dri-devel: < danvet> care to review [PATCH 1/3] drm: Pull drm_crtc.h into the kerneldoc template ?
02:00 #dri-devel: < danvet> it's a small series that's in front of my atomic core/helper patches
03:26 #dri-devel: < danvet> daniels, do you run exynos with full debugging enabled?
03:26 #dri-devel: < danvet> especially lockdep and sleep-inside-atomic and friends
03:27 #dri-devel: < danvet> it's not amused here
04:06 #dri-devel: < daniels> danvet: hah, yes
04:12 #dri-devel: < MY123>
04:12 #dri-devel: < MY123> I have a problem with Android
05:26 #dri-devel: < mlankhorst> airlied: ping, how do I fix shadow allocations in rotations with optimus?
05:34 #dri-devel: < xexaxo> MY123: did you miss my previous comments about mesa+android, or did you completely ignored them :P
06:13 #dri-devel: < MY123> xexaxo: I did not see any comment, or it's too far in the logs,...
06:14 #dri-devel: < xexaxo> MY123: it has been reported working (to some extent) for intel radeon/amd and nvidia hardware. not sure about swrast though.
06:14 #dri-devel: < xexaxo> MY123: using the proprietary drivers + mesa along side each other may not be the best of ideas.
06:14 #dri-devel: < MY123> xexaxo: It's for VC4. Not propretary drivers
06:14 #dri-devel: < mareko> it looks like we may be able to remove Linux support from st/egl
06:15 #dri-devel: < xexaxo> :P
06:15 #dri-devel: < MY123> xexaxo: Not swrast but the Mesa VC4 driver
06:15 #dri-devel: < xexaxo> MY123: vc4, as in the driver anholt is working on or another one ?
06:15 #dri-devel: < MY123> xexaxo: The driver anholt is working about
06:16 #dri-devel: < MY123> (I downloaded it from git://, and it's (c) broadcom, Why?)
06:17 #dri-devel: < jcristau> because when your job is to write software, the copyright for that software belongs to your employer?
06:17 #dri-devel: < MY123> jcristau: True but not always
06:18 #dri-devel: < xexaxo> MY123: just set a breakpoint in android_display_init_drm (the one that prints "failed to create DRM screen") and check which piece fails
06:19 #dri-devel: < xexaxo> I would assume that it may be something with gralloc and co
06:19 #dri-devel: < MY123> xexaxo: How can I do that?
06:20 #dri-devel: < xexaxo> or perhaps anholt had experience with Android and the vc4 driver ?
06:20 #dri-devel: < MY123> xexaxo: Anholt said : You'll need to write the device-specific android code (gralloc) and
06:20 #dri-devel: < MY123> figure out how to get the android loader to load the whole mess. You'd
06:20 #dri-devel: < MY123> be the first. in his e-mail
06:20 #dri-devel: < xexaxo> anholt: any ideas why we would fail to create the drm screen ?
06:21 #dri-devel: < xexaxo> that would explain it.
06:22 #dri-devel: < xexaxo> MY123: grab and looking at the nouveau/intel/freedreno commits you'll need to add one for vc4
06:23 #dri-devel: < xexaxo> from your paste there is some form of gralloc/hwcompositor so it might be that you'll need to modify that one
06:23 #dri-devel: < MY123> xexaxo: I did just use that unmodfied
06:25 #dri-devel: < xexaxo> MY123: also I do not see how any of the upstream vc4 code can generate the binary, so it seems that you've got some interesting stuff in there
06:28 #dri-devel: < okias_> Hey guys, I have question about increasing Mesa requirements from i386 to i486 on X86 to be able use intrinsics everywhere?
06:28 #dri-devel: < xexaxo> or.. it seems that none of the vc4 has Android build bits. which means that it's not even trying to build it let alone use it
06:33 #dri-devel: < MY123> xexaxo: I created an and renamed libGLES_mesa to libGLES_bcm2708
06:35 #dri-devel: < xexaxo> MY123: in that case just look into the gralloc bits. either modify your current one or the one I've linked - good luck :)
06:35 #dri-devel: < MY123> xexaxo: Is not there a generic KMS gralloc?
06:36 #dri-devel: < xexaxo> MY123: not that I know of. there are still device specific parts that are required
06:36 #dri-devel: < xexaxo> kms = modesetting, it's not buffer management :\
06:38 #dri-devel: < MY123> xexaxo: Is there some docs about making one
06:39 #dri-devel: < MY123> ?
08:06 #dri-devel: < kallisti5> anyone know where the A4 5300 APU hides the AtomBIOS? Is it ATRM?
08:13 #dri-devel: < agd5f> kallisti5, UEFI or legacy bios?
08:15 #dri-devel: < agd5f> kallisti5, if legacy, at the vga shadow address, if UEFI, generally in the ACPI VCFT method
08:15 #dri-devel: < agd5f> kallisti5, if a dGPU is present it can also be in vram
08:51 #dri-devel: < danvet> daniels, does exynos eventually loose the GO bits?
08:52 #dri-devel: < danvet> since I've just oopsed the driver before the commit, and the plane still showed up after a few seconds
08:56 #dri-devel: < robclark> danvet, background thread periodically mashing GO bits just in case? :-P
08:59 #dri-devel: < danvet> robclark, I suspect so
08:59 #dri-devel: < danvet> either in hw or sw
08:59 #dri-devel: < danvet> but not going to look for this dragon
08:59 #dri-devel: < robclark> wow, hw that works around sw bugs... that would be something!
09:07 #dri-devel: <+ajax> we have that. avx's vector-strchr instructions are marketed as speeding up xml processing.
09:07 #dri-devel: < MY123> robclark: Possible with firmware
09:08 #dri-devel: <+ajax> since the use of xml is pretty much always a bug...
09:09 #dri-devel: < MY123> ajax: And IBM mainframe can do a UTF-8 256-char strchr in ONE cycle
09:10 #dri-devel: < imirkin> that's a lot of xml being processed
09:10 #dri-devel: <+ajax> i can do anything you like in one cycle if you're not picky about how long it is
09:10 #dri-devel: < imirkin> (so it can process 1024 bytes in a single cycle? that's pretty impressive...)
09:11 #dri-devel: < imirkin> ajax: well, once you start using sub-clocks, that's sorta cheating...
09:12 #dri-devel: < MY123> imirkin: And at 6GHz stock clock,...
09:24 #dri-devel: < bwidawsk> is EndPrimitive() required if you're emitting all vertices for a primitive?
09:27 #dri-devel: < imirkin> i think it's implied
09:27 #dri-devel: < imirkin> and it's esp non-sensical if you're emitting points
09:29 #dri-devel: < bwidawsk> imirkin: I agree with both. Thanks
09:30 #dri-devel: < imirkin> that said, it's still fully legitimate to say EndPrimitive() in those cases
09:30 #dri-devel: < bwidawsk> the examples on (from nv) do that
09:31 #dri-devel: < bwidawsk> which was what raised the question
09:31 #dri-devel: < MY123>
09:33 #dri-devel: < imirkin> bwidawsk: hmmm... reading the glsl4.50 spec, it says that EndPrimitive is optional only for points and if you're emitting a single primitive
09:33 #dri-devel: < imirkin> (section 8.15)
09:34 #dri-devel: < imirkin> oh right. coz the other primitive types are line strip and tristrip, which have no implied "end"
09:36 #dri-devel: < bwidawsk> imirkin: that's EndStreamPrimitive() you're referring to, right?
09:37 #dri-devel: < imirkin> bwidawsk: EndStreamPrimitive(0) == EndPrimitive, right?
09:37 #dri-devel: < bwidawsk> that'd be my guess
09:37 #dri-devel: < glennk> multiple streams is from gs5
09:37 #dri-devel: < bwidawsk> but if you don't have multiple streams, I am not sure
09:37 #dri-devel: < imirkin> non-0 streams can only have points in unextended gl
09:38 #dri-devel: < daniels> danvet: hm, honestly not sure if it's hw or a misguided sw thing
09:38 #dri-devel: < imirkin> there are some amd extensions to be able to send any primitives to those streams, and even to rasterize them iirc
09:38 #dri-devel: < glennk> non-0 streams don't emit primitives in gl unless you have an amd extension for that
09:40 #dri-devel: < bwidawsk> I'm also confused what's supposed to happen if you EndPrimitive before emitting the requisite amount of verts (in the cases of primitives which don't require just 1)
09:42 #dri-devel: < bwidawsk> (or even if you have a single triFOO primitive)
09:46 #dri-devel: < mareko> can we set the FDO bugzilla not to add the "New: " prefix to the first message in a bug report?
09:49 #dri-devel: < agd5f> yeah, that would be nice
09:50 #dri-devel: < agd5f> mareko, ask Mithrandir on #freedesktop
09:50 #dri-devel: < mareko> oh it can be set in Preferences -> General preferences -> the option at the bottom, but that won't work for other accounts like mesa-dev and dri-devel
09:51 #dri-devel: < mareko> unless I get the passwords for them :)
09:52 #dri-devel: < imirkin> bwidawsk: the primitive gets dropped
09:52 #dri-devel: < bwidawsk> imirkin: for both cases?
09:53 #dri-devel: < imirkin> not sure what the 2 cases are...
09:53 #dri-devel: < imirkin> either you have enough for a complete primitive or you don't
09:53 #dri-devel: < bwidawsk> the more obvious was 1 primitive without all verts
09:53 #dri-devel: < imirkin> keep in mind that a tristrip is a single primitive
09:53 #dri-devel: < mareko> agd5f: do admins also manage bugzilla accounts for mailing lists?
09:53 #dri-devel: < bwidawsk> but for something like a tristrip... it will just continue on with the next vert?
09:53 #dri-devel: < bwidawsk> oh
09:53 #dri-devel: < bwidawsk> ah
09:54 #dri-devel: < imirkin> so if you give it not-enough-for a tri, the "trailing" vertices get dropped
09:54 #dri-devel: < imirkin> and if that's not enough for even a single tri, the whole primitive gets dropped
09:54 #dri-devel: <+ajax> mareko: hey cool, i have enough bz admin powers to impersonate those fake users. one moment...
09:54 #dri-devel: < glennk> its the same rules as for normal primitive assembly
09:55 #dri-devel: <+ajax> mareko: and done.
09:56 #dri-devel: < bwidawsk> Yeah, I was mixing up how the hardware is describing primitives passed through the pipeline versus what the spec means
09:56 #dri-devel: < mareko> ajax: is it for all mailing lists? or just mesa-dev and dri-devel?
09:56 #dri-devel: <+ajax> mareko: just those two
09:56 #dri-devel: <+ajax> probably could flip the site default if i knew where to find it
09:57 #dri-devel: < alanc> heh, that explains the email bugzilla just sent about the evil hacker ajax impersonating the mesa-dev account
09:58 #dri-devel: <+ajax> the warning screen on the "impersonate user" ui was pretty impressive
09:59 #dri-devel: < imirkin> aka the logs from your actions will be thrown away sooner than normal?
10:01 #dri-devel: < mareko> ajax: thank you
10:10 #dri-devel: < glennk> bwidawsk, writing piglits for geometry shaders?
10:10 #dri-devel: < bwidawsk> glennk: debugging existing ones atm
10:11 #dri-devel: < bwidawsk> hoping to improve some though once I solve the bugs
10:12 #dri-devel: < glennk> would be nice if arb_gpu_shader5-xfb-streams was split up into separate tests for subfeatures
10:13 #dri-devel: < bwidawsk> it's hard to get excited about GS since about everyone I talk to says, "nobody cares about gs"
10:13 #dri-devel: < glennk> pretty much
10:13 #dri-devel: < bwidawsk> +1
10:18 #dri-devel: < mattst88> mareko, ajax: thanks for doing that. the New: has always bugged me
10:23 #dri-devel: < imirkin> bwidawsk: -- i always get confused by the various list-of-triangles types. note that in this case, any number of vertices is valid except 0,1,2.
11:00 #dri-devel: < danvet> always great if you write nice helper functions for the tricky details
11:00 #dri-devel: < danvet> then while debugging an oops notice that you didn't use them

Written by Christoph Brill © 2007-2014

Valid XHTML 1.0 Transitional

Available in Android Market