03:54bl4ckb0ne: is there an apkbuild (alpine linux) for waffle ?
05:33anholt_: grr, gitlab, could you please say *why* the test summary failed loading results?
06:02anholt_: https://gitlab.com/anholt/gitlab-experiments/merge_requests/1 shows the metrics widget but with no change reported when I tried to change
06:02anholt_: https://gitlab.freedesktop.org/anholt/gitlab-experiments/merge_requests/7 doesn't even show the widget
13:46eric_engestrom: bl4ckb0ne: I don't know Alpine packages but I think they're similar to Arch?
13:46eric_engestrom: if so, have a look at the arch PKGBUILD for waffle: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=waffle
13:47eric_engestrom: bl4ckb0ne: you should be able to adapt it easily :)
14:41daniels: anholt_: per https://docs.gitlab.com/ee/ci/junit_test_reports.html it's globally disabled by default - I've flipped it on now
15:24bl4ckb0ne: eric_engestrom: will do then :D
17:53alyssa: ...this has got to be a gallium bug...
17:55alyssa: Is pipe_resource::bind not, well, binding? just a suggestion? :|
17:55alyssa: "Resource binding flags -- state tracker must specify in advance all the ways a resource might be used." k.
17:56robclark: iirc, gl doesn't necessarily know all the ways a reasource might be used
17:56alyssa: In dEQP-GLES3.functional.buffer.map.write.render_as_index_array.pixel_pack_full, I have a resource being allocated as RENDER_TARGET | SAMPLER_VIEW, but then used as an index buffer
17:56alyssa: Since we get a binding of RT|sampler, we tile. But then you can't tile an index buffer (on mali anyhow) and it fails.
17:56alyssa: If it had specified INDEX on the binding, we would've given linear and the test would pass.
17:57alyssa: And per that comment it should have given INDEX if it could possibly be used that way
17:57alyssa: Unless there's some magic "change the binding" callback
17:57Venemo: sounds like a bug in the test case
17:57alyssa: Venemo: You think it's out of spec for GL, you mean?
17:57imirkin_: alyssa: it's all lies
17:58imirkin_: that said, no way that a RENDER_TARGET can get bound as an index buffer
17:58imirkin_: index buffer must be a PIPE_BUFFER, while a render target must be != PIPE_BUFFER
17:58alyssa: imirkin_: Well, it is, in that test case.
17:58robclark: the resource type should be BUFFER.. which I don't think is a thing that makes sense to try to tile
17:58imirkin_: note that if you free() and then malloc(), the pointer can be equal
17:59imirkin_: so if you're storing pointers without taking references and then comparing for equality, you can be disappointed
17:59alyssa: I'd buy that
18:00imirkin_: you use GALLIUM_TRACE=foo.xml and then use the tools in ... somewhere in the tree ... to help read them
18:00imirkin_: it gives you all the calls + a bunch of dumped info
18:00alyssa: Checking for ==TEXTURE_2D fixes it
18:00alyssa: Still, this seems like a mesa/st bug if the binding is wrong but maybe it's that pointer thing idk
18:00Venemo: alyssa: I'm not a GL expert by any menas but based on how you described it, it sounds like the test case makes a mistake
18:01alyssa: Venemo: It's certainly possible. Not sure if the edge case is in spec or not.
18:02Venemo: does it pass when you change the test case to use the binding that you think is correct?
18:02alyssa: But binding a PIXEL_PACK_BUFFER, writing to it directly with index data, unbinding, then rebinding as an index buffer and drawing ... does smell funny :)
18:02imirkin_: pixel pack buffer will always be a PIPE_BUFFER
18:02alyssa: Fair enough, then
18:02imirkin_: which can certainly be reused as an index buffer
18:02imirkin_: that's totally legal
18:02alyssa: At any rate, with that accounted for we're passing dEQP-GLES3.functional.buffer.*, weeeee...
18:03imirkin_: anyways, the whole ->bind flags thing is mostly a lie ... you shouldn't rely on it being 100% accurate
18:03imirkin_: it's more to communicate stuff like PIPE_BIND_LINEAR and whatnot
18:03imirkin_: coz in GL any buffer can be used for anything
18:04imirkin_: so passing in all the bind flags always isn't incredibly useful either
18:04imirkin_: iirc intel computes a usage history for internal hinting
18:04alyssa:runs more o dEQP
18:05alyssa: Something tells me I'm going to be with ES3.0 dEQP for a while...
18:05imirkin_: nouveau has all kinds of flushes in place for constbufs.
18:06alyssa: Oh, joy, I still have to implement multisampling, this will be Fun with a capital f
18:07imirkin_: is msaa *required* for ES3?
18:07alyssa: For 3.0, I think so
18:07imirkin_: freedreno's been faking it for ages
18:07imirkin_: there's a PIPE_CAP for it
18:07alyssa: At least, I have to fake it then
18:07Venemo: it is entirely possible that some of the tests have typos or mistakes, too.
18:09robclark: (we only fake it for early gen's, fwiw)
18:11alyssa: ES3 is just so.. large
18:11alyssa: And then ES3.2 is twice the size somehow
18:15alyssa: Okay, ES3.0 level anyway MSAA doesn't look so scary
18:18imirkin_: it's annoying ... even if you don't implement the "fancy" stuff externally, you still have to handle e.g. blits between MSAA surfaces somehow.
18:19Venemo: alyssa: btw congrats, according to phoronix you had the most commits in mesa in 2019
18:19alyssa: Venemo: Does that make me a try-hard or just a workaholic?
18:20imirkin_: you'll have to start going to meetings about your addiction to workahol...
18:21Venemo: alyssa: nothing wrong with either of those
18:23Venemo: I didn't mean it in a negative way
18:24alyssa: I know, just teasing :)
18:33robclark: mmm, workahol, that cause of and solution to all segfaults
18:34imirkin_: nice one
18:34imirkin_: (that's one of my favorite simpsons episodes...)
18:35imirkin_: at first, prohibition was great... people were drinking more, and having more fun. but without alcohol, prohibition just doesn't work!
18:40sravn: mripard: anything holding back applying LogiCVC?
18:44sravn: mripard: forget it, I have a few review comments, mail coming
18:53Kayden: BTW I stole the usage history for internal hinting from radeonsi. They did it first. :)
18:57imirkin_: at least if a shader writes to something with a ssbo, you're supposed to get a barrier
22:09anholt_: daniels: thanks! weird that junit impacts metrics too.
22:10anholt_: (and the junit widget *was* showing up)
22:26anholt_: daniels: oh. o, I had my gitlab version open still. fd.o still doesn't show metrics widget.
22:29daniels: anholt_: are the metrics in the default branch? wonder if they're not shown until they are
22:31anholt_: daniels: yeah, I've got metrics in master, that change is changing them in the MR, which seems to be what it's supposed to be diffing.
22:32anholt_: https://gitlab.freedesktop.org/anholt/gitlab-experiments/pipelines/93935 (master)
22:33anholt_: looking for metrics in their issues page is mostly about prometheus
22:34daniels: 93935 doesn't seem to be associated with a MR?
22:34anholt_: hmm, you think we have to click merge on an MR for it to store that as baseline?
22:35anholt_: oh, right, I did try merging an MR last night (https://gitlab.freedesktop.org/anholt/gitlab-experiments/merge_requests/6/diffs)
22:36daniels: yeah, if it's not merged into the target branch then it can't be the baseline
22:37anholt_: one would hope that they would pick the completed pipeline for the base commit of the branch, but that's probably too much to ask.
22:37anholt_: so I merged an MR then put up a new one with those v3d metrics
22:37anholt_: and the new MR didn't show changes either
22:37anholt_: and, anyway, the same commits show the metrics widget on gitlab.com but not on fd.o
22:40daniels: yeah ok, honestly I don't know how it's plumbed through and can try to take a look tomorrow once I've bottomed out a couple of other things
22:40daniels: will be away most of next week tho