06:58lewphole: I read on the gallium compute site that r600g is supported. I have a radeon mobility hd 3200 aka RS780M and would like to run a python program that I got from GitHub that requires opencl. The fglrx drivers support version 1.2 of opencl for my card but I can't get the fglrx module to load into the kernel. Would the radeon driver allow me to use opencl on my card? I saw the examples about passing the r600 flag to llvm but
06:58lewphole: don't know enough about llvm and opencl to know how to go from that to being able to run a python program that uses opencl.
08:39bbrezillon: narmstrong, pinchartl, danvet: if you're okay, I'd like to apply the first 6 patches of https://patchwork.freedesktop.org/series/64915/
08:40danvet: not sure why you need my ack on this?
08:40bbrezillon: intel CI and 0day are happy, I just need R-bs on patch 3 and 4
08:40danvet: was this the one that originally broke the build, because it wasn't following the atomic helper pattern to a T?
08:41bbrezillon: danvet: well, not your necessarily your ack, but since you mentioned the bad helper/core-bridge split on the last version
08:41bbrezillon: would be great if you could have a look at patch 1 at least
08:41bbrezillon: danvet: yes, that's the one
08:43danvet: bbrezillon, hm why the ->atomic_reset in bridge_attach?
08:43danvet: from a quick (pre-coffee) scroll that's the only one that looks inconsistent with how it's done for all the other atomic things
08:44bbrezillon: danvet: where should it be?
08:45danvet: the placement of that itself in the core code is a historical accident
08:46danvet: this was a case of "hey I can use this unchanged" when I typed og atomic, never cleaned it up
08:46danvet: I guess 100% ocd would also just call it ->reset
08:53bbrezillon: danvet: I guess I should also change the prototype
08:56danvet: bbrezillon, yeah maybe for consistency
08:56danvet: it's kinda awkward that we still have that void there
08:57danvet: bbrezillon, btw in add_bridges maybe check for ->atomic_duplicate_state instead of ->atomic_reset
08:59bbrezillon: danvet: ack
09:19bbrezillon: danvet: drm_atomic_private_obj_init() is called in drm_atomic_helper_bridge_reset() right now, but I'm not sure where _fini() should be called
09:24bbrezillon: well, drm_atomic_private_obj_fini() is currently called unconditionally in the bridge detach path, but that's wrong
09:29Venemo: daniels: you asked me to tell you if I see another arm64 failure, so here it goes: https://gitlab.freedesktop.org/Venemo/mesa/-/jobs/1468449
09:32bbrezillon: danvet: or I can call drm_atomic_private_obj_init() with a NULL state in bridge_attach(), leave the drm_atomic_private_obj_fini() in bridge_detach(), and let drm_mode_config_reset() set a non-NULL bridge state (if the ->reset() implementation does so). Would that be acceptable?
09:35danvet: bbrezillon, hm
09:40bbrezillon: danvet: the problem with the private obj API is that it assumes we have the initial state at init time, which is not the case if ->reset() is called from drm_mode_config_reset()
09:41danvet: yeah ...
09:41danvet: bbrezillon, I guess your current code is ok then
09:41danvet: maybe mention that this doesn't quite work like other ->reset hooks
09:42benjiG: airlied: hello, could you have a look at this thread ? https://lists.freedesktop.org/archives/dri-devel/2020-January/253049.html?_sm_au_=irW3202JjNH4q1SrcLpsvK618Vf61
09:42benjiG: I done know what to do with crc4 in dp topology, thanks
09:42daniels: anholt, robclark: looks like more a6xx flake? see Venemo's link above
09:43bbrezillon: danvet: hm, okay
09:43bbrezillon: should I still rename the function?
09:44danvet: nah, since it's not an exact match I guess we can keep things as-is
09:45bbrezillon: ok, still need to make the _fini() call conditional on the presence of ->atomic_duplicate_state() in drm_bridge_detach(), otherwise we have a NULL pointer dereference
09:48danvet: bbrezillon, wrt ini/fini I think attach/detach are about the most reasonable places
10:16bbrezillon: danvet: https://github.com/bbrezillon/linux-0day/commit/d02fbb9e9ba091545bd0cfa6eb9940599f2f8969
10:16danvet: bbrezillon, a-b: me
10:17bbrezillon: danvet: thanks
10:33bbrezillon: pH5: can you have a look at https://patchwork.freedesktop.org/patch/350213/?series=64915&rev=10 when you find some time?
11:44tjaalton: dcbaker: hi, are you still managing 19.3.x or focusing on 20.0 now?
12:57pH5: bbrezillon: ok
12:59bbrezillon: pH5: thanks
14:32kisak: tjaalton: dcbaker is scheduled to handle both right now based on https://www.mesa3d.org/release-calendar.html , also looked like there was some QC issues with staging/19.3, so 19.3.3 was delayed until it was investigated
14:33tjaalton: kisak: ah, ok
15:42robclark: Venemo, daniels, yeah very occasionally something will flake twice in a row, it seems (which gets counted as a fail)
15:42Venemo: robclark :(
16:20bl4ckb0ne: is there an extension for GL_DEPTH_STENCIL_ATTACHMENT on gles2?
16:29imirkin_: i would have imagined that'd be supported in gles2
16:30imirkin_: but my imagination would have been wrong, it seems
16:32imirkin_: bl4ckb0ne: GL_OES_packed_depth_stencil
16:32imirkin_: ah wait, no. still separate.
16:32bl4ckb0ne: or could I emulate it with 2 renderbuffers ?
16:33imirkin_: you can attach the same depth/stencil buffer
16:33imirkin_: to both attachment points
16:33bl4ckb0ne: https://www.khronos.org/registry/OpenGL-Refpages/es2.0/ depth16 and stencil8
16:33imirkin_: those are incompatible.
16:33imirkin_: depth24 + stencil8
16:33bl4ckb0ne: also is the renderbuffer a requirement for the framebuffer ?
16:33bl4ckb0ne: ah yeah it doesnt add up
16:33imirkin_: no, you can attach textures with glFramebufferTexture
16:34imirkin_: see sample code in https://www.khronos.org/registry/OpenGL/extensions/OES/OES_packed_depth_stencil.txt
16:34bl4ckb0ne: just a texture and nothing else?
16:35imirkin_: well, the call takes like 30 argumens
16:37bl4ckb0ne: what I mean is can a framebuffer be complete with only a color attachment
16:37imirkin_: of course
16:38imirkin_: a framebuffer can even be complete with *no* attachments ... https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_framebuffer_no_attachments.txt
16:38imirkin_: [that functionality is core in ES 3.1 as well.]
16:39bl4ckb0ne: ah well i must've made a mistake
16:39imirkin_: not everything is necessarily compatible though
16:39imirkin_: e.g. you can't have depth16 + stencil8
16:39imirkin_: in most drivers
16:39imirkin_: maybe it'd get upgraded to depth24? not sure
16:40bl4ckb0ne: im just rendering a triangle for now
16:40imirkin_: reaching for the stars...
18:20danvet: bbrezillon, patchwork tends to be fairly lossy unfortunately
18:35kisak: anholt: all of sagarghuge's pull requests are failing on lima/panfrost tests and the pipeline results aren't public, so I guess there's some account config issue still going on there that's blocking all his pull requests
18:35lewphole: anyone know anything about the state of opencl support in gallium compute for r600 cards?
18:35kisak: anyone in particular to give a friendly nudge to start a conversation on that?
18:38kisak: referring to https://gitlab.freedesktop.org/sagarghuge/mesa/pipelines/101385 / https://gitlab.freedesktop.org/sagarghuge/mesa/pipelines/101405
18:40Kayden: sagar_: ^
18:40imirkin_: lewphole: afaik there's some basic support, but various bits are missing
18:43sagar_: I had CI pipeline disabled previously, now I enabled it, but Not sure what's going on with MR. :(
18:46notafile: has there been any work or intent to work on a connector backlight property?
18:47kisak: sagar_: Hi, didn't know you hang out on irc. I was guessing that a gitlab admin could compare the account settings to one that's behaving. something about your account also causes "Could not retrieve the pipeline status. For troubleshooting steps, read the documentation." on merge requests
18:47imirkin_: notafile: it gets brought up from time to time, not sure of a current actual plan
18:48notafile: I assume there is a blocker for it then, imirkin_? Or is it just a case of it not being critical enough.
18:49imirkin_: you should try to find the old discussions, but my recollection is that the conclusion was along the lines of "we should not do this"
18:49sagar_: kisak: okay.
18:50imirkin_: probably something about it not fitting into atomic. but my recollection is rather hazy.
18:51notafile: I'll try to see what I can find. I assume it's on the mailing list? I'm not very good with those, I'm post mailing-list generation...
18:51imirkin_: yes, almost certainly on ML
18:51imirkin_: conveniently they are archived online
18:52imirkin_: and there are fancy tools called "search engines" which can help you find things
18:52lewphole: imirkin_, would it be possible to run a python script that requires a gpu with opencl support using gallium compute? im confused on the relationship between gallium compute / radeon driver / amdgpu driver / amdgpu pro driver / opencl libraries..
18:52lewphole: i have a radeon mobility hd 3200 aka rs780m
18:52airlied: sagar_: for some reason you have CI/CD disabled or something on your mesa project
18:53imirkin_: lewphole: depends what it wants. does rs780 even have compute shaders? i don't know that it does...
18:53imirkin_: i think compute support, at least in mesa, is evergreen+
18:54imirkin_: airlied can probably correct me.
18:54airlied: yeah compute is evergreen+
18:54airlied: opencl 1.0 was "possible" on r700 in theory, using vertex shdaers
18:55airlied: but nobody has ever implemented it in open source afaik
18:59sagar_: airlied: I enabled CI/CD pipeline, I might be missing some options (only lima/panfrost tests are failing to run in pipeline, rest of them passes) Failed job: https://gitlab.freedesktop.org/sagarghuge/mesa/pipelines/101910/failures
19:00airlied: sagar_: when I look at your mesa project in gitlab I'd expect to see a CI/CD option on the left and I don't
19:01airlied: I see one for other people's personal forks
19:01lewphole: hmm i see. so my only option would be to get the fglrx driver working? supposedly it has opencl 1.2 support for my card
19:02airlied: lewphole: it doesn't
19:02airlied: I don't think opencl1.2 is possible on rs780
19:06sagar_: airlied: weird, I see CI/CD option :( https://imgur.com/a/NjL9fWY
19:06notafile: imirkin_: yeah you remembered correctly. DRM properties are cached and can not read the status of the driver. This is because there is no callback to return non-atomic properties.
19:07notafile: sounds like it's the end of the road for me then, that seems far beyond my current knowledge. Unless I want to spend like two months learning the depths of dri. Shame.
19:08emersion: notafile: link?
19:08notafile: emersion: https://lists.freedesktop.org/archives/dri-devel/2016-October/121886.html
19:08imirkin_: there's a semi-weird exception for link-status
19:08imirkin_: which can randomly go false (with an appropriate userspace notification)
19:10emersion: would it be a big deal to make it an atomic prop?
19:13airlied: notafile: use something like pocl
19:14airlied: to do opencl on your cpu
19:14emersion: lewphole: ^ probably for you
19:16anholt_: just moved the fd-farm nuc out of our docker setup. this hopefully didn't interrupt any pipelines, apologies if it did.
19:20mattst88: can someone interpret the CI failure in https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3376 ?
19:20gitbot: Mesa issue (Merge request) 3376 in mesa "intel/compiler: Clear accumulator register before EOT (Gen12 WA)" [Intel-Fs, Intel-Vec4, Opened]
19:21mattst88: the pipelines on arm are failing, but the commit is only touching i965
19:21mattst88: and I get 404s when I try to download the artifacts (I assume there are none)
19:21mattst88: I can't spot where to find the CI logs
19:24airlied: mattst88: see above
19:24mattst88: ah, okay
19:24airlied: something wrong with sagar_ setup
19:28kisak: sagar_: whatever adjustment you just made, individual CI jobs are now publically viewable
19:29sagar_: kisak: there is a option called "Public pipelines", I just enabled it.
19:32mattst88: sagar_: looks like it's now running some more jobs, so hopefully problem solved?
19:33sagar_: mattst88: I ran those manually, just to check if it's working or not.
19:34lewphole: emersion, sorry, were you referring to airlied's message about pocl?
19:34mattst88: maybe just try assigning to margebot now that it's able to run on those platforms?
19:34emersion: lewphole: yes
19:34kisak: margebot is already assigned, and hasn't rejected the current set
19:34lewphole: i was looking my card up online and wikipedia says it supports "close to metal" or "ati stream" only
19:35lewphole: terascale 1
19:36lewphole: ill check pocl out though, thanks
19:44kisak: oh oops, my last comment was based on an out-of-date page
19:45kisak: (hitting back sometimes shows old content in gitlab)
19:46sagar_: airlied: kisak: mattst88 jobs are passing now \o/
20:49mattst88: sagar_: yay!
21:40Lyude: we need to go through some of the DP workarounds in amd's dc at some point and move them into drm
21:40Lyude: (just putting that out there in case anyone is bored :)
21:42imirkin_: airlied: i actually pushed that piglit patch quite a while ago :)
21:42imirkin_: Jan 12, according to the records.
22:11anholt_: wait, does LAVA really not have a way to get files back from the test run?
23:52tarceri: Is there any documentation on how to setup piglit to run the GL 4.6 spriv tests? can't seem to find anything