07:14 pq: Can 0 be a valid value for an enum value in a KMS property?
07:16 pq: looks like yes
08:02 DPA: /etc/drirc - can I somehow use this instead of setting ETNA_MESA_DEBUG=nir?
08:02 DPA: It would allow me to get rid of a horrible hack I use to work around display managers unsetting all env variables before starting Xorg (https://github.com/Daniel-Abrecht/libenvpreload)
08:05 pq: DPA, oh, that's innovative, I would have expected you just mv Xorg and put a shell script as the new Xorg :-)
08:08 DPA: pq: I wanted it to survive updates.
08:08 pq: indeed
08:09 pq: not sure if display managers deliberately clear the environment, it may be just a side-effect of setuid-root and not restoring the env fully.
12:54 sravn: tzimmermann: Do you plan to apply "au1100fb: Remove NULL pointer check before clk_enable/disable" too?
12:54 sravn: Looks good, and extra polishing can be a new patch
12:55 tzimmermann: sravn, i was hoping the author would send another patch with my comments addressed
12:55 tzimmermann: so i didn't r-b it
12:56 sravn: I learned the hard way that applying trivial patches is often better than waiting for new iterations. This is also a good way to encourage people to write more patches
12:57 tzimmermann: ok, lol
12:57 tzimmermann: i'll add it to drm-misc-next then :)
12:59 sravn: thanx
12:59 sravn: One less patch in my huge pending queue
17:00 therealjumbo: I'm not sure if I'm barking up the wrong tree (bit of a graphics newb) but I'd like to do software rendering on a imx6ULL
17:01 therealjumbo: so that obviously doesn't have a gpu
17:01 therealjumbo: but mesa has a swrast driver, should that work without a drm driver or...?
17:02 therealjumbo: i'm using buildroot btw
17:02 danvet_: therealjumbo, probably want to use llvmpipe, and yeah that should work
17:03 therealjumbo: llvmpipe only works on x86, x86_64 and ppc right?
17:03 therealjumbo: that's what i gleaned from the docs
17:04 therealjumbo: the opengl path through mesa will be a fallback, so it doesn't need to be fast, it just needs to work
17:06 danvet_: tbh I don't know, but I kinda assumed llvmpipe would work anywhere llvm works
17:06 danvet_: and that should include arm
17:07 FLHerne: therealjumbo: I think the docs must be outdated, it definitely works on ARM
17:08 danvet_: having roughly 0 clue and from a quick look, it uses generic llvm builders and no intrinsics
17:08 danvet_: so this should work
17:08 danvet_: and yeah "docs are outdated" most likely explanation
17:10 therealjumbo: ok that's good to know
17:11 therealjumbo: so the imx6ULL uses a kernel fbdev driver, when i compiled mesa i see that the libEGL.so is linked to libdrm.so
17:11 therealjumbo: that means i compiled it wrong right?
17:12 danvet_: shouldn't matter
17:12 danvet_: I mean some extra code in there, but it should still be able to fall back to llvmpipe
17:12 FLHerne: It might mean you managed to compile in more drivers than you wanted, but they shouldn't do anything
17:12 therealjumbo: ok, i'll try again with llvmpipe instead of swrast
17:13 danvet_: I'm not sure how well or if at all llvmpipe works automatically in X and wayland if you have an fbdev driver
17:13 therealjumbo: as is, when I start a QT app i get a failure to detect drm device
17:13 danvet_: but for kms-only drm drivers it should Just Work
17:13 danvet_: hm it should still find llvmpipe
17:13 therealjumbo: oh right, so i'm not using X, and its a fbdev drive
17:13 danvet_: tbh not sure how you get gbm going without drm
17:14 danvet_: you'd need something like EGL for fbdev, which doesn't exist
17:14 danvet_: I think OSMesa is the only other option, but not sure how well that works
17:14 therealjumbo: right ok, that's what I thought, if i don't have a drm driver in the kernel but instead fbdev then i can't use mesa
17:15 therealjumbo: would another option be to port a revert of this commit onto my version: https://cgit.freedesktop.org/mesa/mesa/commit/?id=17645103aaa937d24d58d110b845200c637c2365
17:16 therealjumbo: but i wasn't sure, since i saw the software render drivers, and the only reason you would use them i thought would be if you didn't have a gpu, and if you don't have a gpu then you don't have a drm device?
17:17 FLHerne: therealjumbo: You should be able to use OSMesa, like danvet_ says: https://docs.mesa3d.org/osmesa.html
17:18 FLHerne: therealjumbo: But you might need to modify the application slightly
17:18 therealjumbo: ok, so Qt would need to know how to use that
17:19 therealjumbo: i can hack in the -lOSMesa easily enough but...
17:20 therealjumbo: and how does GL_FRONT map to the /dev/fb0 or /dev/fb1?
17:26 therealjumbo: i guess i must be missing some understanding of how the different pieces all fit together if its a sw only render
17:29 linkmauve: danvet_, llvmpipe uses wl_shm on Wayland, so it doesn’t depend on dmabuf or any support for wp_linux_dmabuf or wl_drm in the compositor.
17:30 linkmauve: EGL programs will automatically fallback on llvmpipe when the compositor doesn’t expose any of the latter two globals.
17:31 linkmauve: therealjumbo, any reason you can’t use DRM?
17:31 therealjumbo: linkmauve: there isn't a kernel drm driver that works on that hardware
17:31 linkmauve: Ok.
17:32 therealjumbo: unless there is a software only kernel drm driver, but as far as I can tell those are "virtual" only for testing, they don't actually write to a screen
17:32 therealjumbo: vkms and vgem
17:41 danvet_: linkmauve, hm right if this is on wayland
17:41 danvet_: I figured it's bare metal
17:42 therealjumbo: its not on wayland
17:42 danvet_: yeah then I think you're down to osmesa
17:43 danvet_: therealjumbo, I think the real problem is ... why don't you have a drm kms driver for your display?
17:43 therealjumbo: ok, i think i built it wrong then
17:43 danvet_: fbdev is kinda dead
17:43 therealjumbo: ya i know... but that's all the imx6ULL supports, and for some reason somebody decided to use that processor for a product with a display...
17:44 danvet_: might be quicker to type the drm driver :-)
17:44 therealjumbo: the long term plan (in my head) is to use qt quick 2d for the vast majority of painting, and the sw based opengl implementation from mesa would just be a fallback
17:44 therealjumbo: haha
17:45 therealjumbo: it might be faster if i knew a thing or two about linux graphics...
17:45 danvet_: oh just remembered surfaceless
17:45 danvet_: https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_platform_surfaceless.txt
17:45 danvet_: this might also work
17:46 therealjumbo: ok i'll check that out
17:48 therealjumbo: https://www.collabora.com/news-and-blog/blog/2018/08/01/kms-swrast-hardware-backed-graphics-driver/ ok i think that answers some of my questions
17:49 therealjumbo: specifically: "The DRM driver is actually only used for a single thing, to allocate a slice of memory which can be used to render pixels to and then be sent to the display."
17:49 therealjumbo: so maybe i do want vkms
17:49 therealjumbo: i'm not sure
17:49 sravn: therealjumbo, danvet_ I think imx6ULL is supported by mxsfb - no?
17:50 therealjumbo: sravn: you mean CONFIG_FB_MXS?
17:52 sravn: No, DRM_MXSFB. I says imx6sx though, so maybe imx6ull is not supported
17:53 therealjumbo: i don't think it works, i was gonna try that next but somebody else told me that just crashes on the imx6ULL
17:53 sravn: therealjumbo: Try to ask at #linux-imx - they may know the details
17:53 therealjumbo: ahh that's a good idea
17:53 therealjumbo: sravn: thanks
17:53 vsyrjala: if i read the dts stuff right imx28-lcdif is what gets you the fbdev driver on imx6ull
17:54 therealjumbo: vsyrjala: ya
17:54 vsyrjala: hmm. but that's also in the drm driver
17:54 therealjumbo: yuo
17:55 therealjumbo: yup
17:56 vsyrjala: hmm. must have misread something since imx*-fb is what the fbdev driver is looking for. not sure where that is in the dts though
17:59 vsyrjala: confused. to me it looks like only the drm driver is possible on imx6ull
17:59 vsyrjala: also confused by the drm driver being named mxsFB
18:02 vsyrjala: says the guy working on a driver named after a 15 year old chipset
18:26 lrusak: Hey guys, looking for some advice. For Kodi we are trying to build all windowing systems in one binary (x11, wayland, drm/kms) however we have an issue with the EGL/egl.h include file. I feel the best way is to define EGL_NO_X11 for all platforms, however if __GBM__ is defined that is chosen first. Should I just undef the define before including EGL/egl.h or what? reference: https://github.com/xbmc/xbmc/pull/18560
18:27 lrusak: or do we just try and use EGL_EXT_platform_base ?
18:27 lrusak: I'm not sure which version of android that requires
18:28 anholt: have you looked into waffle? it could possibly help with this.
18:28 lrusak: yea I know about it. Didn't really want to add another dependency though :/
18:30 anholt: I'd also recommend libepoxy for interacting with loading EGL extensions. But yes, you really want to use platform_base for choosing your egl platform. As far as the silly EGLNative* types, in code like that I would be aiming to run things though void * because you can't have a single type that makes sense.
18:42 lrusak: gotcha
18:53 anholt: jekstrand: I'm so close on ntt. now, the live index change is making a collection of shaders that fail nir validation return different pass/fail states in piglit, though there's no change in NIR_PRINT output. My inclination is to just update the piglit test expectations because the result of OOB access of components IR vectors (the validation failure) is undefined
19:05 lrusak: what android api added EGL_KHR_platform_android ?
19:08 lrusak: seems like android 10 implemented EGL 1.5
20:56 jekstrand: anholt: On what drivers? Should we just fix those bugs? :-
20:56 jekstrand: :-P
20:56 anholt: jekstrand: llvmpipe
20:57 anholt: bad things happening with double in/outs
20:57 jekstrand: Oh...
20:57 anholt: it's not a new bug, and I don't have any idea what the challenge will be in fixing it. I wouldn't be the first to try
20:57 jekstrand: anholt: Test name?
20:58 jekstrand: anholt: That fails on Master
20:59 anholt: check out the .gitlab-ci/piglit/quick_shader.txt changes
20:59 anholt: ~/src/piglit/generated_tests/spec/arb_gpu_shader_int64/execution/inout/vs-out-fs-in-S1-float-float-float-i64vec3.shader_test for example on master
21:10 airlied: anholt: my brain put those fails down as a higher level non-driver problem, so I never really looked into them
21:11 anholt: me too!
21:11 anholt:spent plenty of time in swrast driver 64-bit pain in this branch already
21:12 anholt: softpipe doubles are such a mess.
21:13 airlied:has to back and make the st pass 64-bit for real at some point
21:13 anholt: (don't go fixing the tgsi_exec bugs, because gtt's got equivalent bugs on the input!)
21:13 airlied: big endian won't appreciate it
21:13 jekstrand: anholt: If it's just llvmpipe 64-bit inputs falling over, I don't care.
21:13 anholt: jekstrand: a sensible answer
21:13 jekstrand: anholt: I'm seeing it fall over inside GLSL IR validation....
21:14 anholt: what I'd really like is for a bit more nir_validate perf so we could stop turning our obvious failures into UB with NIR_VALIDATE=0 in CI
21:14 jekstrand: anholt: I imporoved it massively earlier this year
21:15 jekstrand: shader-db with validation on vs. off is only 2x.
21:15 jekstrand: It used to be more like 10x
21:15 anholt: jekstrand: was thinking, given recent talk about ssa def count, that we could swap out the sets in favor of a bitset or two using def->index
21:16 airlied: jekstrand: yeah falling over in GLSL IR was what made me assume I didn't care
21:16 jekstrand: anholt: Part of why we use a hash set is to validate that def->index is unique
21:16 jekstrand: I think I did look into that
21:18 jekstrand: Is there some crummy GLSL IR thing for lowering 64-bit values to vec2s?
21:25 jekstrand: Looks like GLSL I/O packing is screwing up
21:28 airlied: tarceri: may be a better person to dig into it
21:28 Lightkey: zmike: features.txt still lists zink for GL_ARB_blend_func_extended and GL_ARB_occlusion_query2 even though GL 3.3 is all DONE.
21:29 jekstrand: blend_func_extended is an ES feature, not desktop.
21:31 Lightkey: It's in OpenGL 3.3. ¯\_(ツ)_/¯
21:35 jekstrand: Uh... Maybe I'm thinking of a different feature
21:35 jekstrand: Oh, I'm thinking of blend_equation_advanced.
21:35 bnieuwenhuizen: everything GL_ARB should definitely be desktop GL?
21:35 jekstrand: Totally different thing. :-)
21:36 bnieuwenhuizen: after too many extended and advanced features one gests confused about the baseline? :P
22:36 jekstrand: Ok, I know what's going wrong... sort-of
22:36 jekstrand: i'm just very confused as to why this doesn't break in iris
22:37 jekstrand: Or literally all other GL drivers
22:37 jekstrand: Oh, no, it's busted on iris too. Great!
22:41 jekstrand: I just don't know what the correct fix is. Should we allow a uint64 to straddle two locations? Or should we align it?
22:41 jekstrand: tarceri: ^^
22:41 jekstrand: tarceri: Looking at generated_tests/spec/arb_gpu_shader_int64/execution/inout/vs-out-fs-in-S1-float-float-float-i64vec3.shader_test
22:42 jekstrand: Or someone else who knows about varying packing
22:55 Kayden: I would be inclined to align it to the data type size
22:55 Kayden: it's probably possible to not align it for a bunch of HW
22:56 Kayden: or just pass it as 2x32
22:56 Kayden: since it's flat and doesn't need interpolation like a double would
22:58 jekstrand: Doubles don't get interpolate
22:58 jekstrand: *interpolated either
22:58 Kayden: ah, right
22:58 jekstrand: The case that's messing up is one where a i64 ends up on the edge of a vec4 location (in this case because there are three floats in front of it)
22:59 tarceri: jekstrand, anholt: I haven't read the who backlog but maybe these are what you are looking for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2332 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2333 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3146
23:00 jekstrand:sees the amount of commentary on those issues and walks awa
23:00 jekstrand: *away
23:01 tarceri: There are major issues with handing of 64 bit varyings and structs, my idea at the time was to just fix it by implementing support for linking varyings with a new nir based linker rather than hacking up the exiting mess
23:02 tarceri: unfortunately I didn't get that far with a nir linker and I'm not sure I will
23:03 tarceri: I believe none of the glsl ir fixes proposed so far have fully fixed all issues
23:39 imirkin: jekstrand: at the API level, you have to align. you can't have a i64 at a components=3 offset.
23:40 imirkin: there are also various rules about what can and can't share slots