07:14pq: Can 0 be a valid value for an enum value in a KMS property?
07:16pq: looks like yes
08:02DPA: /etc/drirc - can I somehow use this instead of setting ETNA_MESA_DEBUG=nir?
08:02DPA: 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:05pq: DPA, oh, that's innovative, I would have expected you just mv Xorg and put a shell script as the new Xorg :-)
08:08DPA: pq: I wanted it to survive updates.
08:09pq: 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:54sravn: tzimmermann: Do you plan to apply "au1100fb: Remove NULL pointer check before clk_enable/disable" too?
12:54sravn: Looks good, and extra polishing can be a new patch
12:55tzimmermann: sravn, i was hoping the author would send another patch with my comments addressed
12:55tzimmermann: so i didn't r-b it
12:56sravn: 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:57tzimmermann: ok, lol
12:57tzimmermann: i'll add it to drm-misc-next then :)
12:59sravn: One less patch in my huge pending queue
17:00therealjumbo: 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:01therealjumbo: so that obviously doesn't have a gpu
17:01therealjumbo: but mesa has a swrast driver, should that work without a drm driver or...?
17:02therealjumbo: i'm using buildroot btw
17:02danvet_: therealjumbo, probably want to use llvmpipe, and yeah that should work
17:03therealjumbo: llvmpipe only works on x86, x86_64 and ppc right?
17:03therealjumbo: that's what i gleaned from the docs
17:04therealjumbo: the opengl path through mesa will be a fallback, so it doesn't need to be fast, it just needs to work
17:06danvet_: tbh I don't know, but I kinda assumed llvmpipe would work anywhere llvm works
17:06danvet_: and that should include arm
17:07FLHerne: therealjumbo: I think the docs must be outdated, it definitely works on ARM
17:08danvet_: having roughly 0 clue and from a quick look, it uses generic llvm builders and no intrinsics
17:08danvet_: so this should work
17:08danvet_: and yeah "docs are outdated" most likely explanation
17:10therealjumbo: ok that's good to know
17:11therealjumbo: so the imx6ULL uses a kernel fbdev driver, when i compiled mesa i see that the libEGL.so is linked to libdrm.so
17:11therealjumbo: that means i compiled it wrong right?
17:12danvet_: shouldn't matter
17:12danvet_: I mean some extra code in there, but it should still be able to fall back to llvmpipe
17:12FLHerne: It might mean you managed to compile in more drivers than you wanted, but they shouldn't do anything
17:12therealjumbo: ok, i'll try again with llvmpipe instead of swrast
17:13danvet_: I'm not sure how well or if at all llvmpipe works automatically in X and wayland if you have an fbdev driver
17:13therealjumbo: as is, when I start a QT app i get a failure to detect drm device
17:13danvet_: but for kms-only drm drivers it should Just Work
17:13danvet_: hm it should still find llvmpipe
17:13therealjumbo: oh right, so i'm not using X, and its a fbdev drive
17:13danvet_: tbh not sure how you get gbm going without drm
17:14danvet_: you'd need something like EGL for fbdev, which doesn't exist
17:14danvet_: I think OSMesa is the only other option, but not sure how well that works
17:14therealjumbo: 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:15therealjumbo: would another option be to port a revert of this commit onto my version: https://cgit.freedesktop.org/mesa/mesa/commit/?id=17645103aaa937d24d58d110b845200c637c2365
17:16therealjumbo: 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:17FLHerne: therealjumbo: You should be able to use OSMesa, like danvet_ says: https://docs.mesa3d.org/osmesa.html
17:18FLHerne: therealjumbo: But you might need to modify the application slightly
17:18therealjumbo: ok, so Qt would need to know how to use that
17:19therealjumbo: i can hack in the -lOSMesa easily enough but...
17:20therealjumbo: and how does GL_FRONT map to the /dev/fb0 or /dev/fb1?
17:26therealjumbo: i guess i must be missing some understanding of how the different pieces all fit together if its a sw only render
17:29linkmauve: 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:30linkmauve: EGL programs will automatically fallback on llvmpipe when the compositor doesn’t expose any of the latter two globals.
17:31linkmauve: therealjumbo, any reason you can’t use DRM?
17:31therealjumbo: linkmauve: there isn't a kernel drm driver that works on that hardware
17:32therealjumbo: 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:32therealjumbo: vkms and vgem
17:41danvet_: linkmauve, hm right if this is on wayland
17:41danvet_: I figured it's bare metal
17:42therealjumbo: its not on wayland
17:42danvet_: yeah then I think you're down to osmesa
17:43danvet_: therealjumbo, I think the real problem is ... why don't you have a drm kms driver for your display?
17:43therealjumbo: ok, i think i built it wrong then
17:43danvet_: fbdev is kinda dead
17:43therealjumbo: 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:44danvet_: might be quicker to type the drm driver :-)
17:44therealjumbo: 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:45therealjumbo: it might be faster if i knew a thing or two about linux graphics...
17:45danvet_: oh just remembered surfaceless
17:45danvet_: this might also work
17:46therealjumbo: ok i'll check that out
17:48therealjumbo: 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:49therealjumbo: 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:49therealjumbo: so maybe i do want vkms
17:49therealjumbo: i'm not sure
17:49sravn: therealjumbo, danvet_ I think imx6ULL is supported by mxsfb - no?
17:50therealjumbo: sravn: you mean CONFIG_FB_MXS?
17:52sravn: No, DRM_MXSFB. I says imx6sx though, so maybe imx6ull is not supported
17:53therealjumbo: i don't think it works, i was gonna try that next but somebody else told me that just crashes on the imx6ULL
17:53sravn: therealjumbo: Try to ask at #linux-imx - they may know the details
17:53therealjumbo: ahh that's a good idea
17:53therealjumbo: sravn: thanks
17:53vsyrjala: if i read the dts stuff right imx28-lcdif is what gets you the fbdev driver on imx6ull
17:54therealjumbo: vsyrjala: ya
17:54vsyrjala: hmm. but that's also in the drm driver
17:56vsyrjala: 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:59vsyrjala: confused. to me it looks like only the drm driver is possible on imx6ull
17:59vsyrjala: also confused by the drm driver being named mxsFB
18:02vsyrjala: says the guy working on a driver named after a 15 year old chipset
18:26lrusak: 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:27lrusak: or do we just try and use EGL_EXT_platform_base ?
18:27lrusak: I'm not sure which version of android that requires
18:28anholt: have you looked into waffle? it could possibly help with this.
18:28lrusak: yea I know about it. Didn't really want to add another dependency though :/
18:30anholt: 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:53anholt: 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:05lrusak: what android api added EGL_KHR_platform_android ?
19:08lrusak: seems like android 10 implemented EGL 1.5
20:56jekstrand: anholt: On what drivers? Should we just fix those bugs? :-
20:56anholt: jekstrand: llvmpipe
20:57anholt: bad things happening with double in/outs
20:57anholt: 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:57jekstrand: anholt: Test name?
20:58jekstrand: anholt: That fails on Master
20:59anholt: check out the .gitlab-ci/piglit/quick_shader.txt changes
20:59anholt: ~/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:10airlied: anholt: my brain put those fails down as a higher level non-driver problem, so I never really looked into them
21:11anholt: me too!
21:11anholt:spent plenty of time in swrast driver 64-bit pain in this branch already
21:12anholt: softpipe doubles are such a mess.
21:13airlied:has to back and make the st pass 64-bit for real at some point
21:13anholt: (don't go fixing the tgsi_exec bugs, because gtt's got equivalent bugs on the input!)
21:13airlied: big endian won't appreciate it
21:13jekstrand: anholt: If it's just llvmpipe 64-bit inputs falling over, I don't care.
21:13anholt: jekstrand: a sensible answer
21:13jekstrand: anholt: I'm seeing it fall over inside GLSL IR validation....
21:14anholt: 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:14jekstrand: anholt: I imporoved it massively earlier this year
21:15jekstrand: shader-db with validation on vs. off is only 2x.
21:15jekstrand: It used to be more like 10x
21:15anholt: 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:16airlied: jekstrand: yeah falling over in GLSL IR was what made me assume I didn't care
21:16jekstrand: anholt: Part of why we use a hash set is to validate that def->index is unique
21:16jekstrand: I think I did look into that
21:18jekstrand: Is there some crummy GLSL IR thing for lowering 64-bit values to vec2s?
21:25jekstrand: Looks like GLSL I/O packing is screwing up
21:28airlied: tarceri: may be a better person to dig into it
21:28Lightkey: 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:29jekstrand: blend_func_extended is an ES feature, not desktop.
21:31Lightkey: It's in OpenGL 3.3. ¯\_(ツ)_/¯
21:35jekstrand: Uh... Maybe I'm thinking of a different feature
21:35jekstrand: Oh, I'm thinking of blend_equation_advanced.
21:35bnieuwenhuizen: everything GL_ARB should definitely be desktop GL?
21:35jekstrand: Totally different thing. :-)
21:36bnieuwenhuizen: after too many extended and advanced features one gests confused about the baseline? :P
22:36jekstrand: Ok, I know what's going wrong... sort-of
22:36jekstrand: i'm just very confused as to why this doesn't break in iris
22:37jekstrand: Or literally all other GL drivers
22:37jekstrand: Oh, no, it's busted on iris too. Great!
22:41jekstrand: 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:41jekstrand: tarceri: ^^
22:41jekstrand: tarceri: Looking at generated_tests/spec/arb_gpu_shader_int64/execution/inout/vs-out-fs-in-S1-float-float-float-i64vec3.shader_test
22:42jekstrand: Or someone else who knows about varying packing
22:55Kayden: I would be inclined to align it to the data type size
22:55Kayden: it's probably possible to not align it for a bunch of HW
22:56Kayden: or just pass it as 2x32
22:56Kayden: since it's flat and doesn't need interpolation like a double would
22:58jekstrand: Doubles don't get interpolate
22:58jekstrand: *interpolated either
22:58Kayden: ah, right
22:58jekstrand: 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:59tarceri: 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:00jekstrand:sees the amount of commentary on those issues and walks awa
23:01tarceri: 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:02tarceri: unfortunately I didn't get that far with a nir linker and I'm not sure I will
23:03tarceri: I believe none of the glsl ir fixes proposed so far have fully fixed all issues
23:39imirkin: jekstrand: at the API level, you have to align. you can't have a i64 at a components=3 offset.
23:40imirkin: there are also various rules about what can and can't share slots