00:26airlied: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7357
00:26airlied: reworks your patch a little bit
00:26jenatali: airlied: Awesome :) I'll take a look
00:27airlied: now to make it pass all the tests
00:28jenatali: airlied: There's a difference between how AMD's LLVM approach handled strings vs what I had, where they strcpy the string but I just wrote a pointer
00:28jenatali: Have you looked at strings yet?
00:28airlied: jenatali: nope strings don't pass the test so I expect that explains that :-)
00:29jenatali: That'd explain it :P
00:29airlied: I might have to add another backend options there then
00:29airlied: or key it off the bufer fmt one I have
00:29jenatali: airlied: Considering how unimportant printf is at the end of the day I wouldn't care if it wrote the actual string into the buffer
00:30jenatali: It was just simpler for my purposes to write the pointer, since I could easily retrieve the string from the pointer
00:30airlied: the other difference is the buffer header
00:30airlied: they use 8 bytes, not sure if there's an value
00:30jenatali: Ah right
00:30airlied: any value in what they are doing
00:30airlied: we might find another corner case :-P
00:30jenatali: The CL CTS is pretty lax at validating printf anyway
00:31jenatali: I think their format strings all have a single % value...
00:33airlied: jenatali: is there anythihg that tests it better?
00:34jenatali: My only goal with printf was to pass the CTS :)
00:34airlied: jenatali: well you mentioned those corner cases, did CTS find those?
00:34jenatali: airlied: Nope, karolherbst did :P
00:35airlied: wil have to ask him when he comes back
00:36jenatali: I just mean he pointed them out while looking at the code
00:36jenatali: I don't think he tried running anything
00:39jenatali: airlied: I've heard there's some proprietary tests for the arm printf extension, but I haven't seen any of them
00:39airlied: okay strings fixed, now to figure out the vector crash
00:43airlied: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7357 (since you joined again)
00:54airlied: jenatali: do you align records in the global buffer to 4 bytes bounds?
00:54jenatali: airlied: Yeah, I believe so
00:54jenatali: DXIL has a 4-byte-alignment limitation for writing to SSBOs
00:55jenatali: Anything lower than that ends up with masked atomics
00:55airlied: ah cool
00:55airlied: one test just stores two single-byte chars
01:01karolherbst: oh wow
01:01karolherbst: upgrading to plasma 5.20 makes me think: maybe we still need to maintain Xorg for 10 years...
01:03karolherbst: also how tooltips get misplaced is totally beyond me as well
01:03karolherbst: and that's what I see atm: https://i.imgur.com/JRe2CFy.png
01:03karolherbst: thing is, it's also moving, but I can't even record the screen as... you know
01:04emersion: wayland is the future™
01:04karolherbst: plasma 5.20 is the first release with the screen recording stuff
01:04karolherbst: emersion: well, I blame plasma :p
01:04karolherbst: gnome doesn't have those bugs
01:04karolherbst: and I can't use X on this system anyway
01:04karolherbst: like literally can't as it doesn't have the features I need
01:04airlied: yay test_printf PASSED 57 of 57 tests.
01:04karolherbst: airlied: nice!
01:05airlied: can we have CL 3.0 now :-P
01:05karolherbst: do it :p
03:28soreau: If a shader does fetches on several neighboring fragments of a texture and each invocation of the shader might fetch the same fragments as previous ones, is there some way to avoid the cost of refetching the same coordinates repeatedly in each invocation?
03:29HdkR: texturegather or wave-ops could help
03:34jekstrand: Or you could just hope the GPU has a good cache (it does)
03:35soreau: yea I was thinking maybe this is already taken care of somehow
03:43anholt: soreau: there's a whole bunch of stuff the gpu does to make that work out without you doing anything (texture cache, tiling texture data, and making sure that dispatch of waves is clustered in screen space as a prim gets rasterized are all examples)
03:44jekstrand: The sampler is likely #1 most optimized memory path in the whole GPU and fetching texels near each other is the #1 thing it's optimized to do. :-)
04:07soreau: Ok thanks. I think the wayfire blur plugin could use further optimizing, any suggestions? https://github.com/WayfireWM/wayfire/tree/master/plugins/blur (re the blur shaders are at the top of each method file such as kawase.cpp)
04:08soreau: (though these shaders only account for about half of gpu resources used per radeontop, the rest is blits and final blending shader)
04:17soreau: the other thing I wonder, is if changing the size of a texture with glTexImage2D every frame is expensive
08:10glennk: soreau, considered using a compute shader for the separable filters?
08:14soreau: glennk: no, the only time I tried glsl compute was converting rgb to yuv420 and it was extremely slow compared to the opencl shader to do the same
08:15soreau: so I don't keep it as forefront in my considerations
08:16soreau: glennk: do you think it would have a chance to help? And would it work where only glsl 1.00 is available?
08:17glennk: uh, same hardware running opencl and glsl compute, so if its any performance difference, thats down to api usage or driver implementation
08:20glennk: compute in GL was 4.3 i think
08:20soreau: well whatever I had running for glsl compute, it was dog slow though it worked
08:21soreau: so it left a bad taste in my mouth
08:26glennk: well, main point with the compute shader is it can reuse a bunch of otherwise redundant sampling and computation, and you don't need an intermediate texture
08:26glennk: but there's still room for improvement without going that route
08:27soreau: I see
08:27glennk: what sampling filter is your code using? nearest?
08:28soreau: linear afaik
08:28danvet: mripard, maybe wait for the -rc2 backmerge next week, I need that one too
08:28danvet: before you apply your giantic cocci patch :-)
08:31soreau: glennk: min and mag filter are set to GL_LINEAR
08:34glennk: soreau, a common trick is to approximate the 1d filter kernel using the hardware bilinear sampling, which cuts your number of shader samples in half
08:34soreau: glennk: I think I'm already doing that for gaussian and box
08:34soreau: unless I don't understand what you mean
08:42glennk: i'm not sure i'm reading your box shader correctly, it looks like its setting up the center tap so its half a texel offset, but then the other taps are added by 1.5 and 3.5 texels so they align on texels
08:43glennk: so only the first tap is getting a bilinear weighting
08:43soreau: oh, should it be 1 and 3?
08:49glennk: 2 and 4 i think?
08:50glennk: the offset parameter which i think is some sort of scale factor confuses me :-)
08:51soreau: well position.xy is in the range (-1, +1) and it adds vec2(1.) which makes it in the range (0, 2), then divides by 2. so it's in the range (0, 1) and from there, adds/subs 1.5 and 3.5 offsets
08:57glennk: right, so your first tap ends up being effectively nearest neighbor assuming your input coordinates were screen raster aligned
08:57soreau: glennk: you can just assume offset == 1.0
09:03glennk: anyway, getting back to performance
09:08glennk: i'd move the offsets to a uniform instead of passing as varying
09:10mripard: danvet: what do you need ? The backmerge?
09:57danvet: mripard, yeah I have some patches for -next that need -rc
09:57danvet: but tzimmermann not around
09:57danvet: plus -rc1 is pretty badly broken in our CI
09:58mripard: danvet: ack
09:59pq: vsyrjala, did you write some wayland or weston related bits about HDR many years ago? Remember how I can find those? Just for a historical reason.
10:37pq: I thought Kodi could do HDR display, but now that I look for it, I can't find a mention of it?
10:42emersion: pq: yeah it can, but where are you searching?
10:43emersion: there are a few requirements: it only supports HDR when vaapi is used and the hw can do direct scan-out
10:43pq: I'm searching the kodi wiki, then just google in general which pointed to some kodi forun posts saying "no"
10:44pq: by kodi devs
10:44emersion: i managed to get it work on a GLK
10:44pq: emersion, so, is the HDR output support just an accident of VAAPI->scanout without Kodi actually doing anything?
10:45emersion: no: kodi explicitly sets the various KMS HDR props
10:45emersion: i think it has to do with the depth of the buffer?
10:45emersion: i don't remmeber the details honestly
10:45pq: any link I could use as a reference when claiming "Kodi does HDR sometimes on KMS"?
10:47emersion: pq: i guess this is about the best you're going to get: https://github.com/xbmc/xbmc/pull/16103
11:54stuom1: I'm trying to make a DRM driver for a mipi panel, and struggling to translate the init sequence from the datasheet to my code. The init sequence has the commands, and packet header, packet data, and packet footer (checksum). If I use function like mipi_dsi_dcs_write_buffer, do I need to take care of the headers and checksums too, or are they
11:54stuom1: handled automagically somewhere else?
12:55vsyrjala: pq: https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html
12:55vsyrjala: the branches should still be there
12:59pq: no wonder I didn't find, I don't have a copy of that email in my archives, thanks!
13:23zmike: ajax: I saw your blog post about xserver yesterday; brought back a lot of nostalgia from when I was first getting into linux and open source
13:23zmike: then I saw social media comments about it and remembered this is 2020, not 2000
13:24pq: time sure flies
13:24zmike: really dose
13:24zmike: especially this year
13:29ajax: this year's been a hell of a decade
13:29zmike: has it really been that short?
13:31danvet: mripard, we might need some irc discussion for your fifos ...
13:51mripard: danvet: yeah, probably :)
13:51mripard: danvet: so it's a global state because while we have N pixelvalves / CRTC
13:51mripard: there's a single HVS for the whole system
13:52mripard: so we need to take into account the state of all the CRTCs in the system when a new one is enabled
13:53danvet: mripard, so the pixelvalve <-> crtc, is taht some N <-> M dynamic thing?
13:53mripard: yeah, there's 1 HVS with N FIFOs, connected to M CRTCs
13:53danvet: i.e. in a perfectly ideal driver that supports every use-case and every transition as best as possible
13:53mripard: with N < M
13:53danvet: would you need to dynamically need to reassign them around ?
13:54danvet: oh N < M
13:54danvet: so you can't even light up all the CRTC?
13:54danvet: at the same time I mean
13:54mripard: I don't think we do no, they are pretty much equivalent in terms of capabilities
13:55danvet: no as in, you can't light them all up at the same time
13:55mripard: but it's not necessarily a big deal, the rpi4 doesn't have enough output to realistically enable all the CRTCs in the SoC either
13:55danvet: or no, as in danvet still confused?
13:55mripard: no we can't light them all up at the same time
13:55danvet: why not just make a fixed assignment at boot-up and done?
13:56mripard: because we don't know the ones that are actually going to be used during the life of the system
13:57mripard: it has 2 HDMI outputs, a writeback engine, a DSI and DPI outputs
13:57mripard: and 3 FIFOs
13:57mripard: so while I wouldn't expect all of them to be enabled at once
13:57mripard: it doesn't seem really far fetched to have at least some variations depending on the use case
13:58igorkovalenko: hello, I get glxgears crash with LIBGL_ALWAYS_SOFTWARE=true on mesa-20.2.1 and seems like the same crash with mesa-20.0.8 - is this a known issue?
13:58karolherbst: igorkovalenko: it shouldn't crash and I would be surprised if that's a common issue
13:58karolherbst: do you have some logs or backtrace or something?
13:59mripard: (and they dont' completely have the same capabilities, there's a few constraints on some FIFOs)
14:00igorkovalenko: I did a few checkouts and builds locally, 20.2.1 and 20.0.8 do crash, but mesa-18.3.6 works
14:00igorkovalenko: backtrace 1sec
14:03igorkovalenko: (export LIBGL_ALWAYS_SOFTWARE=true; gdb /usr/bin/glxgears) https://pastebin.com/6dFKCCuR
14:04igorkovalenko: akin to https://gitlab.freedesktop.org/mesa/mesa/-/issues/3613 but cannot confirm if exactly the same
14:06igorkovalenko: hmm looks like the same issue
14:32ajax: grumble. i can get zink on nvidia but i can't get core contexts out of it, wtf
14:32zmike: I'm not sure it's ever been tried on nvidia before?
14:33ajax: it took some coercion, yeah
14:50jekstrand: Ugh... I've got 97 patches on my RT tree just to handle building BVH kernels. :-/
14:50jekstrand: Need some serious pruning there. :)
14:51daniels: ajax: *blink*
14:55jenatali: jekstrand: How much of that is stuff that accrues to CL (like generic pointers) vs being Vk-specific?
14:56jekstrand: jenatali: Quite a bit of it probably
14:56jenatali: jekstrand: Cool, I look forward to reviewing :)
14:58jekstrand: jenatali: Also, 97 is the branch in a very messy state. Likely it'll be compacted again before stuff lands. :-)
14:58jenatali: Heh, fair enough
15:00danvet: mripard, sry was distracted with mtg
15:00danvet: yeah so dynamic assignment makes sense
15:00danvet: and I think you need that last_user drm_crtc_commit * pointer for transitions
15:01mripard: no worries :)
15:03mripard: to prevent from the issue you mentionned in your mail with two subsequent non-blocking commits?
15:06mripard: (I can't find a last_user pointer in drm_crtc_commit?, or any last_user pointer under DRM)
15:19igorkovalenko: my crash backtrace really looks like issue #3613 and I bisected it back to MR !2303 which is "llvmpipe: switch to NIR by default"
15:19danvet: mripard, yup, for the case of two nonblocking commits
15:19danvet: for that case the drm_modeset_lock won't sync anything
15:20igorkovalenko: as I'm not a reporter of #3613 should I just add a comment there suggesting reporter to test with mesa-19.3.5 which also works for me?
15:22danvet: mripard, I'm typing up a sketch for pastebin
15:23danvet: mripard, https://paste.debian.net/1169094/
15:23danvet: instead of your bitmask
15:23danvet: and maybe make in_use a drm_crtc * pointer
15:24danvet: so you can check for consistency easier
15:24FLHerne: igorkovalenko: It might be important which version of LLVM you have
15:25FLHerne: There'd probably be more complaints if llvmpipe crashed for everyone with something that trivial
15:25igorkovalenko: FLHerne: started with llvm 11 (current)
15:25danvet: oh and drm_crtc_commit is a bit renamed, it's really a fairly generic end-of-hw-commit tracker
15:25igorkovalenko: older versions did not build with that, so bisected with 10.0.1
15:26FLHerne: Can't reproduce with 20.2.1 and llvm 10.0.1
15:26FLHerne: My gears spin happily :-)
15:26igorkovalenko: I'm sure noone is using swrast until pressed ) I'm running with LIBGL_ALWAYS_SOFTWARE=true for specific reason to reproduce firefox rendering issue
15:26danvet: I think we could rename it to drm_atomic_hw_commit
15:27danvet: and make the ->crtc pointer optional
15:27danvet: so that you could use this to track commiting of pretty much anything
15:27danvet: but it's slightly more convenient for the code to attach it to a crtc
15:30FLHerne: I guess airlied is the one to ask about llvmpipe things
15:30igorkovalenko: I left comment in #3613 anyway
15:30MrCooper: igorkovalenko: the Mesa CI pipeline runs thousands of tests with llvmpipe
15:30FLHerne: There are definitely a number of users, there's no way it breaks for many people for a year without complaints
15:31MrCooper: there must be some system specific factor to this issue
15:31igorkovalenko: I would not exclude some exotic thing here, right
15:31FLHerne: i.e. there's something different about your system, but what? :p
15:31MrCooper: / build configuration
15:31FLHerne: igorkovalenko: What distro, platform is it?
15:32mripard: danvet: I'll look into that then, thanks :)
15:35igorkovalenko: FLHerne: its gentoo here, linux-5.9.1 glibc-2.32 GCC 9.3.0 and I reproduce with mesa built from source, configured like this: PATH=/usr/lib/llvm/10/bin:$PATH CPPFLAGS="-O2 -W -Wall" meson build -Dgallium-drivers=swrast -Ddri-drivers= -Dvulkan-drivers=
15:36igorkovalenko: running on kde plasma + wayland via LIBGL_ALWAYS_SOFTWARE=true glxgears
15:37igorkovalenko: unsetting WAYLAND_DISPLAY does no change
15:39igorkovalenko: hope it is not my old cpu AMD Phenom(tm) II X6 1055T Processor, as I'm scared to remember last time I was chatting to you nice people on #xorg-devel many years back, my name was garrison and my issue was 64bit ddx layout incompatibility or something :)
15:45igorkovalenko: but I'm prepared to find out what is the exotic root cause this time
15:50FLHerne: That sounds old and uncommon enough that it might break some assumption about processor features
15:50FLHerne: There was a patch for something vaguely related in the last month or so, but I can't find it
15:51igorkovalenko: was the patch on gitlab or somewhere else?
15:53FLHerne: Hrm, I think I was misremembering some discussion of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/518 , which isn't really relevant at all :-(
15:54igorkovalenko: unfortunately it is not a SIGILL here
15:57ajax: daniels: most of the coercion is the same as making llvmpipe work on nvidia, in the sense of making the drisw binding work.
15:58ajax: which... i still need to sort out properly, i guess
15:58ajax: and then making that deign to load zink requires more environment variables than you'd like
15:59ajax: and that gets you as far as glxinfo but glxgears throws an assertion
15:59jekstrand: airlied: From phoronix:
15:59jekstrand: Is there anything like softpipe or llvmpipe for Vulkan Raytracing?
15:59jekstrand: airlied: You going to get working on that now? :-P
16:00daniels: Phoronix-Driven Development
16:00jekstrand: daniels: That's what our managers think we do. :P
16:00FLHerne: One frame per day?
16:00jenatali: You'd beat us to it, we still haven't gotten around to implementing raytracing in WARP
16:12jekstrand: jenatali: RE: "real" generic vs. if-ladders
16:12jekstrand: jenatali: Right now, the way I have it working is that if addr_mode_is_global returns true, it assumes you have "real" generic and doesn't do any of the lowering.
16:13jenatali: jekstrand: Yeah, I'm realizing that now, and that makes sense to me
16:13jekstrand: So for karolherbst's case, he can use 64bit_global and should get global access for everything.
16:14jekstrand: The sticky bit, of course, is that 64bit_global always does 64-bit even for shared and scratch
16:14karolherbst: jekstrand: are conversions inserted already?
16:14jekstrand: But we could add a new one to have the right semantics
16:14jekstrand: karolherbst: What do you mean?
16:14karolherbst: shared -> global conversion intrinsics
16:15jekstrand: karolherbst: The way it works right now is that shared would shared_base_ptr + offset
16:16jekstrand: So you would just lower shared_base_ptr to be the base address of your shared memory mapped region
16:16jekstrand: Same for scratch only scratch_base_ptr
16:17jekstrand: So if the NV thing really is just mapping scratch and shared memory to your VA space at fixed offsets, it should be exactly what you want.
16:34jenatali: jekstrand: Any reason !6332 is still marked WIP?
16:34jekstrand: cmarcelo: Could you please look at the "Make nir_deref_instr::mode a bitfield" patch in my generic pointers MR? You're the closest person to actually being able to review it AFAIK.
16:35jekstrand: jenatali: What WIP? :-P
16:36karolherbst: jekstrand: yeah, sounds good
16:44jekstrand: The deref mode specialization pass seems super-effective, BTW. In my giant pile of kernels with generic everywhere, I've only seen a couple of if-ladders.
16:46jekstrand: And I know how to get rid of those. :-)
16:46jekstrand: I just have to write the code
16:49jenatali: I'm curious, what's your plan?
16:50jekstrand: The cases that I'm seeing are where someone has a loop and does `ptr += N` at the end of it.
16:50jekstrand: So the current thing can't propagate because it goes to look at the parent and the parent is a phi not a deref.
16:50jekstrand: So we need a bit of code to look through phis
16:50jenatali: Ahh, makes sense
16:50jekstrand: We probably also want to handle bcsel of deref
17:15drv04: Hello. I made a Coccinelle change to drivers/gpu/drm/msm/adreno/a5xx_debugfs.c and would like to build the associated driver(s)
17:15drv04: However, looks like my config needs tweaking
17:15drv04: Can someone help with the steps in order to build the change I made to the file?
17:15drv04: I am runnign a x86
17:42drv04: Yaay...I think I got it!
17:53anholt: starting to test it in CI now, but my new deqp runner is published https://crates.io/crates/deqp-runner
17:57anholt: Compared to the one we've been using, it can handle known flakes, doesn't reshuffle on skiplist changes, logs better, extracts QPAs for you, saves failed caselists for you, produces a nice file for use as the baseline of your next run (aka the thing we check in to git in mesa ci) and is chock full of unit tests so I have a harder time breaking it than the old one.
17:58pepp: anholt: nice!
17:58anholt: looks like the code is 1/3 unit tests.
18:10ajax: i wonder, for GLXSetClientInfo, whether the list of gl versions is meant to reflect direct or indirect support
18:12ajax: could only possibly matter for indirect i suppose
18:15ajax: except llvmpipe vs nvglx is only giving me 3.1 compat and not 4.5 core
18:15ajax: which seems a lot like its taking the SetClientInfo version list quite seriously
18:23ajax: we don't do ARB_compatibility past 3.1, right?
18:23jekstrand: Yes, we do
18:23jekstrand: On most drivers anyway
18:23danvet: yeah I thought mareko was spending years enabling this
18:23danvet: and most drivers followed
18:23jekstrand: That changed a year or two ago
18:24ajax: whoa. yeah iris seems to have it under 4.6. wild stuff.
18:25ajax: per driver then? MESA_query_renderer says max of 3.1 for llvmpipe compat
18:25airlied: igorkovalenko: do you have DRAW_LLVM=0 set somewhree?
18:29daniels: anholt: \o/
18:30jenatali: ajax: Yeah, it's pipe caps that control it
18:32anholt: oh, I didn't plan how the new runner was going to do this for you:
18:32anholt: dEQP error: deqp-gles31: ../src/gallium/auxiliary/tgsi/tgsi_exec.c:1483: fetch_src_file_channel: Assertion `mach->Consts[index2D->i[i]]' failed.
18:32anholt: ERROR - Test dEQP-GLES31.functional.shaders.opaque_type_indexing.ubo.dynamically_uniform_geometry: Crash: See "//results/c5.r0.qpa"
18:32igorkovalenko: airlied: not yet, but DRAW_USE_LLVM=no
18:33igorkovalenko: let me see where it comes from
18:33airlied: yeah don't be setting random vars
18:37igorkovalenko: not easily found, let me grep / :)
18:37anholt:really needs a driver knob for "make some tests flaky"
18:37cmarcelo: jekstrand: will look
18:38igorkovalenko: i confirm it works like this: LIBGL_ALWAYS_SOFTWARE=true DRAW_USE_LLVM=yes glxgears
18:38robclark: anholt: something that randomly no-op'd draws in core glDraw path, perhaps?
18:39jekstrand: cmarcelo: I also just updated the SPV_KHR_ray_tracing branch with the latest from the internal branch. I think I had some fixes in there but I don't remember what they are anymore. :-/
18:39igorkovalenko: guess verbose error can be made in place of crash #3613 as an enhancement
18:39airlied: igorkovalenko: I should probably just ignore DRAW_USE_LLVM
18:40airlied: not sure why people have it set in their environment
18:40igorkovalenko: as it appears to be the root cause of my crash I'll root cause where it comes from
18:42igorkovalenko: airlied: I see that r600_pipe_common.c does this setenv("DRAW_USE_LLVM", "no", 0);
18:43igorkovalenko: can it be that my plasmashell or console got through that initialization and env variable just sticked there
18:45airlied: igorkovalenko: very unlikely, do you have a radeon gpu though?
18:45airlied: I don't see that setting in master
18:46cmarcelo: jekstrand: but fixes for the generic pointer MR? or just the other branches?
18:46igorkovalenko: no but I have r600
18:46jekstrand: cmarcelo: The fixes were for SPIR-V parsing of SPV_KHR_ray_tracing
18:47igorkovalenko: airlied: well my r600 is Radeon HD 4290
18:47igorkovalenko: in 20.2 it is here src/gallium/drivers/r600/r600_pipe_common.c: setenv("DRAW_USE_LLVM", "no", 0);
18:47cmarcelo: jekstrand: ok.
18:48karolherbst: igorkovalenko: probably a distribution patch or something?
18:49karolherbst: ohh no, in 20.2 that indeed existed there
18:50airlied: igorkovalenko: that might be it indeed
18:51airlied: what a singularly bad idea in an unreviewded patch
18:51karolherbst: airlied: well, the original patch is also from 2019
18:51karolherbst: and not reviewed
18:51jekstrand: :-/ rather
18:52karolherbst: I don't bother to comment that anymore
18:52karolherbst: seems pointless to bring it up every time I see it
18:52karolherbst: don't care about driver patches though
18:52karolherbst: they can be unreviewed for all I care
18:53karolherbst: although I think the patches were reviewed, but the tags not added to git
18:54karolherbst: *sigh*.. anyway
18:54karolherbst:goes back to investigate broken bgr565 on s390x
18:59ajax: zmike: ping if you're around for a zink question'
19:03ajax: specifically why allocating a renderbuffer would fail in get_memory_type_index
19:05igorkovalenko: let me triple-check reverting that patch cures the env here
19:06igorkovalenko: is there another release expected from 20.2? if so, can I somehow request backporting that 85f39cab8bda7cd03445193de4c80649791ba569 to 20.2?
19:08airlied: igorkovalenko: there is another release expected alright, I'll hook gerrdie into the issue
19:08airlied: karolherbst, jenatali: https://paste.centos.org/view/raw/3f7aa0ac bit of work for llvmpipe CL 3.0 :-P
19:09airlied: (also was images turned off)
19:09karolherbst: yeah.. non uniform work groups :/
19:09igorkovalenko: thanks, I'll be right back after reboot, my grep did found DRAW_USE_LLVM nowhere but mesa binaries so I'm testing the change
19:10jenatali: karolherbst: Non-uniform work groups are optional
19:21airlied: pq, vsyrjala : do we have any sort of state of HDR knowledge? like what is done/works/etc
19:24igorkovalenko: airlied: I confirm backing out that change from 20.2.1 fixes the crash (and no more DRAW_USE_LLVM=no in environment)
19:26airlied: igorkovalenko: excellent, thanks, and sorry for shooting ourselves in the foot here
19:31igorkovalenko: commented on the item now, waiting for 20.2.2 :)
19:32igorkovalenko: went unwinding the stack back to firefox rendering issue
19:34igorkovalenko: yay see firefo WebRender with llvmpipe on fixed mesa-20.2 at last :)
19:34igorkovalenko: * firefox that is
20:04zmike: ajax: yeah, I'm back now
20:05zmike: ajax: you mean hitting that unreachable()? I haven't seen that before
20:08zmike: I'm not afraid to admit that code predates my involvement and thus I haven't spent much time there
20:08zmike: airlied might have some ideas
20:08ajax: is there a reason that's not written as if (blah & (1 << i)) ?
20:08airlied: reachable unreachables are the best type
20:09Sachiel: they enable some interesting speed run tactics
20:11airlied: ajax: not 100% sure or awake, but it might involve dedicated allocations
20:11airlied: would need to set the memory types from the vulkan impl
20:11airlied: vulkaninfo might show them
20:11ajax: ngh why did i not build with -O0 like a sane person
20:13ajax: airlied: https://paste.centos.org/view/a7586a9f
20:14ajax: this is on a gtx1650, i am aware i'm doing something extremely off-label
20:14zmike: so what's the unsupported type?
20:15igorkovalenko: hello hello please help, maybe anyone seen similar issue https://bugzilla.mozilla.org/show_bug.cgi?id=1673939 which I cannot reproduce with llvmpipe but it is seen with r600
20:15airlied: I assume you are asking for host visible on something that isn't
20:17airlied: nvidia don't adverise host visible vram at all
20:17airlied: from what I can read
20:18airlied: and I assume for the sw winsys path we needs that
20:20ajax: i mean, if that's the architectural issue i'll just shift gears back to making drivk be a thing instead of trying to coax drisw into working for this
20:21ajax: but yeah, it wants HOST_VISIBLE and doesn't think it's finding it
20:22ajax: memoryTypes in the paste linked above has that though
20:22ajax: and .
20:23airlied: ajax: not for the image type
20:23airlied: you create and image, ask the driver what memroy types it works for
20:23airlied: and they don't intersect
20:24ajax: mmm, reqs.memoryTypeBits ends up as HOST_VISIBLE | DEVICE_UNCACHED
20:26airlied: for nvidia drisw we'd likely want to do image->image copy from a tiled to linear cpu image we can map
20:28airlied: (acutally for any drisw path we'd like that for speedups)
20:28airlied: but I think drivk would be better worht the effort
20:28ajax: drisw for things not actually drawn with the cpu does seem like a losing plan
20:29airlied: yeah it's definitely not winning
20:29airlied: it was just a nice bringup feature
21:46daniels: austriancoder: btw, we've got imx6q-sabrelite in LAVA if that helps bring up etnaviv at all?
21:47austriancoder: daniels: good to know - thanks
22:00daniels: austriancoder: are you still looking at an etnaviv baremetal lab?
22:02austriancoder: daniels: for me a bare-metal lab is much easier to maintain then a LAVA one (also I don't want to do any kernelci stuff)
22:02daniels: sorry, I didn't mean that to come across the wrong way - I'm not asking you to justify baremetal vs. LAVA!
22:02daniels: I was asking about etnaviv generally and how we can enable that, not 'please don't do baremetal' :)
22:07daniels: austriancoder: also, tbh I'm slightly confused about running on GBM vs. requiring GLX+GL - I think it would probably make sense to either run piglit on surfaceless, or a sort of hybrid platform where it uses GBM surfaces but then immediately releases the results
22:07daniels: with the current situation, I'm not sure how xvfb+glx is related to gbm?
22:25austriancoder: daniels: the end goal is to run piglit against desktop gl - that's why I enabled glx in Mesa. regarding piglit I need to recheck/retry the surfaceless
22:32sravn: narmstrong: I hope you will find time to take a look at the keembay bindings. They are now split in what I think is the right way
22:33narmstrong: sravn: sure, I’ll have a look
22:35sravn: narmstrong: thanks. Late here so if you jumped at it my replies will wait a bit
22:36narmstrong: sravn: I won’t have a look before tomorrow morning French time
22:45austriancoder: daniels: gbm for piglit looks fine for bare-metal and xvfb is not used in my piglit-runner. But the big pain point could the current piglit usage in the CI
22:46HdkR: austriancoder: EGL + GL isn't viable? :)
22:47karolherbst: yeah, just eliminat the need of a windowing system :p
22:47karolherbst: although how does headless gbm work? But I suspect it just works
22:51austriancoder:is confused but some sleep will help
22:52daniels: austriancoder: oh sorry, I was looking at the wrong tree, so I didn't see your piglit-runner was actually GBM and not Xvfb :(
22:53daniels: but they're orthogonal, right? if you need GLX and the X11 runtime libs, you're running against an X server; if you're running Piglit on GBM, you're not running against an X server ...
22:54daniels: HdkR: indeed it is
22:55daniels: karolherbst: easy - GBM only does allocation, not presentation. eglSwapBuffers() just moves your backbuffer to the slot which the client can pick up with gbm_surface_lock_front_buffer() and then post to GBM itself
22:55daniels: karolherbst: so you just swap -> lock_front_buffer -> release_buffer, without ever posting to KMS
22:58karolherbst: ahh, cool
23:02airlied: jenatali: assume I've only had a small amount of sleep and no caffiene, and tell me why the ptr is wrong for gpu again :)
23:03airlied: my impressiong was you were putting the CPU 64-bit ptr to string into the shader, and it was emitting it into the ssbo
23:03jenatali: airlied: The pointer is just going to be whatever value was in the kernel for the __constant char*
23:04austriancoder: daniels: correct - I am looking into reusing piglit/run.sh for my work and that might change some bits.
23:05jenatali: airlied: So for a system with SVM, yeah it'll be a pointer to the string, but if your GPU addresses are different from CPU addresses, it'll be a GPU address stored into the SSBO
23:08jenatali: airlied: For CLOn12, that pointer ends up being a (buffer ID, offset) pair, and the runtime uses that to find the string data in the buffers that it uploaded to the GPU in the first place
23:08jenatali: I didn't really try to generalize it further than that...
23:11daniels: austriancoder: yeah sorry, I'd opened tig in one tab, and opened vim on the runner script in another tab which was still looking at the upstream tree :\
23:11daniels: austriancoder: so that makes sense, but I'm still not sure how you combine GBM + no X server + GLX/x11proto-dri3 :P
23:13jenatali: airlied: The easiest way to generalize it is probably to put the actual string contents in the buffer, like AMD's LLVM path, though that significantly complicates the code the GPU has to execute
23:17airlied: jenatali: just a memcpy? :-P
23:18airlied: jenatali: when we are lowering things don't we have a cpu side pointer, could we just not use that as a handle
23:18airlied: or we could treat real strings like fmt strings and have an indexed lookup table
23:20jenatali: airlied: Depends if constant kernel args can be used as input to %s format strings... I don't remember where we landed on that
23:20jenatali: jekstrand, karolherbst: Do either of you remember? ^^
23:20karolherbst: I think we came to the conclusion it has to be a literal literal
23:20jenatali: That's what I thought I remembered too
23:20karolherbst: but mhh
23:21karolherbst: oh well. I'd implement it so the CTS is happy
23:21karolherbst: and fix it once people complain :p
23:21jenatali: The CTS only uses literals I believe
23:22jekstrand: I'm happy with only literals
23:23airlied: yeah the spec says global char *s is illegal
23:23airlied: and constant char *p
23:24airlied: In OpenCL C, the conversion specifier s can only be used for arguments that are literal strings.
23:24airlied: so I think we are good with just having a lookup table
23:30airlied: so maybe I'll just adjust the lowering to also reutrn a bunch of strings
23:34airlied: oh maybe that isn't trivial, will have to think about :-P