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