00:01anholt__: austriancoder: not your commit's issue, I had an nginx running on that one port from my previous effort in doing artifacts caching.
02:10ngcortes: Heads up folks: I need to incur a brief jenkins downtime in the next half hour to deploy a fix to the CI testers. Should take no more than a half hour
02:58ngcortes: Upgrade to mesa CI complete :)
03:40austriancoder: anholt__: thanks for the update
04:37airlied: bleh when a test that has nothing to do with the renderer finds a possible bug in the multisample renderer, uggh
04:37imirkin: tests suck ... people should just trust that your impl is right
04:42airlied: imirkin: I'd prefer if the tests that test the rendering found the rendering bugs :-P
04:43airlied: imirkin: the test is just uploading data to a 4x4 multisample texture badly
04:43airlied: it leavs the viewport set to the viewport for the window
04:43airlied: which when the window is extereme non square seems to hit a bug in my ms renderer
04:43airlied: like 1024x64 window dims
04:56airlied: ah we have a piglit that I can pass paramters that make it break, thats usefukl
06:13tomeu: MrCooper: do you have any further comments on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5472 ?
06:39airlied: uggh it was sign extension going wrong, ah well hopefully last bug :-P
06:45imirkin: that's every bug =/
06:45imirkin: (not sign extension, but "the last bug"
06:48airlied:goes to kick off CTS to find the next last bug
06:56tzimmermann: airlied, can i convince you to accept the mgag200 desktop patch? :)
06:59danvet: I'm still happy to have my ack on there at least
06:59danvet: worst case we do a separate Kconfig knob for the real pci ids
06:59airlied: tzimmermann: yeah I'll remain skeptical but won't block it :-)
07:00danvet: so damage is limited if we get a regression report, and if it makes some people happy why not
07:00airlied: like I think nymber of mga g200 cards in existance outisde suse is probably low :-P
07:01tzimmermann: airlied, thanks a lot. my plan is to add support up to g550, which is still being sold by matrox. so the effort is not just for old HW, at least
07:02airlied: tzimmermann: how much vram does a g550 have?
07:02airlied:assumes not enough to bother with the 3d engine on modern desktops
07:03tzimmermann: 32 mib
07:03tzimmermann: i *dont'* bother at all about 3d
07:03tzimmermann: it's only about kms
07:04danvet: yeah 32MB for a few framebuffers is at least useable
07:05tzimmermann: actually, someone sent me an email to ask whether i'd add 3d support as well. :D
07:06tzimmermann: i politely said no
07:06danvet: ln llvmpipe_dri.so mga_dri.so
07:06danvet: it'll be faster most likely too
07:07tzimmermann: g550 has directx6-level HW. /me wonders if there even any software on linux that could use it
07:10imirkin: from wikipedia, "In 2002, Microsoft released DirectX 9"
07:10imirkin: time flies.
07:11danvet: yeah I don't think you'll find anyone who cares about shader-less gpu accel paths anymore
07:12danvet: if they bother with a gpu, even the tiniest soc has at least gles2 now
07:12imirkin: DX6 brought such advanced features as multitexturing, stencil buffers, s3tc
07:13tzimmermann: i'm looking at this page: http://www.vgamuseum.info/index.php/component/k2/item/217-matrox-millennium-g550
07:13imirkin: danvet: are you implying that my TNT2 is obsolete?
07:14tzimmermann: they released a dx6 chip in 2001 when dx9 came out in 2002.
07:14imirkin: well, remember back in those days, things moved faster
07:14tzimmermann: no wonder they went out of the mainstream market
07:15imirkin: dx6 was late 1998
07:20airlied: tzimmermann: any plans for parhelia support :-p
07:21tzimmermann: he he
07:21danvet: uh reading old dx3d history
07:21danvet: firs versions had execute buffers you had to construct
07:22danvet: but everyone was screaming they want immediate mode like gl, so dx5 added all that
07:22tzimmermann: i was looking for opensource drivers for parhelia, but could not find anything.
07:22tzimmermann: if anyone knows something...
07:22tzimmermann: danvet, wasn't that why john carmack went with opengl?
07:23ManDay: Should libglvnd bugs be reported on mesa's GitLab?
07:23airlied: tzimmermann: yeah there was never any open source ones, I think ajax might have had some RE done years ago
07:25tzimmermann: even the parhelias are old these days...
07:26tzimmermann: and only on agp? that's a death blow
07:29ManDay: Yes, no? Anyone?
07:31tzimmermann: ManDay, hi! it looks like the upstream is https://github.com/NVIDIA/libglvnd
07:31daniels: not quite
07:31tzimmermann: i see
07:32tzimmermann: hmm, that's not the top result in searches :/
07:33ManDay: Sorry, disconn, bugs for libglvnd, anyone?
07:34tzimmermann: MayDay, daniels said https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/new
07:34ManDay: Ah yeah, thanks.
07:35ManDay: I didn't see the "Issue" link at the menu at the left, so used to GitHub
07:35tzimmermann: well, thanks for reporting bugs
07:35ManDay: Haven't yet (not upstream, that is)
07:44ManDay: Silly WiFi
07:44ManDay: Reported https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/206
07:45ManDay: I'd like to be able to compile stuff without patching again :-(
07:51danvet: mlankhorst, airlied I justed merged the 3 dma-fence annotation/doc patches
07:51danvet: I think another pull so they make it into 5.9 would be good
07:52danvet: I wanted to wait until thellstrom is back from vacations, hence why it missed by a tiny bit
07:56airlied: fine with me
07:56airlied: i want the nouveau bits anyways
08:00MrCooper: tomeu: none
08:04sumits: hi danvet: apologies for the delay in responding; had a network outage over the weekend.
08:05sumits: danvet: fwiw, feel free to add my Acked-by for the the relevant dma-fence annotation patches
08:28danvet: sumits, oops sry just pushed like half an hour ago :-/
08:33kusma: eric_engestrom: yeah, so I would have answered robclark (because I remember him doing something with it), but I guess I would have been wrong, then ;)
11:50sumits: danvet: oh. sorry, bad timing for me :(
12:33bbrezillon: mattst88: thanks for the review. I've pushed a new version with a patch removing the glsl implems (didn't add your R-b on this one, since it's new)
13:28kisak: I've got a dumb question, does mesa/libclc care about system-wide spirv headers? Meaning, if I have mesa / llvm / libclc built with early 2019 spirv headers, is there going to be runtime issues when someone goes to use opencl?
13:29kisak: as long as any issues show up as a compile-time failure, that's fine because I'll catch those. I just don't know if there can be runtime issues.
13:33kisak: maybe not used directly by mesa / libclc / llvm at all? Only glslang?
13:36bbrezillon: robclark, anholt__: does that ring a bell https://gitlab.freedesktop.org/bbrezillon/mesa/-/jobs/3720216 https://gitlab.freedesktop.org/bbrezillon/mesa/-/jobs/3719848?
13:37bbrezillon: 2 runs, and 2 different failures, on the same group of tests though
13:40bbrezillon: and it passed on the 3rd attempt
13:44ajax: tzimmermann: never any open source p-series drivrs afaik. i did find a header file full of interesting-sounding register names and values on ftp.matrox.com once, which i think i still have somewhere.
13:45ajax: and the modesetting you can mostly RE from the VBE calls if you're patient and lucky
13:45tzimmermann: ajax, i'm not going to write that driver :D
13:46ajax: a wise decision
13:47ajax: hah, nearly forgot about this
13:47tzimmermann: i'd consider old pci and pcie cards worth supporting if the effort is low. parhelia is agp-only, it's dead already
13:47ajax: matrox did actually ask for a project directory for a p-series driver
13:47ajax: ... and then never uploaded anything
13:48tzimmermann: ajax, they did! "added test file to check the repository"
13:48ajax: tzimmermann: no? there were definitely pcie QID cards
13:49ajax: p-series with 4 crtcs
13:49tzimmermann: i see
13:49tzimmermann: it still doesn't pass the low-effort test
13:49tanty: tomeu: with the change for tracie to download traces from minio, how is it possible now to test with forks of the traces-db repo?
13:50ajax: definitely doesn't
13:50ajax: m-series either
13:52tomeu: tanty: just change the download-url in the traces.yml file to point to the artifacts url of your traces-db fork
13:53tanty: OK, thanks!
13:53tanty: ah, right, I saw that in the Ci ...
14:07ajax: anyone remember why libGL needs link_whole: true?
14:13robclark: bbrezillon: haven't seen that one before, and nothing similar has showed up as a flake
15:04ManDay: Is kbrenneman present?
15:31robclark: tomeu, anholt__: is it normal that LFS makes 'git pull --rebase origin master' on the traces-db tree take *forever*?
16:32ajax: ugh the applegl support is so hideously stupid
17:22karolherbst: soo.. I have an ugly bug
17:22karolherbst: a CTS test uses a user uniform buffer to store uniforms
17:23karolherbst: later on the same context, it links/binds other program objects
17:23karolherbst: but gallium never unbinds the user uniform buffer
17:23karolherbst: how should we deal with the situation? should gallium invalidate the uniform const buffer or is there something the driver should handle themself?
17:31imirkin: the driver has no way of knowing
17:31imirkin: so it must be st/mesa (or mesa/main)
17:31anholt__: robclark: pretty sure git pull is going to pull down and check out everything from head, so, yeah maybe?
17:31anholt__: there might be some options for "don't check things out by default", I don't know much about it
17:33robclark: so I managed to git-fetch, and then 'git reset --hard origin/master'.. which itself took a while.. but I guess that has something to do w/ downloading stuff from lfh
17:39karolherbst: imirkin: right... okay, so st/mesa needs to do it, just wondering when exactly
17:39imirkin: karolherbst: probably when the program that the uniform buffer is associated with gets unbound?
17:39karolherbst: I'd say when a new one gets bound
17:39karolherbst: but yeah..
17:39karolherbst: At least the registry is saying this: "All active uniform variables defined in a program object are initialized to 0 when the program object is linked successfully. They retain the values assigned to them by a call to glUniform until the next successful link operation occurs on the program object, when they are once again initialized to 0."
17:40karolherbst: I think we don't do this at all :)
17:40imirkin: if you do it when a new one is bound, then you end up with a bad pointer in driver state
17:40imirkin: don't want that
17:40imirkin: also it has nothing to do with clearing stuff to 0
17:43karolherbst: imirkin: "When a program is linked successfully, all active uniforms, except for atomic counters, belonging to the program object’s default uniform block are initialized as defined by the version of the OpenGL Shading Language used to compile the program." whatever that means :p
17:43imirkin: is that in the spec? or the man page?
17:44karolherbst: OpenGL 4.6 (Core Profile) - October 22, 2019 page 134
17:44karolherbst: no 134 :D
17:44imirkin: dunno whether we do this
17:44karolherbst: probably not
17:44imirkin: but it doesn't seem particularly pertinent to the issue at hand
17:44karolherbst: chromium has a workaround for that against mesa
17:44anholt__: that bit of spec is likely talking about how glsl lets you specify uniform initializers to set things to other-than-0 at link time
17:45karolherbst: ohh, I see
17:45imirkin: anholt__: sounds like the implication is that they all get a 0 default initializer
17:45anholt__: imirkin: correct
17:45karolherbst: so it doens't matter
17:45anholt__: karolherbst: what specific behavior are you seeing?
17:45karolherbst: so whatever you do, it's 0
17:46karolherbst: anholt__: set_constant_buffer is not called
17:46karolherbst: after the program was switched
17:46imirkin: anholt__: a stale constbuf is left in a context with a bad userptr
17:46anholt__: does second program use cb0 at all?
17:46karolherbst: mhhh... good question
17:46anholt__: though, even without use in the program, I would personally expect st to unbind cb0.
17:47anholt__: (or a 0-length one, possibly)
17:47karolherbst: seems to have only an ssbo
17:47karolherbst: but no uniform
17:47karolherbst: the thing is, we just end up reuploading that stuff as the CTS used a different context in the meantimg
17:47karolherbst: and we restore the previous context state
17:48karolherbst: we could be smarter and only upload constant buffer actually used by the program.. but mhhh
17:48anholt__: st_atom_constbuf.c does look like it tries to unbind an unused cb0
17:48anholt__: so this is sounding more like a driver issue to me.
17:49karolherbst: well, set_constant_buffer doesn't get called
17:49karolherbst: only with set date
17:49karolherbst: never with unset one
17:50karolherbst: yep.. not even st_upload_constants gets called
17:51karolherbst: anholt__: maybe we need to set ST_NEW_VS_CONSTANTS and others when the program gets relinked?
17:51karolherbst: but mhhh
17:51karolherbst: that's not the issue actually
17:51anholt__: pretty sure relink should go through the rebind path which would also flag consts
17:51karolherbst: yeah, but we don't relink actually
17:52karolherbst: the CTS doesn't
17:52karolherbst: it just sets a new program
17:52karolherbst: but we still have the old const buffer state
18:01imirkin: karolherbst: it all goes through the cso_context iirc
18:01imirkin: which is another nice little level of indirection
18:02karolherbst: yeah.. mhh
18:31airlied: karolherbst: i think there is a bit of an assumption that if nothing is looking at cb0 there is no harm leaving it bound
18:31karolherbst: airlied: right....
18:32karolherbst: we just have some code around doing some magic if we see a different gl context used and switch some state around
18:32karolherbst: which heavily conflicts with an assumption like that
18:32karolherbst: we could probably be smarter and only reupload _used_ stuff
18:32karolherbst: but no idea if we could know this
18:32karolherbst: imirkin: any ideas?
18:33airlied: that context magic sounds wrong
18:33airlied: or at least hacky
18:33karolherbst: no duh... I was never a fan of it to begin with :p
18:38imirkin: karolherbst: can't look now.
18:40airlied: karolherbst: where does it upload it to?
18:40airlied: is this just the shared pushbuf?
18:41karolherbst: airlied: yes, but from a userptr
18:41imirkin: we have a dedicated buffer allocated for cb0 user ptr's
18:41karolherbst: and the time we get there, the CTS already fred the memory
18:41imirkin: uploads to ubo's have to go via pushbuf pretty much anyways
18:42karolherbst: imirkin: wondering if we could just memcpy it as well...
18:42karolherbst: but where to
18:42karolherbst: I have no idea what guarentee OpenGL promises here
18:42imirkin: opengl doesn't promise anything
18:43imirkin: this isn't an opengl problem
18:43imirkin: it's a st/mesa problem
18:43karolherbst: I meant the userptr stuff
18:43karolherbst: what if the application would be free to free it immediatle after glUniform
18:43imirkin: the application doesn't supply the userptr
18:43karolherbst: would be a nouveau bug then
18:43imirkin: st/mesa supplies the userptr
18:43imirkin: or mesa core
18:43karolherbst: it supplies the buffer at least
18:43imirkin: it does not
18:43karolherbst: even if it's a GL one
18:44imirkin: mesa main supplies the buffer, attached to the program
18:44anholt__: st/mesa definitely generates the cb0 user_buffer.
18:44karolherbst: we get the ptr from the CTS
18:44imirkin: then it's an unrelated issue
18:44karolherbst: how is that unrelated?
18:44imirkin: coz it's not in the default uniform
18:44anholt__: ify ou've got one of the cts's pointers in cb0's user_buffer, something else has gone horribly wrong and you need to fix how that ended up there.
18:44karolherbst: imirkin: it is
18:44imirkin: there's no way for an application to supply the backing for the default uniform buffer
18:45karolherbst: but that's what's happening
18:45imirkin: then we've got serious problems
18:45imirkin: since there's no legal data path for that
18:45airlied: guess you get to dig more
18:45karolherbst: imirkin: glUniform*v?
18:46imirkin: right, that doesn't supply backing for the default uniform buffer
18:46airlied: that should be copied into a user buffer
18:46anholt__: karolherbst: that goes read immediately, through a twisty path in mesa/main, and eventually ends up in mesa/st-owned user_buffer.
18:46karolherbst: mhh.. maybe I messed up in comparing the pointers though
18:46karolherbst: let me check again
18:46imirkin: well, it's a user pointer
18:46imirkin: so free(); malloc(); can return the same thing
18:48karolherbst: ahh.. seems like I indeed messed up comparing the ptrs and thought there are the same
18:49karolherbst: okay.. so the ptr gets fred by st_delete_program
18:49karolherbst: and we never get notified about it
18:50karolherbst: okay.. mhhh
18:51karolherbst: I have an idea now
18:51airlied: seems like you could ttack ifvany shaders in ctx use cb0
18:51airlied: in driver
18:51karolherbst: if we get a new program bound, we just need to mark stuff as valid if it doesn't get touched or so
18:54imirkin: you mean dirty?
18:55karolherbst: no, as non dirty :p
18:55imirkin: that's bogus
18:55imirkin: the bad values shouldn't be there in the first place.
18:55karolherbst: I agree with st/mesa though, no point in touching untouched and irrelevant things
18:55imirkin: having dangling pointers is just asking for trouble
18:56karolherbst: right.. dangling points are still bad
18:56imirkin: i think the drivers that don't manage their own constbufs
18:56imirkin: only do the upload on set_constbuf
18:56karolherbst: or memcpy
18:56imirkin: so they never look at the bad pointer
18:56imirkin: it's not the worst API change to make to gallium
18:56imirkin: but if we do that, i'd like to document that behavior
18:57imirkin: i.e. a user pointer cb is only valid for the first draw that happens right after it
18:57imirkin: after which point it's on the driver to keep track of the underlying data
18:57karolherbst: that just ends up with pointless calls again
18:57karolherbst: I'd prefer a solution which does not add more driver overhead
18:58karolherbst: or at least not for everybody
18:59airlied: surely you only need to fix the magic ilload
18:59imirkin: karolherbst: it already does the pointless calls
18:59airlied: andn i think shader info has a flag
18:59karolherbst: imirkin: where?
18:59imirkin: i don't remember
18:59imirkin: but i'm pretty sure it calls set_constbuf on each draw when there's a user ptr
19:00imirkin: otherwise the caching thing won't know that it needs to re-read the user ptr
19:00airlied: seems like you should know what shaders are bound
19:00karolherbst: imirkin: but then we can just skip uploading it unless new data gets provided
19:02imirkin: karolherbst: yes, my point exactly. but that's not the current definition of the gallium api.
19:02imirkin: and it's a very awkward way to define it
19:02imirkin: but if everyone's cool with it, define and move on
19:03airlied: i its not being used dont look at it
19:03airlied: is how i see the api now post mareko evolution :-)
19:05karolherbst: I'd say that's already implicit the case for like everything
19:07karolherbst: this will just be a bit ugly to fix in nouveau
19:09imirkin: so anyways, i don't think its any material overhead for other drivers to fix it in st/mesa
19:10karolherbst: well, the fix I have in mind would also lower the overhead in nouveau
19:10karolherbst: aka not uploading buffers not needed
19:10karolherbst: but still leave them as dirty
19:11imirkin: we still have to upload
19:11imirkin: coz user ptr values can change from draw to draw
19:11karolherbst: but it's not used by the shader
19:11imirkin: oh, then fine ;)
19:11karolherbst: yeah :)
19:11karolherbst: that's the idea: skip uploading const buffers if not used by the sahder
19:11imirkin: seems reasonable.
19:12karolherbst: just wondering how to do that in nvc0_constbufs_validate.. mhhh
19:14karolherbst: we probably don't save the information which const buffer is touched.. oh well
19:14karolherbst: at least I have a proper idea now
19:18imirkin: we only allow user ptr in cb0
19:18imirkin: so you could have a mask of which stages need uploading
19:18imirkin: and do the upload at draw time
19:18imirkin: and clear the mask
19:19karolherbst: imirkin: my idea was to save touched const buffers per stage and check that in nvc0_constbufs_validate and skip untouched ones
19:20imirkin: karolherbst: that's pretty much what i said, right?
19:20karolherbst: well.. why limit it to cb0?
19:20imirkin: only cb0 needs to be uploaded explicitly
19:20imirkin: everything else is resources
19:21imirkin: (and cb0 can also be a resource)
19:21imirkin: (with st/nine for example)
19:21karolherbst: but we would still save on _something_ if we just do it for all cbs, no?
19:22imirkin: i don't think it'd be a noticeable amount
19:22karolherbst: probably not
19:22karolherbst: well.. nvc0_screen_bind_cb_3d still adds to the pushbuffer
19:23karolherbst: even if it's not noticeable, I think it's still reasonable to just do it for all cbs
19:23imirkin: can't look now, don't remember off-hand
19:23karolherbst: imirkin: uhh, there is even a conditional IMMED_NVC0(push, NVC0_3D(SERIALIZE), 0); in it :D
19:24imirkin: yeah, just cb0 is special
19:24imirkin: the other cb's won't randomly change willy-nilly like that
19:24karolherbst: mhh, right... probably not, anyway, will just see how much work it is to only do it for cb0 vs all
19:24karolherbst: and if it doesn't matter I just do it for all
20:19Lyude: hey-is there any discussion I can catch up on regarding the WSL/DX stuff for mesa? mostly curious if there are still plans to try to do d3d/dx only under wsl (and end up making applications that can only run under wsl as a result...)
20:21anarsoul: Lyude: hi, any progress on oled/intel interface for panel backlight patches?
20:21Lyude: anarsoul: see pm
21:01jenatali: Lyude: I haven't seen much more discussion happening since we announced it. Our plans for D3D in WSL isn't really around introducing an API for Linux developers to target which would lock them into WSL - it's more as an implementation detail to bring hardware acceleration to WSL via mapping layers (GL and CL with some help from Mesa, TensorFlow via DirectML)
21:01Lyude: jenatali: ahhh, cool :)
21:01Lyude: thanks for the info!
21:02jenatali: Yep, no problem :)
21:02jenatali: We're hoping to talk in more details at XDC
21:04airlied: where's vulkan over d3d12 :-P
21:05jenatali: Heh, nowhere - yet :P
21:09EdB: I don't want to reimplement a printf parsing :/
21:10jenatali: EdB: Dunno how useful it'd be, but this is what I ended up doing: https://github.com/microsoft/OpenCLOn12/commit/a7aee165532a97c762cb3e7c64e9ed89d9d93a3d#diff-58adc7a66765518160cb8bb287a51249R604
21:10airlied: EdB: surely there is an MIT one out there already
21:11jenatali: Essentially, dump raw text, and then deal with the idiosyncrasies of CL's printf formatting (i.e. vectors) and convert it into corresponding C printf formatting
21:13jenatali: And yes it's MIT so take whatever you want
21:15EdB: there's some other printf around, but most of the time they are compliant and there is no licence
21:17EdB: Also it's sad that std::format didn't bother to have a prinf compatible formatter
23:09SolarAquarion: i got a build failure in mesa
23:11SolarAquarion: looks new
23:12airlied: dschuermann: ^?
23:12bnieuwenhuizen: SolarAquarion: pull again?
23:13airlied: SolarAquarion: I think a fix landed for it just now
23:28alyssa:is trying to figure out if RK3399 display driver supports the AFBC lossless colour transform (YTR)
23:28alyssa: I don't see any support for it in the kernel, but it's also a little baffling that the hw would miss it, unless the hw is older than the transform
23:29alyssa: I guess I'll find out as soon as I wire up panfrost ...
23:38SolarAquarion: ../mesa/src/vulkan/overlay-layer/overlay.cpp:31:10: fatal error: 'git_sha1.h' file not found
23:38SolarAquarion: #include "git_sha1.h"
23:39alyssa: SolarAquarion: meson's supposed to generate that
23:40SolarAquarion: yes, but for some reason it doesn't i rm -rf'ed all the directories to make sure a clean build occurs
23:40jenatali: Sounds like a missing dependency
23:40jenatali: i.e. a build ordering issue
23:40anholt: check for other users of sha1_h in meson.build, make sure that does so too.
23:41SolarAquarion: it fails in [1992/2449]
23:52bnieuwenhuizen: SolarAquarion: I think, besides just rerunning ninja, that https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6019 should fix it
23:57SolarAquarion: bnieuwenhuizen: thanks, let me rerun ninja and let's see what changes
23:59dcbaker[m]: bnieuwenhuizen: you have my r-b on that