IRC Logs of #dri-devel on for 2016-07-28

Previous dayChoose dateNext day Show menu

00:12 #dri-devel: <+anholt> robclark: results from turning on gtn:
00:12 #dri-devel: <+anholt> (
00:13 #dri-devel: < imirkin_> i wonder if this is as a result of some things being put into shader keys instead of uniforms? not sure how similar the paths are...
00:14 #dri-devel: < imirkin_> (or vice-versa?)
00:18 #dri-devel: < imirkin_> does vulkan at all address the difference between gart and vram? you tell the driver to put a buffer into one or the other or move between them?
00:18 #dri-devel: < bnieuwenhuizen> yes
00:18 #dri-devel: < imirkin_> any chance you might elaborate? :)
00:19 #dri-devel: < bnieuwenhuizen> the app explicitly specifies where to allocate memory and per object (image, buffer etc.) the driver can specify which types of memory are allowed
00:19 #dri-devel: < bnieuwenhuizen> you can have more memory types than just vram/gart
00:19 #dri-devel: < imirkin_> ok, and that's when you allocate the memory presumably, not when you place an image or buffer or whatever over it?
00:19 #dri-devel: < bnieuwenhuizen> e.g. on AMD we split VRAM between mappable and non-mappable
00:19 #dri-devel: < bnieuwenhuizen> yes
00:20 #dri-devel: < imirkin_> cool
00:20 #dri-devel: < imirkin_> and if you, hypothetically, wanted to move from one to the other, you'd have to create another memory region, and then use one of the copy functions?
00:20 #dri-devel: < bnieuwenhuizen> objects are initially not corresponding to any memory. The order is create object -> request memory requirements (mem type, alignment, size) -> find some memory -> associate
00:20 #dri-devel: < bnieuwenhuizen> yes
00:21 #dri-devel: < imirkin_> neat-o
00:21 #dri-devel: < imirkin_> thanks!
00:52 #dri-devel: <+anholt> ok, with a quick fix, results look a lot better.
01:09 #dri-devel: <+airlied> and only the app moves them
01:09 #dri-devel: <+airlied> imirkin_: ^
01:10 #dri-devel: < imirkin_> airlied: yeah, that's what i was trying to get at with my last question
03:09 #dri-devel: < imirkin> jekstrand: looks like dEQP landed some vulkan tests, in case you hadn't noticed. dunno if they're different from the CTS tests, but just fyi.
03:13 #dri-devel: < ishitatsuyuki> Is mesa leaking memory, or it's by design? I have ran valgrind with glewinfo, glxgears, and them all showed leaks
03:13 #dri-devel: < ishitatsuyuki> If it's using some GC model, "leaking" is not a problem
03:13 #dri-devel: < imirkin> ishitatsuyuki: definitely not by design ... shouldn't be leaking
03:13 #dri-devel: < imirkin> how are you exiting glxgears & co? if it's with ^C
03:14 #dri-devel: < imirkin> then those applications don't clean up
03:14 #dri-devel: < ishitatsuyuki> Esc
03:14 #dri-devel: < imirkin> and so you end up with "leaked" memory, aka not cleaned up
03:14 #dri-devel: < imirkin> hm, that should be fine
03:14 #dri-devel: < ishitatsuyuki> ==8357== definitely lost: 71,636 bytes in 18 blocks
03:14 #dri-devel: < ishitatsuyuki> ==8357== indirectly lost: 31,498 bytes in 131 blocks
03:14 #dri-devel: < ishitatsuyuki> ==8357== possibly lost: 23,299,466 bytes in 8,201 blocks
03:14 #dri-devel: < imirkin> this is what i get with mesa 12.0.1 on nouveau:
03:15 #dri-devel: < imirkin> i believe that xcb thing is expected... statically allocated or something like that
03:15 #dri-devel: < imirkin> i forget the details, but it's hard to worry about a 36-byte leak
03:16 #dri-devel: < ishitatsuyuki> Maybe I really terminated by Ctrl C
03:16 #dri-devel: < ishitatsuyuki> Well, it was my fault, it now only leaks <1KB
03:17 #dri-devel: < imirkin> it really should be approaching 0
03:17 #dri-devel: < imirkin> if you're seeing more than that 36-byte xcb alloc, i'd report it. unless it's some llvm thing - that might not be clean-up-able
03:18 #dri-devel: < ishitatsuyuki> Well, I can't say anything about that
03:18 #dri-devel: < ishitatsuyuki> I got 112 bytes from an unknown source
03:19 #dri-devel: < ishitatsuyuki> Everything has missing symbls
03:19 #dri-devel: < imirkin> oh, that's sad.
03:19 #dri-devel: < imirkin> well, without debug symbols available, any report is going to be useless =/
06:40 #dri-devel: < lordheavy> airlied , bnieuwenhuizen: current radv/semi-interesting doesn't build
06:49 #dri-devel: <+airlied> lordheavy: doh , fixed now
06:50 #dri-devel: < lordheavy> airlied: thanks :)
07:41 #dri-devel: < itoral> tarceri_: is component packing enabled in master? I noticed that we need to adapt our fp64/align16 implementation to the component packing changes that landed in master but I am not sure if it is in effect yet (I always see component=0)
07:42 #dri-devel: < Kayden> it is
07:46 #dri-devel: < itoral> aha, so what would I need to do to see a component value that is not zero? I have tried mixing various double types for inputs and outputs (double + dvec3, dvec3 + dvec3, etc) but does not seem to have any effect on the intrinsic components I see
07:48 #dri-devel: < itoral> the fp64 tests in piglit pass, and so do the few tessellation tests that use doubles, but I think these tests might not be exercising these paths so I was trying to do write a few new tests for this
07:58 #dri-devel: < tarceri_> itoral: you can only pack doubles with doubles and a dvec3 starting as component 0 with a double at component 3
07:59 #dri-devel: < tarceri_> everything else is illegal
07:59 #dri-devel: < tarceri_> there *should* be piglit tests but I may have missed something
08:03 #dri-devel: < itoral> tarceri_: ok, thanks
08:04 #dri-devel: < tarceri_> the piglit tests are in tests/spec/arb_enhanced_layouts/execution/component-layout
08:04 #dri-devel: < tarceri_> the execution tests that is
08:04 #dri-devel: < itoral> tarceri_: ok, I'll look into them, thanks!
09:06 #dri-devel: < arnd> agd5f: 737a44b106b9 ("drm/amdgpu/powerplay: endian fixes for ppatomctrl.c") caused a new warning in today's linux-next:
09:06 #dri-devel: < arnd> ../drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c: In function 'atomctrl_set_ac_timing_ai': include/uapi/linux/byteorder/big_endian.h:32:26: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
09:07 #dri-devel: < arnd> I've done this patch for it:
09:07 #dri-devel: < arnd>
09:08 #dri-devel: < arnd> but I then saw that you have the same bug in lots of other places in both the radeon and powerplay drivers, they just don't cause the warning
09:08 #dri-devel: < arnd> basically you cannot use bitfields in hardware data structures
09:08 #dri-devel: < arnd> because the ordering of the bits depends on the ELF ABI rather than the CPU endianess
09:10 #dri-devel: < arnd> agd5f: which architecture did you test this on?
09:57 #dri-devel: < tomeu> danvet: finally got the tests to pass with rockchip's pipe crc impl
09:57 #dri-devel: < tomeu> I will be working on getting the analogix dp driver use the dp helpers in the core
09:57 #dri-devel: < tomeu> danvet: any feedback on v3 of the series?
11:24 #dri-devel: < nha> so, I probably missed a discussion about this, but what are people's opinions on the mismatch between ARB_gpu_shader5 bitfieldInsert/bitfieldExtract and Gallium's (DX-inspired) IBFE etc. instructions?
11:24 #dri-devel: < nha> specifically, the behavior is different when offset = 0 and bits = 32
11:24 #dri-devel: < nha> but bitfieldInsert/Extract are directly lowered to those TGSI instructions
11:47 #dri-devel: < danvet> sumits, I guess 4.8 is closed for sure now for dma-buf stuff :(
11:47 #dri-devel: < danvet> padovan, ^^
11:48 #dri-devel: < padovan> danvet: yeah, it is all 4.9 now.
11:48 #dri-devel: < padovan> the main user is drm fences, so it is okay to have it only on 4.9
11:49 #dri-devel: < danvet> sumits, btw around for a quick chat?
12:21 #dri-devel: < danvet> robher, anholt: that gbm mmap interface - does it use the shiny new sync ioctl?
12:21 #dri-devel: * danvet too lazy to read code
12:23 #dri-devel: < danvet> oh, this isn't directly about dma-buf mmap
13:25 #dri-devel: < agd5f> arnd, x86
13:25 #dri-devel: < l1k> danvet: thanks a lot for shepherding all the stray dri-devel patches into drm-misc, much appreciated.
13:33 #dri-devel: < arnd> agd5f: how about just reverting your patch for now then? if we want this driver to work on big-endian machines that would require a lot more work to get rid of the bitfields
13:36 #dri-devel: < agd5f> arnd, BE is better off with the patch than without
13:36 #dri-devel: < agd5f> I can drop the specific changes that cause the error
13:37 #dri-devel: < agd5f> most of the changes are just simple 16 and 32 bit swaps
13:37 #dri-devel: < arnd> ok
13:38 #dri-devel: < arnd> agd5f: can you also change the types from uint32_t to __le32 then?
13:38 #dri-devel: < arnd> otherwise you get a lot of sparse warnings
13:39 #dri-devel: < arnd> that should also make it clear what work remains -- just don't annotate the bit fields that are left untouched
13:41 #dri-devel: < agd5f> arnd, I'll take a look
13:41 #dri-devel: < arnd> thanks!
14:55 #dri-devel: < sumits> danvet, sorry missed your ping
14:56 #dri-devel: < sumits> danvet, be back in about an hour or so, post dinner, will ping then
15:40 #dri-devel: < mareko> has anybody tried to build cts from master with x11_egl_wrapper?
15:40 #dri-devel: < Kayden> I've been using the 45release branch, rather than master, but x11_egl_wrapper seems crashy and awful
15:43 #dri-devel: < Kayden> I've been using some patches to make it run on gbm
15:43 #dri-devel: < Kayden> I'll email them to you in case they're useful
16:02 #dri-devel: < mareko> Kayden: does nha have those patches as well?
16:02 #dri-devel: < mareko> he's been using cts quite a lot AFAIK
16:08 #dri-devel: < Kayden> no, feel free to forward them on
16:08 #dri-devel: < Kayden> I'm not actually sure what Dave or the Igalia folks have been doing
16:08 #dri-devel: < mareko> ok thanks
16:10 #dri-devel: < Kayden> we should probably try to get some variation of those upstream...gbm is handy
16:10 #dri-devel: < imirkin_> sad ... x11_glx works so well on dEQP. i would have thought they'd be similar =/
16:11 #dri-devel: < Kayden> yeah...might be worth trying to port that over too
16:11 #dri-devel: < Kayden> I think the deqp in the CTS is older, there are a number of things that don't work right.
16:19 #dri-devel: < Kayden> I just realized...khronos uses git now, I can be civilized and post a branch
16:19 #dri-devel: < Kayden> the 'gl45release' branch of kayden/cts.git on gitlab has the gbm patches, if anybody wants them
16:40 #dri-devel: < krh> go go git
17:09 #dri-devel: < tstellar> tests/ appears to be running glslparsertest.
17:46 #dri-devel: < mareko> I wonder if piglit is good for running cts and deqp, because it seems to be slower
18:10 #dri-devel: < robclark> mareko, it runs everything in separate processes which is sometimes nice (ie. when something crashes).. but much slower IMO..
18:18 #dri-devel: < tstellar> Does piglit run those tests concurrently?
18:22 #dri-devel: < imirkin_> tstellar: yes, unless you pass -1 to disable it
18:23 #dri-devel: < robclark> tstellar, I think the gain from running in parallel isn't close to offset offset the loss by process startup/teardown time for most of the tests
18:24 #dri-devel: < bnieuwenhuizen> is there an easy way to skip a hanging test with piglit resume?
18:24 #dri-devel: < mareko> no, you have to use -c to enable concurrency
18:24 #dri-devel: < bnieuwenhuizen> (as well as figure out the name of the hanging test)
18:24 #dri-devel: < mareko> bnieuwenhuizen: ctrl+f1 ... ps aux|grep piglit
18:24 #dri-devel: < imirkin_> mareko: -c is to force tests that were explicitly marked as non-concurrent to be run concurrently anyways
18:25 #dri-devel: < bnieuwenhuizen> mareko: whole computer is hung, including ssh
18:25 #dri-devel: < mareko> bnieuwenhuizen: so that must be a kernel crash or PCI hang
18:26 #dri-devel: < mareko> bnieuwenhuizen: run piglit with -v -1 and watch the screen
18:26 #dri-devel: < mareko> also disable the GPU reset
18:26 #dri-devel: < bnieuwenhuizen> how do I disable GPU reset (on amdgpu?)
18:27 #dri-devel: < mareko> add to your kernel cmdline: radeon.lockup_timeout=0 amdgpu.lockup_timeout=0
18:28 #dri-devel: < mareko> with that, you can sometimes do ctrl+f1 after a hang and ssh usually works
18:57 #dri-devel: < agd5f> amdgpu.lockup_timeout=0 is the default for amdgpu
19:52 #dri-devel: < mareko> bnieuwenhuizen: you can also try GALLIUM_DDEBUG="pipelined 10000" and if the kernel doesn't crash, you'll get a hang report
19:52 #dri-devel: * bnieuwenhuizen is trying to run the vulkan CTS
19:52 #dri-devel: < bnieuwenhuizen> no gallium involved
19:54 #dri-devel: < bnieuwenhuizen> but I've found that the issue was a kernel regression
20:17 #dri-devel: < agd5f> bnieuwenhuizen, airlied, there is a new fence ioctl we added to the hybrid driver for vulkan fences that might be useful to you. We haven't tried to upstream it since nothing open uses it yet.
20:24 #dri-devel: < agd5f>
20:24 #dri-devel: < bnieuwenhuizen> agd5f: I think for implementing support in radv it would be nice if the source of the libdrm bits are also available
20:25 #dri-devel: < agd5f> bnieuwenhuizen, shouldn't be an issue
20:39 #dri-devel: < bnieuwenhuizen> oh, nvm, I found a commit on your libdrm tree with sources:
20:42 #dri-devel: <+airlied> mareko: i use an x11_egl target, no wrapper
20:42 #dri-devel: <+airlied> cts in git has it, not sure if cts in tarball does
20:43 #dri-devel: <+airlied> I also don't use piglit, but piglit is useful if certain tests kill the test run
20:43 #dri-devel: <+airlied> also my CTS branch in gitlab has a bunch of fixes that I haven't sent yet
21:20 #dri-devel: < robher> airlied: can you please apply this patch for virgl:
22:02 #dri-devel: <+airlied> robher: it's on my list, just havent had cycles yet, will try today
23:21 #dri-devel: <+airlied> robher: done
23:23 #dri-devel: < robher> airlied: thanks

Written by Christoph Brill © 2007-2016

Valid XHTML 1.0 Transitional

Available in Android Market