01:07 azubieta: Hello folks! I'm building an AppImage that bundles everything but the linux kernel. But I'm having issues when the app tries to load a dri drivers from the host system. I wonder if there is a way to split an app from the libdrm subsystem?
01:08 azubieta: Or at least avoid the loading of the host system drivers. (That produces a crash because of different versions of glib loaded at the same time)
01:09 imirkin: so what contributes to something being part of the app vs party of the host system?
01:10 imirkin: i.e. how do you make that distinction?
01:10 azubieta: right now my AppImage bundles everything but the kernel
01:10 imirkin: so... including glib
01:10 azubieta: correct
01:10 imirkin: and what are you referring to when you say "host system drivers"?
01:11 azubieta: libs like this /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
01:11 imirkin: so ... not part of the kernel
01:11 imirkin: i.e. part of your AppImage?
01:12 azubieta: but the problem is that my AppImage will become huge if I bundle every private driver
01:12 imirkin: well, libGL is a good place to make the cut
01:12 imirkin: the libGL ABI is super-stable
01:13 azubieta: so it will be libGL*
01:13 imirkin: unfortunately those libs could be linked against other versions of the same libraries as the ones in your AppImage though
01:13 imirkin: and so you're essentially screwed
01:13 imirkin: this is why creating such "packs" is a hard problem.
01:13 azubieta: indeed
01:14 imirkin: e.g. the app uses boost vA, and the driver uses boost vB, and you're screwed.
01:14 imirkin: thankfully the drivers don't use boost, but they could use llvm, or libstdc++, or anything else
01:14 azubieta: or glib
01:14 imirkin: seems like the least of your worries, but sure.
01:14 HdkR: There was a talk at Fosdem about the Steam app containers which was pretty interesting. End result seems to be problems problems problems
01:15 imirkin: hehehe
01:15 azubieta: HdkR do you have a link ?
01:15 HdkR: https://www.youtube.com/watch?v=KrbWbBYAolo
01:15 azubieta: thanks
01:16 imirkin: note that nothign (sane) links against libGLX_nvidia.so
01:16 imirkin: but libGL will dlopen() some stuff, which will dlopen() some stuff, and there you are.
01:16 azubieta: is there a way to avoid libGL to look into the system libs
01:16 azubieta: I'm using LIBGL_DRIVERS_PATH="${APPDIR}/usr/lib/x86_64-linux-gnu/dri"
01:16 imirkin: how would it work?
01:17 azubieta: but it also searches for the system ones
01:17 imirkin: that's surprising
01:17 imirkin: probably could be considered a bug if LIBGL_DRIVERS_PATH is set
01:17 imirkin: but this is also a mesa feature, not a general libGL thing
01:17 imirkin: glvnd was supposed to fix some of this, i think
01:18 azubieta: but /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 is not precisely a driver
01:18 imirkin: but frankly i haven't kept up.
01:18 imirkin: also the fact that you're mentioning nvidia means you're on a different libGL impl than mesa.
01:19 azubieta: or maybe is Qt the one who is loading that lib
01:22 imirkin: nothing will ever directly load libGLX_nvidia
01:22 imirkin: however libGL could certainly dlopen() it
01:22 imirkin: and qt uses GL to draw ... everything
01:23 HdkR: Yea, would just be the blob opening it when GLX/GL is used. Delete the blob? :P
01:27 azubieta: I see
01:27 azubieta: thank you guys!
01:27 azubieta: or gals :)
12:26 FLHerne: What's OpenCL like on r600 (specifically a Palm APU) ?
12:26 FLHerne: clinfo reports its existence, but is it in a state where it's worth trying to use?
12:57 Phils3r: hi guys. I have issues with current mesa 20.0.0
12:58 Phils3r: I have a brand new amd rx 5600 xt graphics card and I compiled the recently released mesa 20.0.0 and I use a current kernel 5.5.2
12:58 Phils3r: But I get this error when trying to run glxinfo
12:58 Phils3r: `MESA-LOADER: failed to open swrast (search paths /usr/lib64/dri)`
12:58 Phils3r: `libGL error: failed to load driver: swrast`
12:59 Phils3r: of course those two files are present `/usr/lib64/dri/kms_swrast_dri.so /usr/lib64/dri/swrast_dri.so`
12:59 Phils3r: what is wrong?
12:59 Phils3r: has somebody a hint
13:04 jcdutton: Phils3r, it cannot find the gl drivers for you GPU. So, it is using trying to use software rast
13:06 Phils3r: jcdutton: Good hint. Howto debug this? Should I post dmesg and xorg.log?
13:07 Phils3r: I debug this for a long time now but I didn't made any further progress
13:11 Phils3r: dmesg: https://gitlab.com/snippets/1943858
13:11 Phils3r: xorg.log: https://gitlab.com/snippets/1943856
13:12 Phils3r: i found this line `[ 9.667] (II) AMDGPU(0): 2D and 3D acceleration disabled`
13:12 Phils3r: this looks wrong to me
13:13 Phils3r: btw. The rpm package I built for mesa 20.0.0 works flawlessly on my laptop with a intel card
13:17 Phils3r: I also found something about drm. Is my version of libdrm to old?
13:18 Phils3r: this commit includes the marketing name of my amd gpu: https://gitlab.freedesktop.org/mesa/drm/commit/5c8ff5773298bd88b4133ebee2ceeaf193228b52
13:19 jcdutton: Phils3r, I don't have a navi card, so I cannot really help further.
13:23 Phils3r: ah crap. But your information already helped me a lot. Thank you very much
13:29 Phils3r: I also try to replace the amdgpu.ids and navi10_smc.bin
13:29 karolherbst: the links are incorrect on our gsoc org page: https://summerofcode.withgoogle.com/organizations/5677334599827456/
13:29 karolherbst: chat and mailing list both point to the project ideas wiki page
13:30 karolherbst: and why this bi weekly bloging thing?
13:31 karolherbst: ohh weekly
13:31 karolherbst: ehhh
13:31 karolherbst: ?
13:31 karolherbst: why
13:32 karolherbst: mupuf: you added this part, and I kind of assume this was discussed on a board meeting or something, still I see no reason why it has to be phrased like this
13:33 karolherbst: kind of sounds like that if somebody doesn't blog and interact, it fails the program
13:34 mupuf: karolherbst: that's exactly the point
13:34 karolherbst: I don't care if anybod blogs about what they do on gsoc or not
13:34 karolherbst: ;)
13:35 mupuf: no communication == code will never land
13:35 karolherbst: interacting yes, blogging? who cares
13:35 karolherbst: I am not against the idea behind this sentence, I just think it's not well phrased
13:35 mupuf: well, let me explain to you: forcing them to blog is like forcing them to have a rubber ducky
13:36 karolherbst: and where should they blog about it?
13:36 mupuf: 10 years of dealing with students, trust me, this makes a great difference
13:36 mupuf: wherever they want
13:36 mupuf: if they want to blog by sending emails on the mailing list, that works too
13:36 karolherbst: right
13:37 karolherbst: still I would rephrase it as "blog" already has other meanings besides "status report"
13:37 mupuf: but they *need* to be able to explain what they are doing, where they are, and formulate what's next
13:37 karolherbst: better write something like "willing to do a weekly status report" than blogging
13:37 mupuf: and that's a great way to collect feedback earlier rather than later
13:37 karolherbst: or "status report (eg: blog, twitter thread, whatever)
13:37 mupuf: I wouldn't object
13:38 mupuf: twitter: no freaking way
13:38 karolherbst: why not?
13:38 karolherbst: that's what people do these days :p
13:38 karolherbst: of instagram sotries :p
13:38 karolherbst: I really don't care
13:39 karolherbst: nobody young does blogs these days, and that's probably the strongest part of why I think the term "blog" is badly choosen here
13:41 karolherbst: or maybe I totally missed what's that about. Is that for _us_ to have something we can show to everybody or is that something for the students so they reflect upon what they did the last week?
13:42 karolherbst: for the former yes, formal reqs make sense, but if it's the latter I don't see why they shouldn't be able to choose whatever they want... anyway, I dislike of the term "blog" being there
13:45 mupuf: nobody makes technical documentation on twitter
13:46 mupuf: the point is not just to help the student, but it also attracts others
13:46 mupuf: by documenting the experence
13:46 mupuf: this is an important communication document
13:47 karolherbst: I don't agree that something like that doesn't happen on twitter, as I already saw it happening
13:47 karolherbst: but
13:47 karolherbst: it again depends on the formal reqs we want to put there
13:48 karolherbst: should it be an in depth technical status report reflecting all the technical issues and things, being pages long or is it more of an abstract of that the person did last week and more written in an informal language?
13:48 karolherbst: and maybe for some students it's good enough to just write something short and maybe even targeting people that student knows directly or so
13:48 karolherbst: but if it has to be some in depth "technical paper" I agree that twitter won't fit
13:49 glennk: Phils3r, i'd guess you need a newer xorg server than 1.20.3
13:50 karolherbst: _but_ I guess we could put a higher focus on this being a "status report" rather than a "blog" thing. And rephrased the sentence
13:50 karolherbst: I am really just against the term blog than anything else here
13:51 karolherbst: we are not in the year 2000 where "blogs" were the cool new shit
13:51 Phils3r: glennk. I fixed it. Finally. I rebuilt libdrm with the current git commit and now it works
13:52 Phils3r: this took me days
13:54 Phils3r: I'm using openSUSE btw. And I built rpm packages
13:54 Phils3r: jfyi: https://build.opensuse.org/project/show/home:seilerphilipp:mesa
13:55 Phils3r: thank you guys for your help.
13:59 Phils3r: this was a hard way but to get hardware accelerating but it's worth. Time for benchmarking...
14:30 mupuf: karolherbst: feel free to rephrase it to weekly status or whatever ;)
14:31 mupuf: but what is needed is to have the student rephrase everything they are told, tell what is their status, what's coming next
14:31 mupuf: and explain the hickups
14:31 mupuf: and that will help others realize how this is not impossible to achieve
14:32 mupuf: the sooner students write these reports, the easier it is to assess their understanding and steer them towards succeeding
14:32 mupuf: 3 months is super short
14:32 mupuf: and some code has to land, we can't afford to mentor students and have 0 meaningful output
14:33 mupuf: and it is against the GSoC rules
15:01 pinchartl: danvet: you have new bridge documentation in your mailbox
15:02 pinchartl: bbrezillon: and two small bridge doc fixes are for you in the series :-)
15:05 sravn: pinchartl: when can we expect to see your big series start to land in drm-misc-next? For the most part (all?) the patches are reviewed
15:09 sravn: pinchartl: Noticed that what you referenced above is a v7 - so a few new patches in the set.
15:13 pinchartl: sravn: v7 is really a rebase + additional doc requested by Daniel
15:13 pinchartl: assuming the doc is acked, the series is ready for mainline in my opinion
15:14 pinchartl: (and I think Tomi shares that opinion)
15:14 pinchartl: so after getting acks from Daniel and Boris, it can go to drm-mis
15:14 pinchartl: c
15:14 pinchartl: which I hope will happen during the upcoming week
15:23 danvet: pinchartl, sigh on devm_drm_panel_bridge_add_typed
15:23 pinchartl: danvet: I know
15:23 pinchartl: I thought about you :-)
15:23 pinchartl: the series document the current API
15:24 danvet: pinchartl, hm maybe that one is actually correct
15:24 danvet: maybe
15:24 pinchartl: and it's big enough, I don't want to fix that one in yet a new version, it should go on top of your patches
15:24 pinchartl: in any case, not my problem at least until your patches land :-)
15:24 danvet: since it's just the driver registration
15:25 danvet: and the driver probably should be thrown out on unload automatically
15:25 sravn: pinchartl: looks forward to see it land. Will take a look at new patches tomorrow
15:25 danvet: except ... we're guaranteed to get all the lifetimes wrong with this, if it's not backed up by refcounts and more magic :-)
15:25 pinchartl: yep
15:26 pinchartl: danvet: as another token of good will, I've sent you a drm_driver constification series
15:26 pinchartl: it's fairly small
15:26 pinchartl: only been compile-tested though, I don't have any DRM_LEGACY device
15:27 pinchartl: danvet: I also wanted to ask you a question about criteria for upstream merge of API extensions
15:28 pinchartl: it's well known that DRM/KMS is pretty strict there, and requires an implementation in a major upstream graphics stack
15:28 pinchartl: (X11, wayland or android hwcomposer are usually mentioned)
15:28 pinchartl: I'm however wondering how to handle features that are of little interest to those frameworks, but that can be very useful in embedded systems
15:29 pinchartl: colour keying is one of those
15:29 pinchartl: on a resource-constraint system it's useful to display GUI on top of a video for instance, with two hardware planes controlled directly by a custom application without using X11 or wayland
15:31 pinchartl: similar question for cubic lookup tables that are used for tone mapping. they're mostly used by closed-source components in userspace because vendors believe their implementation has such a big added value that they want to keep it secret. there's however nothing very special in the API itself, it's just another LUT similar to GAMMA and DEGAMMA, except it's a 3D LUT
15:36 danvet: give me a compositor optimized for these cases
15:36 danvet: we've done stuff for special-purpose compositors like kodi in the video space
15:36 danvet: definitely can do special-purpose uapi for other special-purpose compositors
15:37 pinchartl: so that would require me writing a new open-source compositor ? :-)
15:37 danvet: I think that fairly fundamentalist stance hasn't moved, so yes
15:37 pinchartl: how "standard" does it need to be ?
15:38 pinchartl: I've written such compositor code as an example app for a customer in the past, to show them how to use the API
15:38 danvet: so the idea behind that one is that if you have something that's e.g. obviously for a gl driver
15:38 pinchartl: it blends a video stream captured from a camera and a simple GUI
15:38 pinchartl: and the customer then took over and turned that into a full-fledged application
15:38 danvet: and to avoid review from mesa folks, you go ahead and fork mesa and patch it in there and then do a global rebranding of the mesa codebase
15:38 danvet: just to avoid dealing with those folks
15:38 danvet: and that's a clear nope
15:39 danvet: but for embedded space where everyone just makes one-offs anyway
15:39 danvet: I think an example app is plenty good enough
15:39 pinchartl: something similar to kms-quad then for instance ?
15:39 pinchartl: kms-quads
15:39 danvet: I mean ideally that example app has competent error handling and stuff like that, so it serves well as a use-case validation
15:40 pcercuei: danvet: About your drmm_add_final_kfree patchset, is it online on a branch somewhere?
15:40 danvet: v2?
15:40 pcercuei: yes
15:40 pinchartl: danvet: I swear I didn't go around telling people to ask you for git branches :-D
15:41 linkmauve: pinchartl, maybe something like weston?
15:42 pinchartl: linkmauve: do you think colour keying would be easy to integrate in weston ? I'm not so concerned about writing the code itself, but more about having to extent the wayland protocol with features needed to use colour keying (if any)
15:42 pcercuei: I was Cc'd on the patches touching ingenic-drm, but I can't really test them without the rest of the patchset
15:44 danvet: pcercuei, stuff branch on https://cgit.freedesktop.org/~danvet/drm
15:44 danvet: contains way more, but patch series is on top
15:44 danvet: you need linux-next if you want to cherry-pick it to your own branch
15:45 danvet: pinchartl, looked at the docs, had some suggestions for a bit more links between stuff
15:45 pinchartl: danvet: I've seen that, thanks. I'm working on it already
15:45 danvet: pinchartl, and I'm not exactly clear on why I should look at 09?
15:46 danvet: ah the new doc addition
15:46 danvet: ack on that too
15:46 pinchartl: yes, for that
15:47 pinchartl: I'll add your Acked-by tag then, thanks
15:47 danvet: hm, I'd have put this new paragraph into the kerneldoc for drm_bridge_attach
15:48 danvet: but looks good in the overview comment too
15:48 danvet: anyway, ack on that
15:48 pinchartl: thanks
15:55 pinchartl: danvet: there's a comment that states "Both legacy CRTC helpers and the new atomic modeset helpers support bridges", but it actually seems to me that the legacy CRTC helpers don't handle bridges, except for .mode_valid(). am I missing something ?
16:05 danvet: pinchartl, I don't think legacy helpers ever supported bridges ...
16:05 danvet: maybe this should read "probe helpers and atomic helpers"?
16:06 pinchartl: maybe
16:06 pinchartl: I'll reword it anyway
16:11 pinchartl: danvet: http://paste.debian.net/1131545/
16:11 pinchartl: good enough to keep your ack ?
16:12 pinchartl: (missing comma on line 31 before the final "mode")
16:12 pinchartl: and missing parenthesis on the next line too
16:13 pinchartl: http://paste.debian.net/1131546/
16:13 pinchartl: with typos fixed
16:16 danvet: looks excellent I think
16:16 danvet: btw cooking over here, hence random delays and everything :-)
16:17 pinchartl: bon appétit :-)
16:17 pinchartl: I made a fondue savoyarde yesterday evening, that was enough food for two days
16:17 danvet: ah yes
16:18 danvet: feels kinda not cold enough this winter many days
16:18 danvet: I think I only had one this saison at home here
16:19 pinchartl: definitely not cold enough :-(
17:14 karolherbst: mupuf: I gave it some thoughts and I kind of restructured the full list (as there were duplications and it needed some general updates and some additional information: https://gist.github.com/karolherbst/9aa6c9248f9f0aa6ca20fb0e92bb1eef thoughts?
17:16 karolherbst: mhh, seems like the wiki and the gsoc org page was out of sync anyway
20:14 karolherbst: imirkin: I just realized why nvidia uses global memory for contant in CL: those are all indirect and CL also has this 8 cont buffer req, so... I guess they just end up doing the same as we do
20:14 karolherbst: and I guess the indirect overflow also only allows us to address 8 cbs in compute shaders, no?
20:15 karolherbst: like c5[0x60000] is OOB or invalid or something
20:16 karolherbst: well.. than instead of fetching the cb address it is indeed cheaper to just pass in the global pointer :/
21:09 mattst88: anyone have opinions about renaming ALIGN -> ROUND_UP_TO in Mesa, wrt https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3559 ?
21:09 gitbot: Mesa issue (Merge request) 3559 in mesa "FreeBSD Fix" [Opened]
21:14 imirkin: mattst88: seems like unnecessary churn
21:15 imirkin: align/ALIGN are fairly commonly used
21:15 bnieuwenhuizen: mattst88: I thought we already had something like ROUND_UP which implied division?
21:15 imirkin: DIV_ROUND_UP
21:15 imirkin: which is used in the kernel too
21:16 vsyrjala: kernel has ALIGN() for pot, roundup() for everything else
21:17 vsyrjala: hmm. seems there's also round_up() for pot. yay for consistency
21:17 mattst88: I wonder what fbsd's ALIGN macro is, if it's not the same as Mesa's
21:19 vsyrjala: also see a roundup_pow_of_two(). how many of these do people need?
21:20 HdkR: Would be much easier if it was just included in the C and C++ standard since it is used so much :P
21:20 vsyrjala: ah, that last on rounds up to the next pot value. so not the same as the others
21:21 karolherbst: HdkR: that would be too easy ;)
21:21 ccr: would be great to have a time-machine, to send K&R a list of "we _really_ need these things in C to be standard"
21:21 mattst88: ccr: seriously
21:21 HdkR: std::duplicated_gubbins::roundup
21:21 karolherbst: also, what should all the vendors do with their super awesomely highly optimized vendor implementations?
21:22 HdkR: dubious claims of highly optimized
21:22 karolherbst: ahhh
21:23 karolherbst: well, that just means that align will become a function rather than a macro and vendors do dirty tricks to get it as close as possible to the perf of that being a macro ;)
21:23 karolherbst: (and I really hope that's not what's usually happening in C)
21:24 HdkR: oops, you passed something that changed the idiom slightly, now the pattern match failed
21:25 vsyrjala: wrt the original question. ALIGN()->ALIGN_POT() would seem more in line with ALIGN_NPOT(). otoh ROUND_DOWN_TO() already breaks the pattern
21:26 karolherbst: I think that having align as a macro does make sense, because you usually use it to align certain values to a POT value, like pointers. Even if this will just end up being a convenience wrapper around something else
21:28 ccr: why not just add some short prefix to Mesa macro names, would be safer probably?
21:28 ccr: cue bikeshedding tho perhaps :P
21:29 mattst88: (feel free to bikeshed on the MR as well :)
21:29 bnieuwenhuizen: (also random question: why is ALIGN capital case if not a macro?)
21:30 mattst88: bnieuwenhuizen: my guess is that it used to be a macro, and then we decided to make it safer by calling _mesa_is_pow_2 or whatever
21:31 bnieuwenhuizen: (and align64 is lowercase, yay!)
21:32 mattst88: imirkin: I bumped libxcb and ported to EAPI=7 which has better cross-compiling support. if you get a chance before me, would be nice to see if it fixed https://bugs.gentoo.org/558774
21:32 mattst88: otherwise I can dig into it a bit deeper soon
21:38 imirkin: mattst88: i've largely stopped my cross-arch efforts ... the ppc g5's power supply died, and i haven't brought up an arm board in ages =/
21:42 mattst88: imirkin: okay, no problem
21:44 imirkin: mattst88: i wasn't doing anything too odd, just bringning up a new chroot for that arch
21:45 mattst88: imirkin: yeah, I think it should be easy for me to test