00:01 airlied: dolphin: sfr has reported a fail to build in drm-intel-fixes, please make sure it doesn't get to me :-)
00:01 airlied: j4ni: ^
00:01 imirkin: karolherbst: unless you understand that the local array is set once and you could rematerialize just the one value used, not sure how you'd improve
00:01 imirkin: but that's a pretty advanced optimization
00:02 karolherbst: yeah
00:02 karolherbst: but possible in that one shader :p
00:02 karolherbst: that's why it's evil
00:02 karolherbst: as the optimization is just super painful to write
00:06 karolherbst: *sigh*
00:06 karolherbst: this test passes with NV50_PROG_OPTIMIZE=0 of course :(
00:06 karolherbst: I bet it's memoryopt
00:07 karolherbst: yep
00:09 karolherbst: weird...
00:09 karolherbst: makes literally no sense
00:46 imirkin: karolherbst: that test passes for me
00:53 airlied: EXT_shader_group_vote seems like a pretty lowhanging GLES extension
01:06 airlied: turns out it was: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5490
01:39 imirkin: airlied: good to scan over new exts
01:39 imirkin: usually a few in there that are trivial like that
01:39 airlied: imirkin: yeah I only found it, looking at the GLES 3.1 CTS tests I didn't support
01:40 HdkR: Nice
01:40 airlied: GLES CTS is so much more lenient than deqp :-P
01:41 imirkin: airlied: yeah, rendering all black gets you far :)
01:42 imirkin: of course rendering all green gets you far in piglit...
07:26 MrCooper: dj-death: maybe you have duplicate userspace instances corresponding to the same kernel BO?
07:39 dj-death: MrCooper: it seems to be a BO received from another process via dmabuf, imported into the GBM API, exported has a GEM handle (kept around as is, without being put back into a driver object), followed by the destruction of the GBM BO
07:39 dj-death: MrCooper: at this point the exported GEM handle is destroyed
07:40 dj-death: MrCooper: tbf I can't even see how that worked before
07:41 dj-death: I'm somewhat getting tired of this
07:42 MrCooper: I can relate to that, I spent quite a lot of time wrangling with these issues in radeonsi as well
07:43 dj-death: I wished GBM was getting its own table of DRM objects
07:43 dj-death: so that we could isolate the driver from the window system stuff
07:43 dj-death: I don't know how to do that though
07:44 MrCooper: the fundamental problem is that GEM handles aren't reference counted
07:44 dj-death: they should be private things in my opinion
07:44 dj-death: or like I said, give a different table for the driver and the wsi stuff
07:45 dj-death: so that driver handles never leak
07:45 MrCooper: so what is retrieving that GEM handle, for what purpose?
07:46 dj-death: in chromium?
07:46 MrCooper: yeah
07:46 dj-death: it happens when you enable a particular option
07:46 dj-death: --enable-native-gpu-memory-buffers
07:47 dj-death: which shares dmabufs of textures between the tab & gpu processes
07:48 dj-death: the tab process created a buffer, shares it with the GPU process through dmabuf
07:48 dj-death: and it seems the chromium code doing the import doesn't play well with the trick we do in gallium
07:49 dj-death: essentially the GEM handle created out of the dmabuf gets destroyed before it can be used
07:50 MrCooper: so does chromium itself call gbm_bo_get_handle, and then try using the resulting handle after gbm_bo_destroy?
07:51 dj-death: yeah
07:52 MrCooper: that sounds like a chromium bug then
08:05 MrCooper: can't seem to reproduce with radeonsi though
08:09 dolphin: airlied: thanks for letting me know, I did a build-check locally, obviously I'm missing some flag that CI has (as I didn't get CI results either)
08:12 dj-death: MrCooper: probably screwed up somewhere :(
08:13 MrCooper: that chromium code does look suspicious though; the handle returned by gbm_bo_get_handle isn't valid after gbm_bo_destroy
08:24 dj-death: MrCooper: maybe add --ignore-gpu-blacklist
08:25 dj-death: MrCooper: to your testing
08:25 dj-death: maybe --enable-zero-copy too
08:40 MrCooper: dj-death: I tried with all the parameters in the issue
08:40 dj-death: MrCooper: okay
08:40 MrCooper: but maybe it's using a different path with radeonsi
08:41 MrCooper: or, could it be that there's a duplicate representation of the same kernel BO in another screen?
08:46 dj-death: MrCooper: any reference to the buffer would prevent it from being destroyed
08:47 MrCooper: in the same screen, sure
08:47 dj-death: MrCooper: so either there is a bug in iris or in chromium
08:47 dj-death: MrCooper: even in another screen
08:49 MrCooper: if the pipe_resource is de-duplicated in 100% all cases, yes
08:50 dj-death: there must another issue too because on iris chromium ends up leaking FDs
08:51 dj-death: and since it doesn't export FDs from iris, I'm pretty sure it's not iris the source of the leak
09:00 MrCooper: airlied: push topic branches to your personal repo, not the main one :)
09:23 danvet: MrCooper, dj-death do you take into account that if you import the same underlying obj again on the same drmfd, you get back the same gem id?
09:23 danvet: not a new one
09:23 danvet: so if e.g. chromium uses the same fd for its own stuff, then all things will go boom
09:23 MrCooper: radeonsi does, but that's basically what I was asking about iris
09:23 danvet: I haven't seen the entire discussion, just figured this is usually it
09:24 danvet: so you need a table/cache in userspace, per drmfd (across any dup() you do or AF_UNIX fd passing)
09:24 danvet: to check whether the gem id you get back at import is one you have already
09:24 danvet: and if so, do a refcount++ on that userspace tracking obj
09:25 danvet: MrCooper, yeah this was all specifically done for radeonsi so that radeonsi doesn't go boom in cs ioctl when it puts duplicated buffers into the obj list
09:25 MrCooper: anyway, in this case it looks that might only serve as a workaround for a chromium bug (other reference for the BO keeping it alive until it uses the GEM handle)
09:25 danvet: or maybe that was for the older kernel only, not sure
09:26 danvet: MrCooper, yeah but then I wonder why chromium is running on the same drmfd if it wants to manage these buffers on its own
09:26 MrCooper: pretty sure it's still the case
09:38 pq: clever, re: VBI API; I suppose how to structure that also depends on whether the VBI data needs to ne in sync or independent of the actual image contents on each refresh. If you use KMS API for VBI, it's possible that sometimes the same data gets emitted again, when the KMS app "drops" a frame.
09:39 clever: pq: i think the best thing, would be to have some kind of fifo, and the kernel would emit pop a packet off the fifo on every vsync interrupt
09:40 clever: and never repeat a packet
09:40 clever: -emit
09:45 clever: the object in the fifo could either be teletext packets (needing some encoding into graphics) or just full DRM planes
09:46 pq: clever, btw. connector numbering is not guaranteed to be persistent. If you have several DRM devices with same connector types initializing simultaneously, you might get random numbering.
09:47 clever: pq: other then usb, the rpi will never have any other drm devices
09:48 clever: and for most models, there is only 1 of each type, so the type is all you need
09:48 clever: rpi4 has 4 hdmi, but if the driver can just number the 2 ports in the same order every time, it should be fine
09:48 clever: 2 hdmi*
09:50 clever: the compute module also has 2 DSI ports, but those are less likely to be seen in the wild
09:56 pq: clever, such fifo for VBI does not sound like it would fit well with KMS API at least (properties with atomicCommit).
09:57 pq: clever, yeah, rpi probably has no problem, but a generic PC will when someone plug in add-on cards.
10:00 clever: in that situation, i would identify a connector based on: the driver, the type, the index within that driver
10:00 clever: things would only get complicated if you have several instances of the same driver
10:01 clever: but each is isolated to its own node in /dev/dri, right? so you can just card "card 1 DVI port 0"
10:01 clever: the card# may change, but the rest would be fixed
11:02 danvet: tzimmermann, ping for testing my regression fix
11:03 danvet: also need an ack for merging
11:03 clever: which package is kmstest typically found it? i'm not seeing it in apt
11:04 danvet: libdrm, and I think by default it's not built for distros
11:04 tzimmermann: danvet, i did not forget about you.
11:04 clever: danvet: E: Unable to locate package libdrm
11:04 clever: oh, let me look at `libdrm-tests - Testing tools from the libdrm project` ...
11:06 clever: that has some of the binaries, but not all of them
11:07 tzimmermann: danvet, mripard, about backmerging -rc1 into drm-misc-fixes: can i merge directly from linus' tree, or is there some intermediate branch to merge from?
11:10 clever: yep, i can now run modetest, and see 2 connectors, hdmi&composite, dpi/dsi are missing
11:14 airlied: MrCooper: that was a n extra supodr screwup, it was a piglit topic branch
11:15 airlied: i removed it, and got gitlab to housekeep, hopefully undoes it
11:44 danvet: tzimmermann, uh I think one of the rebases went totally wrong :-/
11:44 tzimmermann: danvet, you mean your patch?
11:45 danvet: yeah when I applied it or when I rebased somewhere
11:45 danvet: I didn't realize that we create dumb with private == true
11:45 tzimmermann: danvet, reverting that broken patch fixes all issues for me
11:46 tzimmermann: happens
11:46 tzimmermann: shall i test with private == false?
11:46 danvet: tzimmermann, hold a bit, compile-testing new patch now
11:47 danvet: I think just looking at the diff it's obvious what went wrong
11:47 danvet: https://paste.debian.net/1152327/
11:47 tzimmermann: ok. i think you still need the current fix for the buffers that are actually private
11:47 danvet: very classic case of misapplied hunk :-(
11:47 danvet: hm
11:47 danvet: right
11:48 danvet: I guess we need both?
11:48 tzimmermann: yeah, i think so.
11:48 danvet: tzimmermann, can you pls test both together and then r-b?
11:48 danvet:crosses finger there's no more stupid prices to collect here
11:48 tzimmermann: this pastebin looks correct
11:49 danvet: tbh I don't quite trust my sense for "correct" anymore right now
11:49 danvet: not on this
11:52 tzimmermann: same here. i write long patch series with trivial refactoring, because i don't trust myself to get more complicated patchs right. and still the patch series have bugs. see the recent mgag200 series
11:52 tzimmermann: danvet, shall i take the pastebin or will you send a patch?
11:53 tzimmermann: just saw it
11:54 danvet: tzimmermann, btw, should I merge "drm/ast: Use managed pci functions"?
11:54 tzimmermann: danvet sure
11:54 danvet: ok, doing that now
11:55 tzimmermann: i have to rebase my recent ast patches anyway
12:05 tzimmermann: danvet, works now :)
12:07 danvet: tzimmermann, \o/
12:21 clever: [ 43.704424] Unable to handle kernel NULL pointer dereference at virtual address 00000044
12:21 clever: [ 44.006410] [<7f2deb60>] (drm_print_regset32 [drm]) from [<7f391f68>] (vc4_hdmi_debugfs_regs+0x88/0xa8 [vc4])
12:57 tzimmermann: linusw, mripard, mlankhorst_, i merged v5.8-rc1 into drm-misc-fixes
12:58 tzimmermann: also test-built it for x86-64, aarch64 and arm
13:20 karolherbst: any other driver having to deal with explicit convergency opcodes
13:20 karolherbst: wondering if it makes sense to add something like this to nir
13:21 karolherbst: like on nv hw we have opcodes to push a sync target and sync all threads on that
13:35 mlankhorst_: tzimmermann: yeah guess its time for me to send out first pull req :)
13:37 tzimmermann: mlankhorst_, if i counted correctly, you now take over drm-misc-next ?
13:40 mlankhorst_: yes
13:48 pq: clever, never assume you cannot have several instance of the same driver. AMD CPU with IGP and a AMD add-on card... ;-)
13:49 pq: clever, yes, so if you identify device instance, then connector *index* should be good except for MST. Mind that connector number is a different thing.
13:50 imirkin: ... and even if you're intel, never assume your gpu device won't be passed into an emulated ppc be host
13:50 imirkin: ;)
13:50 pq: no-one has actually specced any of that to be persistent though, they just happend to be by accident
13:52 pq: My home machine has two AMD cards, IGP and discrete. No, I didn't disable the IGP one, I tried and some driver screamed at me.
13:55 emersion: IGP?
13:56 emersion: smae as iGPU?
13:56 emersion: same*
13:56 imirkin: integrated graphics processor
13:56 emersion: okay, same as iGPU, thx
13:56 imirkin: not sure what iGPU is precisely
13:56 emersion: is IGP more correct than iGPU?
13:57 emersion: integrated GPU
13:57 imirkin: in days of yore, nvidia made IGP's to go on motherboards with intel cpu's
13:57 imirkin: (as did AMD as i recall ... powerxpress or whatever ... but only with AMD cpu's i imagine. but it was completely separate)
14:32 karolherbst: is there a pass to get rid of dead input/output components in nir? not that it matters (I think?).. just wondering
14:52 kallisti5: airlied: I know :-) In the past we had a lot of issues porting it though due to the X11 requirements. Now that it's compiling, we have a nice wedge in the "massive undertaking"
14:53 kallisti5: "kernel side vs mesa side"
14:54 kallisti5: (a lot of issues == we/I wasn't prepared to make major modifications to libdrm to disable X11) Trying to keep our code paths small since my understanding of the whole pipeline across multiple operating systems is weak
17:09 jekstrand: airlied: Did we ever land your patches to add vec8/16 support to the Intel back-end?
17:30 DPA: Hi.
17:30 DPA: I'm trying to export a bo created with gbm_bo_create_with_modifiers from etnaviv using prime, and import it in mxsfb.
17:30 DPA: But it seams to fail in the kernel in drm_gem_cma_prime_import_sg_table.
17:30 DPA: I have tried this using this small example program: https://dpa.li/gbm_export_import_test.c
17:30 DPA: What can I do about that?
17:33 emersion: you're trying to create it with zero modifiers -- that means implicit modifier
17:34 emersion: the driver will choose a modifier, but maybe it's not supported by the target device?
17:34 emersion: you could try with DRM_FORMAT_MOD_LINEAR, which is supported by everyone
17:34 emersion: make sure the target device supports the format
17:35 emersion: … should be the case for GBM_FORMAT_ARGB8888 i guess
17:35 DPA: Okay, I'll try.
17:36 emersion: do you understand why it's failing in drm_gem_cma_prime_import_sg_table?
17:39 DPA: I think it's trying to check if the memory is continous, and that doesn't seam to be the case.
17:40 emersion: eh, rip
17:40 emersion: you can check with https://github.com/ascent12/drm_info which modifiers are supported for scanout by the target device
17:41 emersion: choosing a format/modifier that can be scanned out may help
17:41 emersion: if it doesn't, then you'll need to wait for the unix allocator…
17:42 emersion: or s/wait/drive the effort/ :P
17:43 DPA: Thanks. DRM_FORMAT_MOD_LINEAR doesn't seam to have changed anything. I'll check which modifiers are supported next.
17:44 anarsoul: DPA: don't do that
17:45 anarsoul: GPUs usually have an MMU so their BOs are not physically continious
17:45 anarsoul: while display controllers don't have MMU, so they expect BOs to be physically continious
17:56 DPA: anarsoul: I have a display panel and a hdmi connector, with different dri devices. I'm trying to implement support for multiple kms devices for the same xscreen in xorg. Xorg uses the same bo for all framebuffers of all crtcs. I'm trying to keep that as is, so the most logical thing to create the BOs with is the gpu. Besides, I think Xorg already does that in some situation if it offloads rendering to a gpu using prime.
17:57 danvet: pinchartl, finally gotten around to respinning this one here: https://lore.kernel.org/dri-devel/20200612160056.2082681-1-daniel.vetter@ffwll.ch/
17:57 danvet: I think I butchered enough times by now that maybe also testing would be good, not just review :-)
17:58 pinchartl: danvet: sure. what bothers me was that I tested your previous version, and saw no regression
17:58 pinchartl: I think I mentioned that in a reply
17:58 pinchartl: there should have been a regression, right ?
17:58 danvet: yeah that's bothersome
17:58 danvet: well ...
17:59 danvet: only if you a) boot up without fbcon enabling stuff and b) try to do a vblank wait before you enable the crtc yourself
17:59 danvet: I don't think we have any tests for this
17:59 danvet: generally everyone is non-silly and enables the crtc first before trying to use it :-)
17:59 danvet: also, as soon as you enabled it once it's all good
17:59 danvet: and vblank is correctly rejected after that
18:00 danvet: it's only the undefined initial boot-up state that goes boom
18:00 pinchartl: I've added the manual vblank off call in the driver because it wouldn't work otherwise. has there been changes in the vblank handling that reduced the scope of potential breakages ?
18:00 anarsoul: DPA: create a dumb BO via display card if you're planning to use it for scanout
18:00 danvet: pinchartl, I don't think so
18:00 danvet: afair the only case is the the time from boot-up until first crtc on
18:00 danvet: on said crtc
18:00 pinchartl: then I really wonder what changes
18:01 pinchartl: changed
18:01 danvet: maybe we changed atomic code a bit to more carefully check whether it should vblank wait or not
18:01 pinchartl: but I don't have time to investigate now I'm afraid
18:01 pinchartl: I can test your patch of course
18:01 danvet: pinchartl, did you test with rcar?
18:01 pinchartl: I've tested the previous version with rcar, yes
18:01 pinchartl: I'll test the new one
18:02 danvet: pinchartl, found it
18:02 danvet: https://paste.debian.net/1152379/ <- before this patch you get the vblank while stuff is off
18:02 danvet: and boom on first modeset
18:02 danvet: so if you revert that I think the previous version should go boom
18:03 pinchartl: ok
18:04 DPA: anarsoul: I have more than one of them where I want to use the same buffer with. I could just use the first one, but it kind of feels like a hack.
18:07 anarsoul: well, fix the hardware :)
18:08 DPA: lol
18:09 anarsoul: I'm not sure if there's contiguous modifier, but I guess if there's not you can introduce it and patch etnaviv do respect it
18:09 emersion: nope
18:09 emersion: modifiers aren't for placement restrictions
18:09 emersion: for these, something new is needed
18:12 onox: are functions part of EGL 1.5, but not 1.4, allowed to be symbols in libEGL.1.0.0 instead of only via eglGetProcAddress?
18:14 onox: apparently I can use eglGetPlatformDisplay, even though eglinfo prints 1.4 and no EGL_KHR_platform_base
18:15 airlied: jekstrand: yes i think they all landed, it was mostly 4 to MAXchanges
18:16 jekstrand: Yeah
18:17 jekstrand: I'm considering adding an instruction which returns a vec16; hence the question. :)
18:18 airlied: should rebase shamrock and land it
18:18 jekstrand: No comment. :-P
18:25 linkmauve: onox, yes, but you should first check for the presence of the EGL_KHR_platform_* extension relevant to your platform.
18:26 linkmauve: The presence of this extension indicates that the driver provides EGL 1.5.
18:28 onox: so my app could successfully link with a libEGL.so containing eglGetPlatformDisplay, but if the extension isn't present, then I'm not allowed to call it?
18:29 linkmauve: Oh sorry I misread, until recently Mesa didn’t expose EGL_KHR_platform_*, instead it only supported the EXT version of them.
18:30 linkmauve: There is also no EGL_KHR_platform_base, since it is part of 1.5, but there is an EGL_EXT_platform_base for older EGL versions.
18:31 karolherbst: somebody willing looking over the radeonsi nir patch in this MR? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5480
18:32 karolherbst: "glsl_to_nir: fixup image_atomic_inc_wrap to fit hw needs as done for TGSI "
18:34 imirkin: karolherbst: do you also need to fix intel? or does it not support whatever ext that comes in with?
18:34 karolherbst: imirkin: ac_nir_to_llvm seems to be the only user of that instruction
18:34 imirkin: hm yeah
18:35 karolherbst: it's part of EXT_shader_image_load_store
18:36 imirkin: ah ok
18:36 imirkin: i kinda assume intel has that op, but no one implemented? i guess i dunno
18:37 karolherbst: get's enabled through "PIPE_CAP_TGSI_ATOMINC_WRAP"...
18:37 karolherbst: maybe we should rename this cap...
18:37 onox: linkmauve: I've mesa 20.1.1 here and it exposes KHR_platform_*, but it's still EGL 1.4
18:37 karolherbst: but yeah.. only radeonsi enabled it
18:38 karolherbst: well.. and nouveau
18:40 linkmauve: onox, hmm, I wonder what’s missing.
18:40 imirkin: karolherbst: iirc it's the only thing that that EXT_whatever requires
18:40 imirkin: on top of images
18:40 imirkin: "regular" images :)
18:41 karolherbst: yeah... seems that way
18:42 karolherbst: and I assume there is a good reason it's not part of the arb spec :p
18:42 linkmauve: onox, I’m also on 20.1.1 and I have EGL 1.5 with both radeonsi and iris.
18:42 karolherbst: maybe intel doens't support it :D
18:42 imirkin: maybe
18:42 imirkin: or maybe "oops, forgot!"
18:42 karolherbst: would be good to know though if this workaround is AMD and NV specific or if all hw implement it like this
18:43 imirkin: a bit silly that both their hw implements it one way, and if they're the only vendors to support it, that the glsl spec reads the other way
18:49 onox: linkmauve: is checking for KHR_platform_* the only way to determine if EGL is 1.5 without creating a display?
18:52 linkmauve: I’m not very confident in that, but I’d say it doesn’t matter, you will only use the client extensions to create a display anyway.
18:52 linkmauve: That and picking a device.
19:01 karolherbst: imirkin: funny enough that nv wrote the spec :p
19:07 linkmauve: Speaking of devices, I’m not sure I understand EGL_EXT_platform_device.
19:07 linkmauve: Why is it a platform like wayland or gbm?
19:09 linkmauve: Say I have two GPUs in my computer, AIUI EGL_EXT_device_enumeration is meant to enumerate them, then EGL_EXT_device_query lets me query stuff about them (nothing defined for now AFAICS), then I pick the one I want, all is good.
19:09 onox: I think it's used by nvidia
19:09 linkmauve: But then I can’t choose whether I use wayland or gbm, can I?
19:09 linkmauve: onox, Mesa also exposes them.
19:09 linkmauve: xexaxo1, maybe you know?
19:11 xexaxo1: linkmauve: platform_device is essentially the same as platform_surfaceless + "device selection"
19:11 xexaxo1: it's on my todo list for next week to update the explicit platform extension. one which allows you to select platform (say wayland) + device
19:12 onox: xexaxo1: which extension is that? :O
19:12 linkmauve: Awesome!
19:12 linkmauve: xexaxo1, btw I now have three GPUs in my new desktop. :)
19:12 linkmauve: One from each main vendor. :)
19:13 xexaxo1: onox: the original proposal https://github.com/KhronosGroup/EGL-Registry/pull/23
19:13 linkmauve: One of which is nigh unusable due to how slow the stock clocks are, another which crashes.
19:13 xexaxo1: linkmauve: put another GPU in there ;_P
19:13 linkmauve: But the crashy one is awesome when it doesn’t do that, fast and everything!
19:14 linkmauve: xexaxo1, I’m gonna run out of space on the MB though. :p
19:14 linkmauve: Out of slots.
19:14 onox: linkmauve: the slow one is nouveau, the crashy one is AMD?
19:15 linkmauve: onox, correct.
19:16 linkmauve: The working one in the middle is Intel.
19:16 xexaxo1: linkmauve: grab an external USB-C/Thunderbolt GPU's next?
19:16 linkmauve: xexaxo1, oh, I also have one or two slots for those!
19:19 xexaxo1: onox: I have some notes on the whole to EGL 1.5 or not topic
19:21 xexaxo1: onox: check out the comment in https://gitlab.freedesktop.org/xorg/xserver/-/commit/7fc96fb02dade4a86f2fc038f3cf5f2d9c0cda00
19:23 linkmauve: xexaxo1, oh uh, doesn’t this comment directly conflicts with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5052 ?
19:24 xexaxo1: linkmauve: your MR seems iffy.
19:24 xexaxo1: linkmauve: especially since Mesa does not do EGL 1.5
19:24 linkmauve: Feel free to revert.
19:24 linkmauve: xexaxo1, well, eglinfo reports 1.5 right now.
19:25 xexaxo1: linkmauve: it can report 1.5 on some platforms and in some cases... altough not consistently.
19:25 linkmauve: On all platforms.
19:25 linkmauve: Oh?
19:25 xexaxo1: does it, strange - it didn't last time I've checked.
19:25 xexaxo1:looks through the log
19:28 linkmauve: xexaxo1, maybe because of glvnd vs. no glvnd?
19:30 xexaxo1: KHR_cl_event2 got enabled at some point. originally it was advertised and then disabled since it's not implemented
19:32 linkmauve: Maybe it depends on whether I have an OpenCL implementation installed or not then?
19:35 xexaxo1: I stand corrected - gallium only was wired. no classic drivers are.
19:36 xexaxo1: for the gallium drivers, we depend on finding the "opencl_dri_" API exposed at runtime (by any DSO)
19:36 xexaxo1: if it's not found - all the relevant EGL API fails (understandably)
19:39 xexaxo1: fwiw clover does expose the API and I would imagine the AMDGPU PRO stack as well.
19:40 xexaxo1: that said, would suggest reverting the KHR_platform MR and using something like the earlier suggestion.
19:40 xexaxo1: not a huge deal either way though.
19:42 linkmauve: xexaxo1, so your suggestion is to never ever expose 1.5 and these extensions? Instead of checking if we can do the rest of 1.5 and then decide whether or not to expose these extensions based on the result?
19:43 xexaxo1: all the classic drivers including i965 and egl/haiku don't do 1.5 so, exposting the KHR extensions is incorrect.
19:44 linkmauve: What is missing in Haiku btw? I have it installed I could check.
19:44 xexaxo1: the API should work never the less.
19:46 xexaxo1: both are missing the cl interop. haiku is not even 1.4 IIRC (even tought it lies)
19:47 xexaxo1: drivers/haiku/egl_haiku.cpp is only 237 lines of code.
19:52 xexaxo1: linkmauve: if you're interested can you at least fixup eglGetProcAddress
19:53 linkmauve: What is the issue with it?
19:53 linkmauve: Maybe it’d be safer to first revert it though.
19:53 linkmauve: I should have ping’d you. :/
19:55 linkmauve: AMD people, is there any benefit to the vdpau gallium state tracker now that there is a vaapi one?
19:58 onox: xexaxo1: what's preventing i965 from doing 1.5? just KHR_cl_event2?
19:59 xexaxo1: linkmauve: last time I've tried vaapi was hit and miss with nouveau, while vdpau was just fine
19:59 xexaxo1: onox: from a _very_ quick look - yes.
20:00 xexaxo1: linkmauve: just look at the haiku file... but prepare some bleach.
20:35 agd5f_: linkmauve, depends on what API your application uses.
20:35 agd5f_: as to whether you want to use VAAPI or VDPAU
20:36 linkmauve: agd5f_, let’s say it can use either (I will mostly use mpv and ffmpeg for video).
22:23 karolherbst: imirkin: funny enough that nv wrote the spec :p
22:23 karolherbst: ...
22:23 karolherbst: sorry
22:23 karolherbst: wanted to say that some atomic counter tests are failing now :/
22:24 imirkin: it's a common typo
22:24 karolherbst: :p
23:29 karolherbst: robclark, jekstrand 167fa2887f0928042dcb21bbc2fa89ae9a29897d breaks is_helper_invocation
23:29 karolherbst: or wel..
23:29 karolherbst: shows an error maybe?
23:29 karolherbst: dunno
23:29 karolherbst: validation fails
23:31 robclark: karolherbst: from the output of nir_validate you should be able to see which intrinisc and which pass needs fixing
23:31 karolherbst: is_helper_invocation ;
23:31 karolherbst: and that's before any passes
23:31 karolherbst: straight out of glsl_to_nir
23:31 robclark: hmm, ok..
23:32 karolherbst: "NIR validation failed after glsl to nir, before function inline"
23:32 robclark: I guess that is a thing not covered in gitlab or intel CI
23:32 robclark: let me have a quick look
23:32 karolherbst: yeah.. could be piglit only
23:32 karolherbst: robclark: tests/spec/ext_demote_to_helper_invocation/execution/demote_with_derivatives.shader_test
23:34 robclark: karolherbst: this should fix it:
23:34 robclark: https://www.irccloud.com/pastebin/YlmUewzC/
23:35 robclark: it isn't a vectorized intrisic, it shouldn't set `num_components`
23:35 karolherbst: okay
23:36 karolherbst: yeah.. the validation error is gone
23:36 karolherbst: the test still fails on intel and nouveau.. but yeah.. no idea about why :)
23:37 robclark: it's possible that the backend was using `intr->num_components` instead of `nir_intrinsic_dest_components()`
23:37 airlied: did the test fail before?
23:37 robclark: (at least that is the error that the stricter nir_validation is meant to catch
23:37 robclark: )
23:38 robclark: I'd assume intel does some nir_serialize testing in CI, so they probably would have caught that sort of error? But maybe it is a thing that hasn't been tested on nouveau?
23:40 karolherbst: it did fail before
23:40 karolherbst: and it does pass with TGSI
23:41 karolherbst: the other demote tests are passing.. so I think there is just something slightly off here
23:41 karolherbst: maybe uses_demote isn't set...
23:41 karolherbst: ehh. no, should be set
23:45 imirkin: karolherbst: is_helper_invocation is the inverse of the natural way one might implement it
23:45 imirkin: basically i think all 3 people who added original gl_HelperInvocation support originally got it backwards.
23:45 imirkin: you might be a fourth! :)
23:46 karolherbst: maybe
23:46 karolherbst: :D
23:53 karolherbst: imirkin: heh.. I just emit a THREAD_KILL:0 sv...
23:53 karolherbst: ... kind of looks like what happens with TGSI
23:57 imirkin: hm ok
23:57 imirkin: yeah, sounds right
23:57 karolherbst: mhhh.. the emited code is also quite similiar..
23:58 karolherbst: imirkin: do we have to converge threads before doing quadops or something?
23:59 karolherbst: ehh.. wait
23:59 karolherbst: ohh no.. that shouldn't matter