00:08tanty: anholt, bnieuwenhuizen: I don't know what happened with the initial build after the change for winehq-stable
00:08tanty: But it seems to be building right now.
00:08tanty: A case of bad luck when rebuilding in the WineHQ's OBS?
00:10tanty: bnieuwenhuizen: should you stop the revert ?
00:11tanty: I stopped it
00:12bnieuwenhuizen: tanty: source for building right now?
00:18tanty: Job succeeded
00:19bnieuwenhuizen: what could cause two different runs of the same commit to fail on an apt-get?
00:19tanty: The package from the additional repository.
00:20tanty: Most probably there was some change either in the package or in the Debian dependencies and they were rebuilding it just now.
00:20tanty: So it took the just old package while OBS was generating a fresh one.
00:20bnieuwenhuizen: uff, so our image build are not hermetic based on the git commit ...
00:22tanty: It would happen with any packages based distro, I believe, if we need to pick up more recent packages than the ones provided in stable.
00:22tanty: But this is really bad luck.
00:22tanty: FWIW, I think that can also happen with the LLVM packages.
00:22tanty: (the ones not in buster)
00:23bnieuwenhuizen: well, with the base distro packages as well I presume?
00:23tanty: Yeah, but Debian Buster (stable) is really not moving.
00:24tanty: Not the dependency chain, at least.
00:24tanty: Of course, if you get packages from testing ... (the other alternative to using the one from WineHQ) ... then, you are in the same mess :(
00:24kisak: the error further up in the log -> time="2020-04-24T20:18:46Z" level=fatal msg="Error parsing image name \"docker://registry.freedesktop.org/mesa/mesa/debian/x86_build:2020-04-22-winehq\": Error reading manifest 2020-04-22-winehq in registry.freedesktop.org/mesa/mesa/debian/x86_build: manifest unknown: manifest unknown"
00:26tanty: kisak: that's expected
00:26tanty: it tries to pull from the registry. If it doesn't exist, then it builds the image.
00:26tanty: If it wouldn't be expected, the job would have failed.
00:27kisak: oh right, for the fast completion of repeat jobs, sorry for the noise
00:27tanty: no prob
00:31kisak: I searched the build log that completed before I posted that last comment, but the log in gitlab's view didn't have everything from the start
08:53MrCooper: tanty: hitting this kind of issue should be very unlikely with the Debian testing repository
08:53MrCooper: looks like we should use that instead
15:10karolherbst: ehh.. st_nir_lower_wpos_ytransform messes up doubles for me.. but I gues doubles were always messed up with our nir path
15:10karolherbst: "decl_var shader_in INTERP_MODE_NONE dmat2x3 in_vs_last (VERT_ATTRIB_GENERIC14.abcdef, 0, 0)" -> "decl_var shader_in INTERP_MODE_NONE dmat2x3 in_vs_last (UNKNOWN.abcdef, 0, 0)"
15:11karolherbst: ehh.. wait, it can't be that pass as it only does stuff for fp
15:11karolherbst: nir_remap_dual_slot_attributes... I see
16:58sravn: pH5: OK to commit "Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge"?
16:59sravn: pH5: pinchartl already commented on all patches and added r-b on most
17:00sravn: pH5: The prerequisite patch is applied (https://lkml.org/lkml/2020/4/16/2080) now.
17:18karolherbst: there are three CTS regressions (probably in core mesa): KHR-GL45.direct_state_access.textures_buffer_errors, KHR-GL45.direct_state_access.textures_buffer_range_errors, KHR-GL45.direct_state_access.textures_parameter_setup_errors
17:18karolherbst: did anybody already look into those?
17:52imirkin: heh. someone's going through and closing old dEQP issues in the public google issue tracker with messages along the lines of "thank you for taking the time to file a bug. we haven't looked at it in 4 years, and never will." oh well.
17:59karolherbst: imirkin: if one of yours is this, refile against VK-GL-CTS as long as it's part of the GLES CTS ;)
17:59karolherbst: if it's the deqp stuff I wouldn't care
18:00karolherbst: or not as much
18:00imirkin: yeah, i'd have to go back and check on some of that stuff
18:00imirkin: not worth it
18:00pcercuei: general devicetree ABI question: are node names ABI? Since they appear in sysfs, I'd assume yes, but I'm not sure
18:00karolherbst: imirkin: yeah... especially that I already ran the GLES CTS and updated the trello cards :p
18:00imirkin: karolherbst: they were issues that were hit with llvmpipe
18:01karolherbst: sounded like API validation though
18:01karolherbst: but yeah...
18:01imirkin: https://issuetracker.google.com/issues/37081717 + https://issuetracker.google.com/issues/37094265
18:01imirkin: at least so far
18:02karolherbst: this message I saw today
18:02karolherbst: from the GLES CTS
18:03karolherbst: or something similiar :D
18:03karolherbst: ahh no, those new fails have similiar messages as well
19:56robclark: yeah, I got a bunch of spam about closing deqp bugs in the last day or few.. kinda nice that they sat on a bug where I even provided the one-line patch fix for 4yrs and then closed it as "won't fix" :-/
20:03imirkin: robclark: if only you worked at that company, you could change things
21:08karolherbst: robclark: btw, will there be some "official" announcement that deqp is now a downstream fork of VK-GL-CTS? It kind of seems like that right now it's treated as one
21:25robclark: karolherbst: no idea, other than a user of deqp I'm not really involved
21:26Kayden: karolherbst: chrisf would probably be the one to talk to
21:26Kayden: (unless that changed in the last few months while I was gone)
21:41chrisf: karolherbst, i suppose i should make some kind of announcement
21:42chrisf: but it has just quietly happened -- for the vulkan tests, vk-gl-cts has been "upstream" since khronos adopted it
21:43karolherbst: chrisf: yeah.. the docs pointing to the VK-GL-CTS and that "upstream-master" branch were a bit of a surprise at first
21:43karolherbst: sure.. but it makes sense to do this step and moving the GLES bits there as well
21:43chrisf: and the gles side has quieted down because android has stopped trying to push gles to be better
21:43karolherbst: I see
21:45chrisf: next thing i would like to do is to get the android gles test set better aligned with the khronos gles set
21:54karolherbst: chrisf: I could imagine that some of those tests are actually incorrect and now driver and application already depend on wrong behaviour :/
21:54karolherbst: any idea how bad the situation is there?
21:54chrisf: there's always some number of tests like that
21:55karolherbst: I mean, I'd understand if android would want to keep the broken tests to ensure applications are still working in the future
21:55chrisf: im not aware of any cases where we *require* wrong behavior
22:00chrisf: there's a few places where android requires something the spec doesnt (i think perf, and details of sync behavior) but no desire to be in conflict. you should be able to pass both the khronos cts and android cts with the same driver with no hacks.
22:01imirkin: is DRM_CAP_CURSOR_WIDTH supposed to be the max width/height supported? or just a good size?
22:02imirkin: e.g. kepler+ supports 256x256, but also continues to support 64x64 (and 32x32 and 128x128)
22:47ascent12: imirkin: My interpretation was "a valid size", and didn't say much beyond that. And then people ask why we have a 256x256 allocation for a tiny little cursor.
23:02imirkin: ascent12: ah yeah, that makes sense
23:03imirkin: and so then cursor-using software just sorta has to know what sorts of things hw supports
23:03imirkin: since at least in the nvidia case, it's only a few fixed sizes (powers of 2)
23:04ascent12: It would be possible to atomic-test some different cursor sizes, I suppose. Some more information would be nice, though.