00:04mareko: x86_build container test is broken: https://gitlab.freedesktop.org/mareko/mesa/-/jobs/2911307
00:05airlied: yeah see above, MrCooper will fix it tomorrow is the current plan of action
02:18airlied: https://people.freedesktop.org/~airlied/scratch/twotris.png shows two tris, one rendered by llvmpipe and one by the CTS reference renderer
02:18airlied: left is llvmpipe, right is reference, there is one pixel different
02:19airlied: my vulkan rast fails some tests due to this
02:19airlied: anyone care to speculate on whether it's my fault or test is ott
02:19airlied: jekstrand, bnieuwenhuizen ^ ?
02:20mattst88: oh damn, bottom left
02:21airlied: it's also wierd that this renderpass depth test is one of the only things that trips up here
02:23HdkR: https://docs.microsoft.com/en-us/windows/win32/direct3d11/images/d3d10-rasterrulestriangle.png Going to be one of those fun problems right? :D
02:23airlied: HdkR: yeah I think it is, I suppose I should get out my drawing papre :-P
02:29airlied: hmm gallium hasa bottom_Edge_rule bit and all the hw drivers ignore it
03:13airlied: robclark: msm-next is broken on arm32
03:13airlied: I'm not sure I want to pull it this week or wait
03:13airlied: robclark: please see sfr's emails
03:14robclark: airlied: there is one more commit on top of label from pull req which fixes that.. but wasn't sure I should send fixes pull before you even pulled the thing it was on top of
03:15robclark: so linux-next should be happy, afaik
03:16robclark: the commit you should want to get the fix for that is 721a35ad71d969e448472972605bf443d3181320
03:16airlied: robclark: nope it's still not entirely happy according to sfr
03:17airlied: the mult_frac stuff
03:18robclark: hmm, ok, hadn't seen that yet..
03:20robclark: ok, I'll try to fix that up tomorrow.. maybe I still have armv7 compilers installed..
04:01robclark: airlied: I pushed a revert, and also sent same patch to dri-devel
04:02robclark: don't have time now to setup armv7 build env, but commit should be safe to drop and try again next time
04:04airlied: robclark: not sure what OS you are building on, but fedora does have an arm7 cross compiler
04:04airlied: might be worth having a build with it before sending next out
04:05airlied: or https://mirrors.edge.kernel.org/pub/tools/crosstool/
04:05robclark: yeah, still fedora.. just haven't got around to setting up armv7 build after a couple re-installs with hw swaps..
04:06airlied: like it's not like you need to build userspace
04:06airlied: kernel cross compiles are fairly self contained
04:11jekstrand: airlied: Are you advertising the right number of sub-pixel bits?
04:11jekstrand: airlied: Is llvmpipe using fixed-point rasterization like a sane rasterier?
04:15jekstrand: It's also possible there's some weird rounding issue when converting to fixed-point for rasterization
04:16airlied: jekstrand: yeah it's fixed point, and I should have enough sub-pixel bits not that I think that test cares
04:16airlied:is going to trace the reference rasterizer if I cna
04:16jekstrand: airlied: It's not about whether or not you have enough. You need to have 4 or 8 and you need to advertise the correct number.
04:17jekstrand: Otherwise, some CTS tests will fail due to weird corner cases where clamping to the wrong number of bits causes one pixel to be lit or unlit wrong.
04:17jekstrand: There are some tests which are very touchy
04:18jekstrand: If I advertise 4 on Intel and configure the hardware to 8, it will not pass the CTS.
04:18airlied: okay I'm advertising 4, but I think I have 8
04:18airlied: I'll give that a shot
04:19jekstrand: Also, I'm pretty sure (I tried to imply this above) that the CTS only supports values of 4 and 8.
04:20jekstrand: If you have 16 for some reason, that may be a problem
04:22airlied: jekstrand: nice one
04:22airlied: nope only have 8
04:22airlied: jekstrand: you win! thanks I'd have lost 2 days bashing my head on that
04:23jekstrand: airlied: :D If covid wraps up and we ever get around to meeting in person, add it to my beer tally. :-D
04:24airlied: jekstrand: that tally is probably a large semi trailer by now :-P
04:29jekstrand: airlied: Looks like I need to plan an at least month-long vacation. I don't drink much in a single evening.
04:35airlied: hehe, my consumption has degraded horribly, it can be weeks between beers now!
04:35imirkin: but one beer = one semi, so ...
06:09airlied:launches 5.8-rc1 pull request
06:44MrCooper: dcbaker[m]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4740 should be reverted for now
07:43hakzsam: jsut reporting it herre
07:43hakzsam: *just reporting it here
08:24MrCooper: hakzsam: see scrollback
08:25hakzsam: MrCooper: meson 0.52 fault?
08:26MrCooper: not really, merging that MR just exposed an existing problem with current Debian testing
09:16MrCooper: kusma: no Mesa MR can be merged until the issue discussed above is fixed
09:17kusma: MrCooper: Yeah, I was just reading scrollback. Thanks for pointing it out!
09:20hakzsam: revert it now?
09:31danvet: tzimmermann, mripard, mlankhorst_ ok if I fast-forward drm-misc-next-fixes?
09:31danvet: I have a bugfix to push there
09:31danvet: *fast-forward to drm-next main -rc1 pull request
09:31danvet: tzimmermann, or you can do it
09:32danvet: tzimmermann, generally good practice to roll -fixes branches forward as soon as your last pull request landed
09:32danvet: to avoid them being stuck on some really old baseline, which might be rather broken
09:35mlankhorst_: danvet: go for it
09:52danvet: pinchartl, I just respun the drm_crtc_vblank_reset patch, pls double check I've updated it correctly
09:55siro__: Hi, I've got an issue with ASPM enabled in the firmware causing the Windows Nvidia driver to BSOD. Is there a Nvidia engineer here who can give some inside why this is the case or point me to the right documention?
10:01emersion: siro__: this is a Linux channel
10:03siro__: maybe a linux engineer is familar with ASPM issues on those cards ;-)
10:08tzimmermann: danvet, please do
10:44MrCooper: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5296
10:53ccr: this is local linux channel for local linux people. we'll have no trouble here.
11:36danvet: tzimmermann, done
11:36tzimmermann: danvet, thanks
11:36danvet: tzimmermann, also realized that I need to respin the patch for the review from pinchartl
11:36danvet: so that isn't pushed yet
12:26CrazyByDefault: guys, is this the right place to ask for some troubleshooting help in regards to getting Xserver to run after a DRM/Mesa build?
12:32CrazyByDefault: i'll go ahead and dump our issue here, with hope that someone can help
12:32CrazyByDefault: we're still attempting to get mesa working on GCP with 18.04/10.04
12:32CrazyByDefault: on 16.04 our setup works, and we get an Xserver running with mesa, but on 18/20 it fails with the same build for DRM/Mesa
12:32CrazyByDefault: Xserver logs - https://pastebin.com/nseZcF71
12:32CrazyByDefault: working on 16.04 - https://pastebin.com/gtEdgLh4
12:32CrazyByDefault: this is what we're using to build DRM as well as Mesa on both the systems - https://pastebin.com/LMsP5cdk
12:32CrazyByDefault: Does anyone know what broke between 16.04 and more recent versions?
12:46pq: CrazyByDefault, I see "(EE) open /dev/dri/card0: No such file or directory" - is that expected?
12:47pq: if not, your problem is in the kernel side
12:47pq: then again I don't know what GCN is.
12:47pq: err, GCP
12:48CrazyByDefault: yes, that is expected. occurs in both the log files, but 16.04 manages to start the xserver with a different framebuffer looks like
12:48CrazyByDefault: GCP = google cloud platform
12:49CrazyByDefault: i suspected the issue might be kernel side. It seems to want to accept a 32bit config in the 20.04 logs, but the adapter has 24bit depth I guess, and hence it fails. I've tried setting bpp/Depth for fb through CLI and Xconf as well, but to no avail
12:50pq: aha, then I've would not have expected Xorg to work at all, but pick something like Xvfb instead.
12:51MrCooper: the working log file shows the Xorg fbdev driver being used
12:51bnieuwenhuizen: is this a GPU instance?
12:51CrazyByDefault: pq But they have a virtual display adapter for use cases such as this, and it generally grants much better perf than xvfb.
12:52CrazyByDefault: no, this is a CPU-only instance. We're trying to get it to work with Mesa, not proprietary Nvidia drivers (we tried that and it was a whole another rabbit-hole lol)
12:52pq: just shows how much I know about GCP :-)
12:53pq: wait, performance? with fbdev??
12:53MrCooper: CrazyByDefault: newer Xorg no longer supports 24bpp internally; it's supposed to still work with ShadowFB, but maybe the fbdev driver is missing something for that
12:54CrazyByDefault: pq hmm.. is fbdev supposed to be bad? we have an instance on production running this with pretty good OpenGL perf, lemme check if the config there is somehow different..
12:55pq: fbdev is supposed to offer no hw accel at all AFAIK, it's literally the "I don't have a GPU" thing, and should put you into software GL
12:56pq: CrazyByDefault, maybe check whether your performance difference is actually due to different Mesa software GL renderers rather than Xorg/fbdev vs. Xvfb?
12:58CrazyByDefault: wait how's Vesa figure into all this? It's a different driver right?
12:59pq: you mean Xorg's vesa driver?
12:59pq: it's a userspace mode setting driver for literally VGA hardware
13:00imirkin: well, for VESA bios services
13:02pq: Xorg fbdev driver OTOH uses a kernel driver through the fbdev UAPI, /dev/fb0 etc.
13:04CrazyByDefault: our production sever shows that it's using Vesa, not fbdev. The only difference btw the newer 16.04 and 20.04 servers (for which I've shared logs) and our prod server is that the DRM build changed from make -> meson. is it possible any flag changes there is causing fbdev to be picked up instead?
13:05CrazyByDefault: And like MrCooper said, I guess 24b support has been dropped, but the display adapter we get don't support 32bit, hence the crash on 20.04 I think
13:06CrazyByDefault: If Vesa does userspace modesetting, can't that set the video bpp to be accurate?
13:07CrazyByDefault: pq GCP's display adapter is a VGA adapter lol, guess vesa could be used to modeset the bpp accurately?
13:22pq: CrazyByDefault, I'm struggling to imagine how any of that could make a difference in GL performance :-D
13:23pq: no idea about vesa either
13:24pq: CrazyByDefault, btw. if by "DRM" you refer to libdrm, then it's almost insignificant. libdrm does not do much. All the interesting stuff is in kernel DRM and Mesa.
13:26pq: I suppose indirect vs. direct rendering GLX would make a difference, but I'm not sure how that related to the xserver flavour or Xorg drivers.
13:34danvet: nashpa, so for the 2 drm_crtc_vblank_off fixes in unbind code I think testing would be actually useful ...
13:34danvet: or you're ok if this blows up since komeda is the current thing now?
13:46shadeslayer: anholt_: daniels: what would be the equivalent of src/gallium/drivers/iris/iris_resource.c for i965?
13:46danvet: j4ni, my htmldocs build is full of "duplicate label" warning
13:46danvet: you know what's going on?
13:46danvet: is this new?
14:13j4ni: yes and yes
14:18j4ni: danvet: see 4658b0eb9430 ("docs: conf.py: avoid thousands of duplicate label warning on Sphinx") and a05b28991721 ("drm/i915: fix Sphinx build duplicate label warning"), and their Fixes: tag
14:22danvet: j4ni, ok, I guess I'll ignore this all for now
14:22danvet: and hope that mauro/corbet fix up the fallout
14:28shadeslayer: Hm, is there a document that details the architecture for older DRI drivers like i965? I'm only familiar with Gallium based drivers
14:35nashpa: danvet: I'll do the testing as well. Komeda is unlikely to be meaningfull for a year or so, malidp actually has deployments on silicon
16:44nashpa: danvet: for both malidp and hdlcd you can add the tested-by tag from me
16:46danvet: nashpa, thx very much
16:47danvet: nashpa, first patch needs to go into drm-misc-next-fixes
16:47danvet: where should I push the other 2?
16:47danvet: not really a bugfix, just cleanup, so imo drm-misc-next should be fine
16:47danvet: but can also push to drm-misc-next-fixes if you think it's better to keep them all together
16:48nashpa: drm-misc-next is fine with me
16:48danvet: ok, will push them tomorrow
17:03MrCooper: anholt_: thanks for reviewing https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5296 ! I gotta go for dinner, feel free to merge it
17:04anholt_: will do
17:05anholt_: (being able to adjust other people's branches is nice. Wish we could do so by git push origin HEAD:merge-requests/nnnn though)
17:05anholt_: seriously, thanks for sorting this out. not a fun project.
18:14jenatali: airlied, you were the one interested in looking at CLOn12's source, right? We just published it: https://github.com/microsoft/OpenCLOn12
18:16kisak: next thing you know ... OpenCL -> D3D12 -vkd3d-> Vulkan -> Vallium
18:17anholt_:finally get the x86_build fix queued to marge
18:22airlied: jenatali: cool! will take al ook
18:22jenatali: Don't judge too harshly ;)
18:27jekstrand: jenatali: What component is that, exactly? I'm not seeing mesa sources in there. Is that just an ICD loader or something?
18:27jenatali: jekstrand: The mesa sources are a runtime dependency only. There's a copy of the compiler header in there
18:28jekstrand: Oh, ok.
18:29jekstrand: jenatali: So you did your own runtime and aren't using clover?
18:29jekstrand: jenatali: Just re-using the mesa compiler stack?
18:29jenatali: jekstrand: Yeah, that's currently where we're at. Theoretically when the D3D12 backend inside Mesa gets more mature (e.g. compute shader support) we could wire it up to Clover
18:31jekstrand: Yeah, in a lot of ways clover is more infrastructure than you need. An OpenCL runtime is tiny. All the extra gallium state management stuff is just waste in some ways.
18:32jenatali: Yep. It also means we're free to make our own decisions rather than trying to potentially change Clover
18:33airlied: please change clover :-P
18:33airlied:has considered rewriting it in C for CL 3.0
18:33airlied: I just wanted to see what other people have done in the area before going nuclear
18:33jenatali: That's definitely not the kinds of changes I'd be contributing
18:34airlied: though I'm also considering moving to lvl0 and just doing CL over lvl0
18:35jekstrand: I'm fairly unconvinced that gallium is a useful abstraction. Not so much that it gets in the way. Just that 90% of it is unused and there's way more boilerplate needed to get gallium running than to write an OpenCL runtime.
18:36jekstrand: I mean, it probably is good, when you have a whole gallium driver, to re-use it.
18:37jekstrand: But if someone only cared about bringing up OpenCL, I'd have a hard time recommending they write a gallium driver just to get clover.
18:37jenatali: Right, overkill isn't necessarily a bad thing
18:37airlied: jekstrand: it's not horrible to write a compute only gallim driver though
18:37bnieuwenhuizen: but wasn't there going to be a gallium driver for GL->D3D12?
18:37airlied: if you are limiting your scope
18:38airlied: but you'd still have to deal with clover
18:38jenatali: bnieuwenhuizen: Yeah, but it's only targeting 3.3 for starters, which means compute is still out-of-scope
18:38jekstrand: Is there that much value in clover? Or would we be better off writing a CL on Vulkan state tracker?
18:38jekstrand: If someone wants to do a full rewrite anyway....
18:38airlied: jekstrand: CL on VK sucks without extensions
18:39airlied: if we are talking with extensions I'd rather go CL/lvl0/vk
18:39airlied: but the same extension could be used for CL and lvl0
18:39jenatali: jekstrand: Sounds like you're talking about Clover on Zink :P
18:39airlied:is just trying to sort out lvl0 kernel argument handling now, they copied CL but I pointed out it's not very explicit
18:39jekstrand: airlied: Yeah, we need a variable dispatch size extension.
18:40jekstrand: airlied: Not sure what else would be needed
18:40airlied: jekstrand: kernel support
18:40airlied: rather than shader support
18:40jekstrand: airlied: Yeah.... That's a very big extension.
18:41jekstrand: With very ill-defined meaning
18:41airlied: jekstrand: accept kernel SPIR-V and all it entails
18:41jekstrand: airlied: But how does argument passing work? Descriptor binding?
18:42airlied: jekstrand: argument passing is the only thing you have
18:42airlied: jekstrand: you either expose a kernel argument setting API or you expose a here's how to fill out constnat buffer 0
18:42airlied: and bind it it
18:43jekstrand: You need some sort of descriptor handling for images at the very least
18:44jekstrand: You could do something where you have a tiny trampoline entrypoint that pulls stuff out of descriptors or whatever and then calls an OpenCL-style kernel.
18:44jekstrand: Kind-of like we're doing in spirv_to_nir with entrypoint handling today.
18:45jekstrand: But trying to bolt the OpenCL binding model (or it's lack of one as the case may be) onto Vulkan isn't going to fly.
18:45bnieuwenhuizen: another fun one is workgroup memory arguments
18:46airlied: jekstrand: it's not going to fly in vulkan, I'm not sure mesa should be limited by that for an internal extension
18:46airlied: https://cgit.freedesktop.org/~airlied/mesa/commit/?h=nonya has my last hack in that direction
18:47airlied: exposes a map of kernel inputs to offsets in a UBO
18:47airlied: then you just fill out the UBO with the inputs and bind it
18:47jenatali: That's basically what we're doing as well, yeah
18:48jenatali: Except images/samplers get their own explicit bindings
18:48airlied: is also an ongoing discussion as a result of me digging around
18:49airlied: jenatali: yes some way to expose the image/samplers handles so they could be filled in better might be nice
18:49jekstrand: airlied: You're having way too much fun with the level-zero issues page. :-P
18:50daniels: jekstrand: he's a one-man community
18:51tjaalton: dcbaker[m]: hey, will 20.0.8 end the series, or will there be a .9 too?
18:51airlied: jekstrand: API design by trolling :-P
18:51daniels: jenatali: cool to see the runtime out :)
18:51jekstrand: airlied: TDD at it's finest!
18:52dcbaker[m]: tjaalton: I think that .8 will be the last of the series, since we still have a blocking bug that needs to be resolved before we can do another release
18:52tjaalton: dcbaker[m]: ok, good to know
19:33anholt_: ok, folks. merges seem to be flowing again after x86_build fix, I've tried reassigning everything I found that bounced off due to the failure back to marge. anything else is up to you.
19:33kisak: thanks anholt_, can you double check that marge is healthy right now?
19:34anholt_: kisak: sigh. looks like nchery's piglit merge wedged it again
19:36anholt_: restarted it after deassigning on that mr
19:58nchery: anholt_: kisak: Sorry, I thought getting CI setup on my repo was all that was needed
19:59nchery: I'll go take a look at the email about marge again
20:05airlied: daniels: I should hire myself out, pop-up communities
20:29daniels: anholt_: thanks a lot
20:35nchery: anholt_: I guess this was just a missed edge-case in the how-to email? Just wanna make sure there isn't something obvious I not seeing/realizing
20:40anholt_: nchery: no repo should have ci turned off, only a few people have had those and I don't know where they came from
20:40anholt_: so, the tool doesn't detect this weird edge case
20:41anholt_: and it hasn't been worth my time trying to figure out gitlab apis to patch for it
20:44nchery: anholt_: got it. thanks again for helping me get set up
21:30imirkin: mareko: can you say a few words about what TRUNC_COORD does? i've seen the same test fail on nouveau, and i never figured out why
21:39imirkin: the official docs have the highly helpful comment "truncate coordinates". where would i be without them. (there's also a MC_COORD_TRUNC, but that one doesn't have any info next to it)
21:51bnieuwenhuizen: imirkin: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3951 has the VK/D3D spec links
21:52bnieuwenhuizen: imirkin: IIRC the thing is if you go from float to integer coordinates, the default i rounding, and this options sets it to floor instead
21:53bnieuwenhuizen: (even applies th normalized coords after un-normalizing them)
21:55imirkin: bnieuwenhuizen: thanks!
22:10mareko: imirkin: MC_COORD_TRUNC is for yuv I think
22:26CME: imirkin, the evergreen docs were a bit more specific: "1=truncate when point sampling; 0=round-nearest-even to n.6 and drop fraction when point sampling."
22:27imirkin: CME: ah ok
22:27imirkin: so it really only matters when the round-nearest ends up at the next integer, so values > 63/64 or whatever
22:31bnieuwenhuizen: imirkin: note that the 1 value doesn't say what it is truncating to. I believe it is not 6-bit precision but full integers
22:32bnieuwenhuizen: (though haven't verified, but the spec suggests it)
22:32imirkin: bnieuwenhuizen: right
22:32bnieuwenhuizen: which kinda makes sense if you assume the (0,0) pixel is (0,1)x(0,1)
22:33imirkin: but the difference only matters when you have a 63/64'th value, no? otherwise it will get the same result?
22:33bnieuwenhuizen: oh right, yes
22:34bnieuwenhuizen: the off version still drops the fraction
22:43CME: just curious, on which hardware does 1-1-linear-texture fail on nouveau?
22:44imirkin: all, iirc
22:44CME: maxwell v1 is fine here
22:44imirkin: that specific deqp test
22:44imirkin: that was mentioned in the commit
22:44imirkin: in mareko's commit
22:44CME: ah oops, thought about the piglit test, sorry
22:45imirkin: i could be mixing it up with freedreno, hm
22:45imirkin: i've definitely seen that one fail rather inexplicably
22:50CME: i can try that deqp test tomorrow (too tired now), but at least with dxvk, we've only seen this issue on amd
22:51CME: and afaik adreno is based on some old radeon, so it would kinda make sense
22:51imirkin: a200 is based on like r600-ish
22:51imirkin: but they diverged pretty fast
22:51ajax: no accident that they're acronyms...
22:52ajax: anagrams. whatever.
22:52imirkin: acronym is an anagram for anagram
22:53imirkin: (not really. but turning up the confusion to 11.)