01:05 anholt: after all that, the nir algebraic tests still won't tell me that I got my pattern wrong.
03:06 alyssa: /o\
03:06 alyssa: anholt: UNSUPPORTED or..?
03:11 alyssa: single trace in zink-radv seems to be regressed by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39271
03:12 alyssa: the image change looks like one of my patches breaking rendering, but I'm scratching my head at what and dont have the relevant hw to repro
03:12 alyssa: glehmann: since you're the radv reviewer for that could you take a look? thank you
03:13 alyssa: (I reran the job and it still fails so I don't /think/ it's a flake.)
08:14 glehmann: alyssa: it's a flake, I've seen it in other MRs
08:17 glehmann: yeah, I just retried and it passed
08:17 glehmann: eric_engestrom: is it possible to get information on when this job started flaking?
08:26 pq: sima, I was not thinking of compositors using colorops uAPI wrong. I was thinking of drivers or hardware accidentally claiming they implement a colorop but do something slightly different that is not noticeable without at least a side-by-side comparison.
08:27 pq: Implementing all colorops in VKMS is an obvious requirement to me, but for it to be useful for driver developers, they need to implement CI with comparisons to VKMS. That practically means IGT needs good colorop coverage and support for external picture comparisons.
08:29 MrCooper: when discussing gitlab UI, might want to check if "New UI" is enabled for you in the account menu at the top right
08:29 pq: Validating compositors against VKMS is "just" typing up the tests, it's doable without hardware and important.
08:31 pq: VKMS provides writeback, so compositor testing can be completely automatic.
08:32 pq: If a hardware driver testing relies on eye-balling pictures, that's slow, tedious, unreliable, and probably forgotten. It also requires engineering test pictures that would make errors noticeable, which I think is actually hard.
08:33 MrCooper: comparing between vkms & HW drivers would also require the former to support the same pipelines as the latter, wouldn't it?
08:33 pq: yes
08:35 pq: How else could one test whether a unique pipeline or colorop works correctly if not computing the expected result in some other way as well?
08:36 pq: VKMS might support arbitrary pipelines by implementing all colorops in the wild, and configuring their order in pipelines via configfs.
08:36 valentine: glehmann: looks like it started flaking between 1st and 3rd January: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14588#note_3255525
08:41 glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/compare/7ed6679361f02ea48562652d11281e927ee06fed...07f8729361c4f57564437f4f21d9340e913cab91
08:41 glehmann: I guess that likely makes it a radv regression
08:55 daniels: pq: but then what makes colorops unique in this regard? why not say that no-one can implement any display output at all without hardware checksums to verify it's the right output? or HDMI/DP audio without loopback monitoring?
08:56 daniels: obviously having writeback is super desirable and everyone should, but refusing to allow people to implement their hardware spec because they have to observe bugs irl rather than have it rigorously validated seems like a step too far tbh
08:56 emersion: agreed
08:58 pq: daniels, previously the output hasn't been defined. Colorops are defined in detail.
09:00 pq: daniels, I'm seeking ways to make implementation testing easier for everyone. I did not mean fobidding implementations.
09:01 pq: daniels, this discussion stems from a private discussion, where the said hardware spec is a single ambiguous word for a colorop.
09:03 pq: daniels, also, I don't think yolo'ing before is an excuse to continue yolo'ing if a practical better way can be found.
09:05 emersion: adding new KMS features is already a very tall order
09:05 emersion: we took multiple years adding colorops
09:05 emersion: i don't think adding even more requirements is going to help
09:06 pq: yes, and improving IGT will make it easier
09:06 emersion: it's just more work
09:07 pq: one-off work, the next driver developer then has it ready-made
09:07 pq: Why does IGT exist to begin with?
09:10 daniels: pq: hrm, I read 'should writeback functionality be required ... ?' as quite literally saying that colorop implementations would only be accepted if there was also a wb implementation
09:11 pq: daniels, and I said "ok" to "no, it cannot"
09:13 pq: I'm not sure what you imagine me requiring here. What I have in mind is a) VKMS could be required to have an implementation of all colorops of any driver. b) IGT could be required to exercise every colorop.
09:15 pq: That means that VKMS can be configured to realize any hardware color pipeline and used as the reference. The only thing missing is writeback. Drivers that implement writeback would be testable as-is. Drivers that don't would need framegrabbers and maybe manual testing. The point is the tests would exist, and there would be a way to use them if you can just get a framegrab.
09:17 pq: And none of it would rely on eye-balling, which is susceptible to monitor implementations which are known to vary.
09:26 daniels: pq: sure, sounds perfect to me
09:47 daniels: pq: sorry, I must've missed the intermediate part where that happened; I'm ofc all in favour of all the VKMS coverage we can get, all the IGT coverage we can get, and all the writeback testing we can get :)
11:32 karolherbst: jnoorman: the offset_shift index, is it a shift of the entire address or just the offset? It looks like on the entire address, but the naming is a bit confusing there then.
11:34 karolherbst: the problem is, I need different semantics I _think_... like for nvidia it is: final_address = (offset_src << const_offset_shift) + uniform_base_src + BASE and I'm wondering if I need a new index for this or can reuse the one you've aadded
11:39 karolherbst: but also.. we only can support shifts of 0, 2, 3 and 4.. which is annoying because I might have to rework the lowering to also have a min shift value besides 0
11:41 karolherbst: I assume you mean the BASE index inside "offset = (offset_src + base) << offset_shift"?
11:47 karolherbst: anyway, not having a good idea how to support both definitions... could add a special BASE_NV for nvidia, or could add a special offset_shift_nv..
11:51 karolherbst: well I'll figure this out later after I landed the encoding bits...
13:51 fomys: Hello,
13:51 fomys: I am wondering if the rotation property is special for its default/initial value.
13:51 fomys: I am working to add supported_rotations/default_rotation in VKMS configfs interface, but I strugg le to define the initial/default value for the plane rotation, it always fall back to DRM_MODE_RO TATE_0 even if I pass DRM_MODE_ROTATE_90 as the default and only supported rotation
13:51 fomys: According to the documentation and my printk, the default value is properly passed to drm_objec t_attach_property, but that not what drm_info / modetest / IGT report.
13:51 fomys: This is not a configfs issue, I test with hardcoded value default=supported=DRM_MODE_ROTATE_90 th e values in [1] and the value returned by drm_info/modetest are strange:
13:51 fomys: "rotation": bitmask {rotate-90} = () // no value?
13:51 fomys: 35 rotation:
13:51 fomys: flags: bitmask
13:51 fomys: values: rotate-90=0x2
13:51 fomys: value: 1 // value is 0x1, but it should not as only 0x2 is supported
13:51 fomys: [1]:https://elixir.bootlin.com/linux/v6.18.5/source/drivers/gpu/drm/vkms/vkms_plane.c#L234-L235
13:51 fomys: Is this expected? If yes what is the correct way to set the default rotation for a plane?
13:58 emersion: fomys: drm_plane_create_rotation_property() unconditionally initializes the initial value to 0
13:59 emersion: hm, or does it
14:00 emersion: nah, it sounds fine
14:00 fomys: https://elixir.bootlin.com/linux/v6.18.5/source/drivers/gpu/drm/drm_mode_object.c#L260
14:00 fomys: I have a print right there that shows my DMR_ROTATE_90
14:01 fomys: And I checked, it work well for other properties like COLOR_RANGE/ENCODING (not bitmask)
14:01 fomys: That why I think there is maybe a special behavior for the rotation, but I was not able to find it in the core
14:03 emersion: do you call __drm_atomic_helper_plane_state_reset()?
14:03 emersion: seems not
14:03 fomys: I don't think, I will check
14:05 fomys: It is
14:05 fomys: drm_mode_config_reset(dev); in [1]:https://elixir.bootlin.com/linux/v6.18.5/source/drivers/gpu/drm/vkms/vkms_output.c#L121
14:06 fomys: (that call plane->reset that contains call to __drm_gem_reset_shadow_plane that contains call to __drm_atomic_helper_plane_reset that contains call to __drm_atomic_helper_plane_state_reset)
14:06 fomys: But I will add logging and see what is the value after this reset
14:11 fomys: That where it goes from "no state" to "initial state contains ROTATION_0", I will dig to understand how the "initial plane state" is filled, thanks for the pointer!
14:12 fomys: https://elixir.bootlin.com/linux/v6.18.5/source/drivers/gpu/drm/vkms/vkms_plane.c#L105
14:13 emersion: np!
14:13 fomys: Filled with zero :)
14:13 fomys: ha no, the initialization is forced to ROTATE_0
14:14 fomys: Core is broken
14:14 fomys: https://elixir.bootlin.com/linux/v6.18.5/source/drivers/gpu/drm/drm_atomic_state_helper.c#L252
14:14 fomys: Or maybe that a "legacy" behavior, but at least I know I could be able to change it afterward
14:17 emersion: maybe you could use drm_object_property_get_default_value() to fill the rotation?
14:17 emersion: in that function
14:18 fomys: Yes, I am digging in git log to check if this ROTATE_0 is mandatory for uAPI compatibility, but I don't think so I will switch to get_default_value yes
14:20 emersion: this is "new hardware" anyways
14:20 emersion: and i don't think that reset function is called by all drivers
14:20 fomys: 25aaa3a1e5dba6256fd4a548f088ee1ebbc4b5f8
14:21 fomys: No special comment for this value except "zero is not valid", so I will submit a patch to "fix" this
14:21 fomys: Thanks for your help
18:50 emersion: pq, i think part of the disconnect is that you're a professional and I'm an amateur. I prefer to rely on my community rather than a costly to write and maintain (and unfun) test framework
18:51 emersion: to fix things
18:52 emersion: pq, it also feels (not saying this is the case) like userspace dictating that driver authors do more work, which is easy since they won't have to do the work
18:52 emersion: (this is why I specifically wasn't interested in reviewing the igt colorop patches)
19:50 cwabbott: been seeing this a lot: "There has been an unknown job problem, please contact your system administrator with the job ID to review the logs"
19:50 cwabbott: e.g. with job 91129148
19:55 mareko: FYI new project https://gitlab.freedesktop.org/mesa/gpu-ratemeter
19:56 dcbaker: eric_engestrom: Did I see you moved the 26.0 branchpoint to next week? I was thinking about moving the next 25.3 release by a week as well
20:00 cwabbott: https://gitlab.freedesktop.org/cwabbott0/mesa/-/jobs/91129147
20:08 alyssa: mareko: Oh cool! =D
20:09 alyssa: This looks really good
20:09 alyssa: Lol at using Vulkan as the universal HAL
20:12 alyssa: surprisingly clean code for what it is
20:55 jannau: no luck on the blown up phone GPU G13D. how are uniform memory GPUs supposed to handle VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT? the vk tests fail early because honeycomb has no memory type without DEVICE_LOCAL_BIT
20:59 alyssa: jannau: what test?
21:00 alyssa: oh, gpu-ratemeter I guess
21:00 alyssa: yeah that code'll need a lot of portability fixes, it's currently very AMD-hardcoded
21:01 alyssa: in this case vk_find_heap should be relaxed
21:07 jannau: or gpu-ratemeter should skip tests. doesn't make much sense to benchmark device local to host visible buffer bandwidth if it's the same memory
21:08 robclark: that isn't quite true..
21:08 robclark: since bus scaling
21:10 jannau: the gl.bufbw test is glacially slow. maybe 5 minutes for 5% of progress
21:14 jannau: I was trying to compare bare metal vs. drm native context
21:18 alyssa: oh interesting