04:55 karolherbst: hi, http://cgit.freedesktop.org/mesa/mesa/commit/?id=04e201d0c02cd30ace5c6fe80e9f021ebb733682 this commit broke mesa for me. I get undefined symbols about the sha functions like _mesa_sha1_compute
04:55 karolherbst: I think this is caused by http://cgit.freedesktop.org/mesa/mesa/commit/?id=0db323a62481a57269a46287a64fa743756e80f3 ?
05:01 dboyan: anholt, could you please take a look at http://patchwork.freedesktop.org/patch/58025/
07:21 mareko: imirkin: I wouldn't mind having CULLDIST and CLIPDIST separate outputs, but I'll need correct usage masks
08:47 sarnex: libGL: dlopen /usr/lib64/dri/radeonsi_dri.so failed (/usr/lib64/dri/radeonsi_dri.so: undefined symbol: _mesa_sha1_compute)
08:47 sarnex: what did i do
08:53 imirkin: mareko: i need usage masks too... it's a single bitfield on nvidia hw
08:53 robclark: danvet, anholt, btw, at some point at XDC we need to sit down and talk about atomic/kms vs weird hw with the qcom folks.. some of their hw is starting to get, well, not quite as weird as vc4 yet, but getting there..
08:54 robclark: I think we may end up wanting something like virtual planes too..
09:04 daniels: robclark: virtual planes?
09:04 jekstrand: robclark: Just add an index field to SYSTEM_VALUE. No need to add another #define
09:05 robclark: jekstrand, woah, delayed review/reaction ;-)
09:05 jekstrand: robclark: Also, 8 indices isn't currently posible, we hard-code to 3. Why 8?
09:05 jekstrand: robclark: Sorry, been out for a couple of days
09:05 robclark: ok.. figured a new #define would be less conflicty.. iirc someone else added a new sysval intrinsic reasonably..
09:05 jekstrand: vacationing, that sort of thing.
09:06 robclark: heheh
09:06 robclark: jekstrand, yeah, iirc that should have been s/8/1/
09:06 jekstrand: ok, makes more sense
09:06 robclark: since just one index, with a max value of 8
09:06 jekstrand: Yeah, that makes more sense.
09:06 robclark: I think I changed it locally.. but actually didn't have a chance to finish it.. been bashing android with a hammer..
09:06 imirkin: mareko: btw i think tobijk has some patches for cull dist... he wasn't really sure how to proceed with it all... i kept trying to get him to talk to you and brian, but i don't know if i was successful
09:06 jekstrand: As far as #define being more conflicty, you could just do it in 2 patches.
09:07 jekstrand: heh
09:07 robclark: daniels, ie. whole bunch of KMS plane objects.. possibly exposed in a driver specific way.. which you may or may not be able to use depending on things..
09:08 robclark: brb.. lunch..
10:16 syeh: robclark: I had a look at the commit you pointed out the other day in gralloc_drm_pipe. That get_pipe_format() commit dc21193e3 doesn't look right, so I think you're right in reverting it.
10:16 robclark: cool, thx
10:21 syeh: That translation should be done in MESA by svga_translate_format(), which it is. That commit will end up passing the wrong enum to svga, which should end up breaking things.
10:23 robclark: yeah, that is what I expected..
10:24 syeh: What is that github repo for anyway? Is that where gralloc development is happening?
10:32 robclark: syeh, I think currently "upstream" is android-x86 git tree.. I probably pointed you at commit in my github tree where we are working on freedreno suport for android..
10:32 robclark: syeh, I think xexaxo had mentioned in the past about just pulling drm_gralloc into mesa tree, which imho is a really good idea..
10:33 syeh: Yeah, that makes sense
10:34 imirkin: i asked in xorg-devel but this chan seems to have more people awake... it seems like modesetting aliases all 3 dvi connector names to DVI, which sucks when you have both DVI-D-1 and DVI-I-1... thoughts?
10:36 robclark: imirkin, we have different connector_type for DVID vs DVII.. maybe modesetting just needs to realize that?
10:37 imirkin: robclark: it does. and it sets the name for all 3 connector types to "DVI"
10:37 imirkin: followed by a snprintf(name, 32, "%s-%d", output_names[koutput->connector_type], koutput->connector_type_id - 1);
10:38 robclark: imirkin, http://hastebin.com/raw/icawicayat
10:38 imirkin: robclark: looks a lot like http://hastebin.com/carabesoxu.md :)
10:39 imirkin: which i'm having a user test out atm
10:39 robclark: yup, that's the right thing to do..
10:39 imirkin: although it'll mess up people's existing configs
10:39 imirkin: which is a bit annoying
10:39 imirkin: not a problem for the user in question though
10:40 robclark: yeah, kinda sucks that names aren't standardize.. for me they change when going between -freedreno and -modesetting (ie. HDMI-0 vs HDMI-1)
10:40 robclark: (and, well, if I had DVI those would change too, since -freedreno uses DVI-I/D/A..)
10:40 imirkin: or HDMI1 on intel
10:41 robclark: yeah, it's kinda lols
10:41 imirkin: on the bright side
10:41 imirkin: you can usually tell what driver someone's using just by looking at the output names :)
10:42 robclark: heheh
10:42 imirkin: modesetting also uses DisplayPort instead of DP
10:44 robclark: we probably really should have a common helper for connector names somewhere.. but maybe that ship has sailed..
10:44 vsyrjala: kernel at least is more consistent. would be nice if userspace matched, but hard to change after all this time
10:45 ickle: exactly
10:45 robclark: right
10:46 damien_l: wrandr will solve that!
10:46 imirkin: how?
10:46 imirkin: wouldn't it require people to use wayland?
10:46 ickle: no need for backwards compatibilty
10:46 damien_l: details, details
10:46 vsyrjala: i do hope wayland clients don't have access to the display setup the way x clients have
10:47 ickle: comes in handy though
10:48 vsyrjala: there should be a special client for that. normal clients should maybe just get a list of resolutions or something from the compositor and then the compositor can implement fullscreen mode any which way it wants
10:48 vsyrjala: at least that's how i would do it
10:49 vsyrjala: no idea what's out there in the real world
10:57 robclark: xexaxo, btw, any reason for android build not to just have everything link against liblog? It would make it *far* easier if you need to insert some logs here/there to debug issues (plus _mesa_error() should probably log to android logcat stuff too)
12:07 robclark: ugg, unfortunate name for a intel cpu extension.. http://images.anandtech.com/doci/9582/33.jpg
12:08 imirkin_: isn't that also the name of their PVR-based gpu's?
12:10 robclark: which is why it is unfortunate
12:10 robclark: skylake comes w/ SGX.. surprised we haven't seen the phoronix headline :-P
12:10 imirkin_: at a former company, there was someone who was in charge of naming datacenters in a way that their names didn't sound alike
12:10 imirkin_: i guess intel doesn't have someone like that for their abbreviations :)
12:11 robclark: heheh, guess not
12:12 imirkin_: (after an unfortunate incident where the wrong dc got taken down because it sounded similar to another one, and the info was conveyed over the phone. or at least that's how the story went)
12:12 robclark: whoops
12:29 pavolzetor: hi, I am trying to use git mesa LIBGL_DRIVERS_PATH=/home/pavolzetor/pool/mesa.git/lib/gallium ./fiber_surface
12:29 pavolzetor: and the window does not redraw
12:29 pavolzetor: only when I defocus and refocus
12:30 pavolzetor: if I just boot to the system with installed mesa it works correctly (well worked before the bug in mesa broke it)
12:31 imirkin_: pavolzetor: if you just use 'make install' to some directory and use LD_LIBRARY_PATH, does it work fine?
12:36 pavolzetor: imirkin: I have added LD_LIBRARY_PATH=/home/pavolzer/usr/lib but it did not help
12:38 imirkin_: did you remove the LIBGL_* thing?
12:38 pavolzetor: i do not know why it would be different to the one on the system (which worked before https://bugs.freedesktop.org/show_bug.cgi?id=91263)
12:38 pavolzetor: if I remove it I get segfault (caused by above bug)
12:39 imirkin_: ?
12:39 imirkin_: with LD_LIBRARY_PATH?
12:39 pavolzetor: yes
12:40 imirkin_: are you sure you installed properly?
12:40 pavolzetor: I am not sure
12:40 pavolzetor: I just found typo, sorry
12:40 pavolzetor: libGL error: unable to load driver: r600_dri.so libGL error: driver pointer missing
12:40 pavolzetor: now I am getting this
12:41 imirkin_: you're _sure_ you don't have any of that LIBGL_* stuff left?
12:41 imirkin_: (run 'env')
12:41 pavolzetor: nope
12:42 imirkin_: pavolzetor: LD_LIBRARY_PATH=/home/pavolzer/usr/lib LIBGL_DEBUG=verbose strace -f -e open glxinfo
12:42 imirkin_: pastebin the output of that
12:43 robclark: so, for this pair of VS+FS... any particular reason for glGetAttribLocation(mProgram, "uv") to return -1 ?? http://hastebin.com/egeyozulif.coffee
12:44 pavolzetor: http://pastebin.com/6YyjPkiF
12:45 imirkin_: pavolzetor: did you build it with --with-dri-driverpath=/usr/lib/dri or something?
12:46 imirkin_: pavolzetor: or perhaps you didn't do a full enough rebuild after changing the prefix?
12:46 imirkin_: or perhaps you lied to it about where it was going to get installed?
12:47 imirkin_: in which case you do need to use --with-dri-driverdir=/home/pavolzer/usr/lib/dri
12:47 imirkin_: but that's a very rare setup... i have to do it when i cross-compile into a chroot
12:48 pavolzetor: imirkin: I do not think so, let me rebuild to be sure
13:11 imirkin_: i'm hearing reports of the sha1 thing being broken... anyone else seeing that?
13:13 sarnex: imirkin_: yeah i had that issue earlier
13:13 sarnex: libGL: dlopen /usr/lib64/dri/radeonsi_dri.so failed (/usr/lib64/dri/radeonsi_dri.so: undefined symbol: _mesa_sha1_compute)
13:14 imirkin_: and karolherbst on nouveau
13:14 karolherbst: in fact, every driver gets that issue
13:14 imirkin_: i965 too?
13:14 karolherbst: yes
13:14 sarnex: git revert time?
13:14 karolherbst: obviously compiling with --with-sha1 should fix it
13:15 karolherbst: but http://cgit.freedesktop.org/mesa/mesa/commit/?id=04e201d0c02cd30ace5c6fe80e9f021ebb733682 just uses the sha function without checking
13:15 karolherbst: which is a bug nethertheless
13:15 karolherbst: orr wait
13:15 karolherbst: have to check again
13:16 karolherbst: mhh, seems I am wrong, but it still fails
13:16 karolherbst: for whatever reason
13:16 imirkin_: that stuff should only get referenced when HAVE_SHA1 is defined
13:17 imirkin_: of course the previous configure.ac thing does it completely wrong i think
13:17 karolherbst: that is strange
13:18 karolherbst: "configure: error: Illegal value for --with-sha1: yes"
13:18 imirkin_: look at the help for it
13:18 karolherbst: ohhh
13:18 karolherbst: there are many
13:18 imirkin_: if test "x$with_sha1" = x && test "x$HAVE_SHA1_IN_LIBC" = xyes; then
13:18 imirkin_: with_sha1=libc
13:18 imirkin_: so... you basically always get it
13:19 karolherbst: "configure: error: sha1 in libc requested but not found"
13:19 imirkin_: oh
13:19 imirkin_: or not :)
13:21 karolherbst: will use libgcrypt for now
13:22 imirkin_: fwiw mine comes from libnettle
13:22 karolherbst: which is the prefered one?
13:22 imirkin_: it comes before gcrypt in the fallback list
13:22 imirkin_: dunno
13:23 imirkin_: i see.
13:24 imirkin_: src/util only includes it if you have --enable-shader-cache
13:24 imirkin_: although it defaults to enabled if you have sha1
13:24 karolherbst: mhh
13:24 imirkin_: karolherbst: did you try a make clean?
13:24 karolherbst: I see
13:25 karolherbst: shader cache is off for me
13:25 karolherbst: ohh, ebuild explicitly disables shader cache for the live version
13:26 karolherbst: is there a reason I want that?
13:26 imirkin_: no
13:27 karolherbst: okay
13:27 karolherbst: without disabled shader cache it works
13:29 imirkin_: karolherbst: http://hastebin.com/rocazovama.md
13:30 imirkin_: er wait, that's nto enough
13:30 imirkin_: hold on
13:32 imirkin_: karolherbst: maybe http://hastebin.com/sesokozebi.diff
13:33 karolherbst: I get conflicts
13:33 karolherbst: both hunks failed in src/util/Makefile.sources
13:34 karolherbst: ohh wait
13:34 karolherbst: okay, still with current master
13:34 imirkin_: ?
13:34 karolherbst: patch doesn't want to accept your patch
13:34 imirkin_: damaged whitespace
13:35 imirkin_: coz of the tabs in the Makefile.sources file
13:35 karolherbst: :)
13:35 karolherbst: k
13:35 imirkin_: one mildly annoying thing about the terminal program i use =/
13:35 imirkin_: it gets everything else right though
13:35 imirkin_: [well, that and unicode... heh]
13:36 karolherbst: :D
13:36 imirkin_: but i need non-ascii chars in terminals sufficiently rarely that i don't care
13:36 karolherbst: okay, hunk one is fine now
13:37 karolherbst: okay, non cleaned build worked now
13:37 karolherbst: will do a clean build and verify configure
13:40 karolherbst: imirkin_: yes, your patch works
13:41 imirkin_: cool
13:41 karolherbst: but now enabling shdaer-cache doesn'T trigger rebuilds
13:42 karolherbst: oh well :/
13:43 imirkin_: shader cache doesn't do antyhing
13:44 karolherbst: ohh I see
13:45 karolherbst: anyway, it works now, thanks for your help
13:50 pavolzetor: I tried it also on glarea
13:50 pavolzetor: https://github.com/ebassi/glarea-example
13:51 pavolzetor: LIBGL_ALWAYS_SOFTWARE=ON LD_LIBRARY_PATH=/home/pavolzer/usr/lib LIBGL_DRIVERS_PATH=/home/pavolzetor/usr/lib/dri ./glarea
13:51 pavolzetor: and it still does not refresh until you refocus
14:30 soreau: robclark: Possibly something to do with line 62 of your paste?
14:32 robclark: soreau, oh, that wasn't actually part of the shader, just part of debug prints.. but we determined that varyings that get optimized out (since whole frag shader was commented out) could do that..
14:32 robclark: now just to figure out why mesa crashes without the whole frag shader commented out ;-)
14:43 soreau: Does the information at the bottom of this page stand (for all or some nvidia hw)? ..or only when using older glsl methods? https://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/attributes.php
14:45 imirkin_: not sure what your question is... there's no conflict like they suggest, but on both nv30/nv40 and nvc0+ there are dedicated slots for a few things
14:45 imirkin_: but those aren't at all tied to generic attribute indices
14:45 imirkin_: at least not in mesa
14:46 imirkin_: nv50 is a lot more of no-man's land with remapping things all over
14:46 imirkin_: i guess they decided (and i agree) that it's annoying and went back to a more fixed mapping for fermi and later
15:15 robink:is having some difficulty getting mesa-sha1.o generated and linked against shaderapi.o when linking libOSMesa.so.8.0.0.
15:15 robink: Am I doing something wrong, or did commit 04e201d0c02cd30ace5c6fe80e9f021ebb733682 throw a wrench in the build process?
15:15 robink: It seems to be the most likely cause.
15:15 imirkin: patch on list
15:15 robink: imirkin: Thanks
15:15 imirkin: or remove --disable-shader-cache from configure
15:15 imirkin: (it does nothing btw)
15:16 robink: imirkin: Oh, huh. If I remove --disable-shader-cache, will it not build support for dumping shader sources at runtime?
15:16 robink: imirkin: Not that I need that, just curious.
15:16 imirkin: robink: afaik that enable controls absolutely nothing
15:16 imirkin: except whether mesa-sha1 is built or not
15:16 imirkin: i could have missed something
15:16 robink: imirkin: I...see... Yet enabling it breaks the link process?
15:17 imirkin: actually disabling it breaks the link process
15:17 robink: imirkin: but wait, don't you need mesa-sha1 for the shader source dump support?
15:17 robink: imirkin: Oh, OK
15:17 robink: imirkin: Gotcha.
15:17 imirkin: see http://patchwork.freedesktop.org/patch/58722/
15:17 robink: imirkin: Thanks
15:17 robink: imirkin: I also see that the default Live ebuild for Mesa in the X11 (Gentoo) overlay passes --disable-shader-cache to ./configure always.
15:17 imirkin: indeed it does
15:18 imirkin: which is why many people have been running into this error
15:18 robink: imirkin: Ahh
15:18 imirkin: gentoo's policy is to disable everything imaginable, and make it into a use flag
15:18 robink: imirkin: Heh, yeah, I'm aware of that.
15:18 imirkin: since the shader cache didn't actually do anything, a use flag was never created
15:18 imirkin: (i'm guessing)
15:18 robink: imirkin: One of those things that seems like a Good Idea, but has its (eventually) obvious thorns.
15:19 imirkin: and since it was getting enabled by default by configure, the person making the commit didn't notice the unfortunate interaction
15:22 robink: Ah
15:23 robink: I can submit a bug to bugs.gentoo.org with the patch (and the link to the mbox quilt that you gave me) and an explanation of the issue. I can also ping whomever is currently working media-libs/mesa-9999.ebuild in proj/x11.git.
15:23 robink: Running a compile now with the patch applied
15:24 imirkin: or you can wait the day or two at most that this will take to get in
15:24 imirkin: the patch breaking it only went in today
15:55 robink: imirkin: Gotcha.
15:56 robink: imirkin: OK then, I'm happy to wait, especially since once the commit makes it in the patch in the ebuild will no longer apply and src_prepare will fail.
16:03 robink: imirkin: Compile passes, thanks for the link.
16:03 imirkin: robink: np
18:43 vadimg: airlied: please unban me on #radeon :) but ban me whenever you think it makes sense
18:58 vadimg: airlied: if you see I'm too noisy, I won't be offended in any way if you ban me, I rather ask you to do so (trusting google tranlator)
19:23 airlied: vadimg: should be unbanned now!
19:55 vadimg: airlied: thanks