00:17 imirkin: airlied: huh? ivb should expose ARB_compute_shader, no?
00:17 imirkin: airlied: https://people.freedesktop.org/~imirkin/glxinfo/
00:18 imirkin: just missing ARB_stencil_texturing for GL 4.3 (at least in mesa 17.2 :) )
00:18 airlied: imirkin: oh I thought it was compute shader that stopped 4.3
00:19 airlied: oh myabe simd32 fixed it
00:19 imirkin: yeah
00:19 imirkin: for ivb and haswell, iirc
00:19 imirkin: (or maybe it's the other way around, and it was needed for gen8+? who knows)
00:28 jekstrand: airlied: That shouldn't be.
00:28 jekstrand: We need SIMD32 on IVB, for sure.
00:29 jekstrand: Otherwise, we can't hit the desktop compute limits
00:29 airlied: jekstrand: yeah I think I was thinking olden days
00:29 airlied: jekstrand: as for overallocating buffers, CTS and UE4 both have bugs in them so far
00:30 jekstrand: what do you mean by over-allocating?
00:30 airlied: returning larger memeory requirements than requested size
00:30 jekstrand: Oh, yeah, that'll trip up apps
00:31 jekstrand: I think we might align up to 64B or something but that's it.
00:35 jljusten: I think the ivb could hit the 1024 limit without simd32. bdw and byt did need it though.
00:35 jekstrand: You could be right. I don't remember where everything landed there.
02:58 HdkR: Someone in a different channel was talking about PLS and I'm actually surprised that it isn't implemented in Mesa yet. Considering there's at least 3 pieces of hardware that can support it at this point
03:00 airlied: HdkR: pixel local storage?
03:00 HdkR: Correct
03:00 airlied: is there a spec for it?
03:01 airlied: ah found it
03:01 airlied: https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_shader_pixel_local_storage.txt
03:01 HdkR: Also https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_shader_pixel_local_storage2.txt
03:24 airlied: jekstrand, bnieuwenhuizen : just read that waiting on events on the device to be signaled by the host is illegal, might make something simpler for vallium :-P
03:25 jekstrand: airlied: Yeah... There are CTS tests which totally do that.
03:25 jekstrand: So be careful
03:26 airlied: I only noticed because the CTS tests got reverted
03:26 jekstrand: Oh, really?
03:26 jekstrand: Interesting....
03:27 jekstrand: I don't think it was ever completely intended to be supported
03:27 jekstrand: But it got tested so we all implemented it or added hacks.
03:29 airlied: jekstrand: yeah latest 1.2.2 cts branch has them gone
03:30 jekstrand: neat
03:31 jekstrand:is a fan of them being gone
03:41 airlied: okay 38 fails left on 1.2.2 CTS, https://paste.centos.org/view/raw/45d16d59
03:42 airlied: man I hate lines
04:20 jekstrand: airlied: \o/
04:20 jekstrand: Also, lines suck
05:47 tango_: karolherbst: nvidia's opencl platform, for the most part, is not a good benchmark of how to do things right. their devices can allocate more and will allow you to do so in CUDA
05:48 tango_: karolherbst: the choice to clamp at 2GiB per buffer may be simply a result of misreading what the standard say (other platforms have made the same mistake), but may also be a (conscious or not) attempt at crippling opencl in favour of cuda
07:04 hakzsam: some CI failures: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/3032540
07:21 mripard: it seems we have a massive conflict in drm-tip with amdgpu and i915 (and a couple of issues with nouveau and tidss)
07:45 daniels: hakzsam: caused by disk space, which is now being fixed, thanks
07:46 hakzsam: thank
07:46 hakzsam: you
07:59 daniels: :)
08:55 damo22: regarding libpciaccess: i think i found a bug with the x86 map range method but wanted to find out if there is a reason for what i found... https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/blob/master/src/common_interface.c#L314 this line seems to check for a value that can be uninitialised in some cases, because sometimes that check fails so the mapping is not made and then the mapping is set to NULL below that
08:58 damo22: i submitted a patchset for hurd target that also addresses this issue at https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/merge_requests/12
09:05 damo22: i think pci_device_x86_region_probe() should not map the actual memory regions but set the map->memory pointer to NULL so the next time it is mapped it detects as NULL and the mapping is made
09:08 damo22: maybe i should open a new issue on gitlab?
09:17 linkmauve: “01:27:23 anholt_> are there any hw drivers that have a significantly reduced featureset on gles compared to desktop?”, probably Nvidia proprietary, although I don’t know by how much.
09:19 MrCooper: possibly amdgpu-pro as well (not that anyone should be using that with Firefox anymore)
09:20 damo22: ok ive opened an issue on gitlab for the issue i described above
09:22 linkmauve: What I do remember is some Wii ports to the Nvidia Shield requiring desktop GL on Android, due to GLES limitations.
09:23 dschuermann: question about gitlab: can we get this feature? https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_dependencies.html
09:39 dolphin: airlied, danvet: sent an important dinf PR, hopefully it makes in before -rc1
10:30 danvet: daniels, agd5f, mareko do we have a consensus on TMZ and modifiers (and why)?
10:30 danvet: feels like an interesting edge case documenting, and we might have similar problem in i915 soon
10:35 danvet: *worth documenting
10:35 daniels: danvet: I think I'm still leaning towards no-modifier for TMZ, but the drivers have to actually handle it and properly accept/reject rather than just sampling random garbage if we try to use a secure buffer in an insecure ctx/draw
10:35 danvet: daniels, yeah I guess if non-modifier there's lots of fun around that
10:35 danvet: also dma-buf import/export
10:36 danvet: to other devices, which I presume can't read/write since they lack the keys
10:36 daniels: there's a lot of fun anyway - e.g. you can't bind a secure BO to a texture in a draw which emits anything to a non-secure BO
10:36 danvet: yeah these things have much lolz usually
10:37 daniels: so just having modifiers doesn't really solve the negotiation issue; you just need your entire pipeline to be all TMZ or no TMZ
10:37 danvet: the interesting edge case is around "where does the layout world of modifiers end" and "where does the opaque backing storage property world start"
10:37 pq: I hear that "can't" can actually mean "the proces gets killed" or something like that.
10:37 pq: or is the the whole OS?
10:38 danvet: with stuff like tmz, or contig memory, or maybe some compression mode that prevents you from moving the buffer out of vram (at least in any meaningful way where you can still access the data)
10:38 danvet: pq, orbital ion cannon uplink or something like that?
10:38 pq: danvet, something like that, I forget what it actually said in the emails about it
10:38 emersion: wasn't it the whole gfx card?
10:39 pq: something something extremely unhappy hardware is angry at you
10:39 danvet: or maybe dracarys shows up
10:39 danvet: would give solid meaning to "draconian drm" at least
10:39 pq: not the harmless "oh, you get garbage out"
10:41 pq: so yeah, from what I've heard, TMZ would be nothing like a modifier, it has to be explicit through the whole stack, both userspace and kernel
10:42 pq: and userspace must understand what it means
10:42 daniels: TI and NXP implement 'you get it wrong, process gone'; AMD implements 'you get it wrong, texture samples return random garbage'
10:43 pq: easy way to crash all display servers by sending them one TMZ buffer?
10:44 pq: on TI/NXP
10:45 pq: therefore if possible, importing TMZ buffers should fail to begin with unless userspace indicates it knows it's TMZ
10:47 pq: danvet, btw. how's the DRM device hot-unplug doc?
10:48 daniels: pq: yeah, hence why they added a safety check inside userspace to fail e.g. EGLImage import
10:49 pq: mm, sounds like read-only imports need to be a thing, is that already in dmabuf UAPI in the subsystems?
10:49 pq: otherwise a compositor cannot blend together TMZ and normal content
10:50 danvet: pq, hw often sucks are read-only import
10:51 danvet: as in, no way for the kernel to enforce the read-onliness
10:51 danvet: so it's kinda always implied to be rw
10:51 danvet: if your a gpu driver on a specific kernel/hw, you can sometimes do better
10:52 pq: but the TMZ hw implementation has to, right? Or is it that in cases where TMZ is used, there does not exist any non-TMZ content?
10:52 pq: I'm just wondering how a compositor that has both normal and TMZ clients could work and blend them together into a secure output.
10:53 danvet: I think the common rule is that once you have a protected eglimage in your ctx
10:53 pq: maybe TMZ is scanout-only, never composited with a GPU?
10:53 danvet: every fbo/render target needs to be protected too
10:53 danvet: if your gpu can composite protected buffers
10:53 pq: sure
10:55 danvet: maybe cleanest api would be a egl extension where you create a protected gl context
10:55 pq: but if the compositor also imports a normal dmabuf as a texture, what allows it to be textured from but not used as a render target?
10:55 danvet: which requires that you can only bound render targets which are protected
10:55 danvet: pq, hw
10:56 danvet: but would be nice to model that at the egl/gl level too somehow
10:56 danvet: but also not sure anyone cares
10:56 pq: hmm, or maybe it doesn't need to. Yeah, the TMZ hw lurking in the background, pulling the plug if something attempts to actually e.g. write to an unprotected buffer.
10:56 danvet: most use-cases seem to go with a "direct to hw plane" model only
10:56 danvet: pq, well if it's not explicit then you have the DOS attack you describe
10:57 danvet: client hands tmz buffer to compositor, doesn't tell, screen goes blank
10:57 pq: yes and no
10:57 danvet: in the "enforced by killing the gpu ctx" world I mean
10:58 pq: the compositor has to know that it is deadling with a TMZ buffer, but I'm not sure EGL/GL needs to know explicitly - just don't attach the texture into an FBO
10:58 pq: *dealing... though deadling might be accurate :-p
10:58 danvet: it gets tricky as soon as you texture from a protected eglimage
10:58 danvet: then your fbo must be protected too
10:59 pq: yes, that's not a problem
10:59 danvet: it is, if you allocate a non-protected fbo and everything goes boom
10:59 danvet: or maybe we're talking past each another
10:59 pq: if the compositor knows all TMZ buffers, it can poke at GL that way to avoid explosions
11:00 pq: mm, but yeah, I see
11:00 pq: EGL import must fail, unless the compositor also says "I know this is TMZ, just do it"
11:01 pq: the same with KMS import
11:01 danvet: hm where how would that be done?
11:01 pq: I dunno :-)
11:02 danvet: thus far "opaque backing storage properties" just get passed around in the kernel
11:02 pepp: pq: "maybe TMZ is scanout-only, never composited with a GPU" => yes
11:02 pq: but it seems necessary to me so that compositors that don't know what TMZ is would not blindly try to use the dmabufs
11:02 danvet: stuff like making sure it's contig memory
11:03 pepp: (or the compositor needs to use a TMZ framebuffer as well)
11:03 pq: pepp, IOW, "no" :-)
11:04 pepp: :-)
11:05 pq: danvet, the idea that userspace must explicitly say "it's ok to import TMZ" when importing a dmabuf fd to anywhere is that that is the only way to guarantee that userspace knows what it's doing.
11:05 pq: otherwise someone can simply give a dmabuf pointing to TMZ to any compositor and make it crash
11:06 danvet: pq, well eglimage import should probably fail without anything fancy
11:06 pepp: but maybe instead of sampling from a texture that the compositor knows is TMZ, it can sample from a black texture instead (when it needs to do gpu compositing)
11:07 danvet: if radeonsi doesn't do that for tmz, then might be a good security bug there now
11:07 pq: danvet, we have a Wayland extension for weston where the client can tell to avoid egl import completely, aiming scanout-only.
11:07 danvet: if tmz isn't somehow limited through other means
11:07 pq: so KMS import must fail too
11:07 danvet: agd5f, mareko ^^ how does this work?
11:07 danvet: pq, why must the kms import fail too?
11:08 pq: danvet, so that the compositor does not get killed for e.g. trying to use a writeback connector at the same time.
11:08 danvet: oh
11:08 danvet: hm
11:08 danvet: well I guess if you don't have writeback, then kms import can succeed
11:08 pq: or maybe the compositor did not enable HDCP, so would get killed with TMZ anyway
11:08 danvet: pq, also for writeback I think what happens is that the plane simply doesn't scan out, or scans out garabge
11:09 danvet: for the "no hdcp" case I also assume hw handles that by simply not scanning out the plane
11:09 danvet: I think for kms we could require that behaviour
11:09 pq: danvet, but but but TI and NXP?
11:09 danvet: dunno
11:09 danvet: if their hw is so insisting, kms could allocate a black plane and scan that out if it's wrong
11:09 pq: I would prefer explicit failure rather than garbage though
11:10 danvet: I think the "you get killed" though is for compositing
11:10 danvet: not for scanout
11:10 danvet: for scanout all the hw I know about just scans out garbage or black
11:10 pq: from what I read, the "you get killed" applied to all memory access
11:10 danvet: pq, well this is purely the "what if evil client attacks compositor"
11:10 danvet: an evil client can already give you a texture full of rand()
11:10 danvet: so that's not new
11:11 danvet: pq, oh like the entire SoC dies?
11:11 danvet: or how does this work
11:11 pq: danvet, I really don't know, I got the picture of "big scary things"
11:11 lynxeye: danvet: NXP hardware enforces the domains on the bus level, so the scanout HW would most likely get AXI error responses. Don't know what the scanout does in that case, maybe it just dies, or ignores the errror and scans garbage
11:14 pq: danvet, I make a difference between intended garbage and unintended garbage. The client might not be malicious, but just always use TMZ regardless of compositor support. Being able to kill such client would be nice. Maybe the compositor also has bugs on TMZ setup not always succeeding, getting an error would allow e.g. restarting.
11:14 pq: getting an error is less important than avoidin a crash, but I think it would still be good.
11:15 pq: no way to fall back from silent failures
11:33 mareko: danvet: TMZ is more complicated, because when a TMZ buffer is present for a command buffer, all memory writes (TMZ and non-TMZ) will be encrypted
11:34 danvet: mareko, hm so if an evil client injects a tmz buffer into the compositor, without telling
11:34 danvet: would that result in the entire desktop being encrypted and then garbage on the entire screen because no hdcp?
11:34 mareko: danvet: if the compositor is untrusted, it won't be able to read the buffer; if the compositor is trusted, then yes, garbage
11:35 mareko: danvet: TMZ is enabled per command buffer, so the driver tries to split command buffers to allow both TMZ and non-TMZ writes for the same context
11:35 danvet: hm can mesa detect this an reject the eglimage import except when the compositor tells it to?
11:36 danvet: mareko, so you split up the draw calls?
11:36 danvet: and I thought there was at least concept where compositors have a monster shader and just draw everything in one go, across the screen
11:37 danvet: or is the escape hatch that the compositor isn't ever trusted anyway, so "entire desktop is garbage" can't happen
11:37 mareko: danvet: not draws, but I think we flush between draws
11:38 daniels: EGL_EXT_protected_content already does this
11:38 danvet: mareko, either way I guess we do have to make sure that random clients cant abuse tmz (or any other content protection thing) to pull the compositor over the table some
11:38 daniels: it lets you create protected contexts, protected surfaces, and mark EGLImages as also protected
11:39 daniels: so if you get an EGLImage import with a TMZ dmabuf, and they haven't set EGL_PROTECTED_CONTENT_EXT == EGL_TRUE, you can fail it
11:39 danvet: daniels, but that only helps the "everyone is a good citizen" case
11:39 danvet: I'm worried about obvious compositors being tricked into wreaking the entire desktop
11:39 danvet: so I think we need an s/can fail/must fail/
11:40 daniels: strongly agree
11:41 daniels: (this, again, is what NXP already does. I have no idea about TI since I don't care about proprietary drivers. 'kills your process' refers to the hardware behaviour of taking an unrecoverable fault when you try to access that memory. the NXP stack I heard about from Linaro just fails the EGLImage import so you can never get into that situation.)
11:45 pepp: memory writes are encrypted if a TMZ buffer is present in a command buffer and the compositor enables TMZ support (because when both condition are met, the command buffer will run in a secure context which makes all writes are encrypted)
11:50 danvet: pepp, so you get entire desktop as garbage if someone managed to sneak in a tmz buffer somewhere
11:51 danvet: better than "kills your compositor" but not much really
11:52 pepp: danvet: no. If the compositor enables TMZ => it's framebuffer will be encrypted, so everything works fine. If the compositor doens't enable TMZ, then only the TMZ client will look like gargabe, the rest of the desktop will be fine
11:52 pepp: s/it's frambuffer/its framebuffer/ sorrt
11:53 danvet: if even you do some monster drawcall that spans the entire desktop and has the tmz texture bound?
11:53 danvet: or does the hw encryption work per pixel shader invocation somehow?
11:55 danvet: pepp, the trouble is that if we don't make this explicit now, we can't fix it down the road really since it'll either break security or compositors that want content protection
11:56 pepp: (assuming we're talking about the case where the compositor is not running with TMZ enabled): texture reads from the TMZ texture will return garbage. All other operations will be fine.
11:57 danvet: I guess that's the same as mareko above said with trusted vs untrusted
11:58 danvet: I guess as long as everyone starts out untrusted without explicit actions those should be all fine
11:58 pepp: yes
11:58 danvet: pepp, so enabling trusted/tmz works with that egl extension?
11:59 danvet: still sounds a bit like in trusted mode stuff could go wrong if it's not all checked
12:01 pepp: danvet: EGL_EXT_protected_surface allows a client to allocate a TMZ surface. And for now, enabling TMZ requires to use AMD_DEBUG=tmz
12:01 danvet: ah ok, so we can still fool around with semantics a bit
12:02 danvet: but overall I feel like we have to make this explicit, and rejected such buffers
12:02 danvet: or there's just too much confusion
12:03 danvet: might creep on without too much lol on some gpus, but for general platform stuff not a good idea to be that inconsistent
12:03 pepp: what do you mean by "reject such buffers"?
12:04 danvet: if you get a tmz buffer and withoug agreeing to that
12:04 danvet: on the compositor side
12:05 danvet: daniels seems to think that's possible
12:05 danvet: so I guess ideally winsys code would handle that so it's the same on every driver
12:10 pepp: this "so if you get an EGLImage import with a TMZ dmabuf, and they haven't set EGL_PROTECTED_CONTENT_EXT == EGL_TRUE, you can fail it" ?
12:30 austriancoder: anholt_: https://gitlab.freedesktop.org/austriancoder/mesa/-/jobs/3036093
13:22 MrCooper: pepp: yes, the winsys should refuse to import a TMZ buffer into a non-TMZ context; one potential issue being that Gallium resources are per-screen objects, not per-context ones... is it possible to create a TMZ context passing a non-TMZ one to eglCreateContext's share_context parameter (or vice versa)?
13:28 zmike: anholt_: do I need to take any further action with those piglit MRs?
14:27 FreeFull: How difficult is it to get started with contributing to mesa, for someone who hasn't done driver development before?
14:35 imirkin: FreeFull: helps to have a goal in mind, at least for me.
14:35 FreeFull: Well, I'm currently stuck with a laptop that has Haswell graphics
14:36 FreeFull: So I'd be either trying to get iris to work on Haswell (probably not possible?), or writing a new gallium-based driver for Haswell
14:36 imirkin: that's actually not that much worse than the latest, for the most part.
14:36 imirkin: iris requires pinned buffers for everything at its core, which is only possible on gen8+
14:36 FreeFull: Ok, so not possible
14:37 imirkin: (and actually even some gen8 chips don't work well in that scenario ... restricted VM space? something like that.)
14:38 FreeFull: It just feels like Haswell's gonna decay because most people have newer stuff
14:39 FreeFull: Although for now the only issue I've ran into is a few rendering bugs with dxvk
14:40 imirkin: vk is covered by anv
14:40 imirkin: anv support for gen7.5 is "best effort"
14:41 FreeFull: Yeah
14:41 imirkin: i.e. non-conformant
14:41 imirkin: i expect that patches are welcome though
14:41 FreeFull: The best way for me to contribute right now then, would be to find out what's causing those two rendering issues and fixing that
14:42 imirkin: that could be your goal, sure
14:42 imirkin: i believe renderdoc is the tool people use for making vk traces and analyzing them?
14:42 imirkin: (i'm not really up on the latest vk stuff)
14:42 imirkin: (or really any vk stuff)
14:44 FreeFull: Thanks
14:48 pq: and for me, Haswell *is* my newer stuff :-p
14:52 FreeFull: I'm thankful I'm not stuck with NVidia graphics, at least =P
14:57 udovdh: hello
14:57 udovdh: what can I do to not suffer from sdma0 and gfx ring timeout errors?
14:58 udovdh: this is AMD Ryzen 5 3400G with Radeon Vega Graphics on Fedora 31, git mesa, kernel.org, etc.
14:58 karolherbst: udovdh: filing bugs?
14:59 udovdh: on kernel 5.6.17 I see both
14:59 udovdh: file a kernel bug?
14:59 udovdh: mesa bug?
15:03 imirkin: udovdh: find a concrete way to reproduce on demand
15:03 imirkin: and file a bug explaining those steps.
15:04 imirkin: mesa bug.
15:04 imirkin: udovdh: alternatively ask in #radeon, they might have some concrete steps for you to collect appropriate information
15:09 udovdh: imirkin, ok thanks
15:09 udovdh: issue is that these errors happen spontaneously in fairly normal use of the PC
15:09 udovdh: no heavy gaming or things like that
15:13 pepp: udovdh: I'd say file a kernel bug if the errors happen "randomly" (include the full dmesg in your bug report)
15:13 udovdh: ok...
15:15 pepp: MrCooper: does a compositor need to import a buffer if the usage is to display it directly (without composition)?
15:17 MrCooper: pepp: my understanding is importing via EGL isn't needed for that
15:22 danvet: pepp, MrCooper I think there's a wayland protocol exactly for that, to make sure compositor doens't try to import into an eglimage and set itself on fire
15:27 MrCooper: that only seems needed if EGL allows resource sharing between TMZ and non-TMZ contexts, otherwise the driver should just refuse to import TMZ buffers if the Gallium pipe_screen has a non-TMZ context
15:31 danvet: pq, is amd happy already with the new unplug spec?
15:31 danvet: imo acked-by: me, we'll have to refine it as we go anyway
15:34 danvet: tzimmermann, [PATCH] drm/ast: fix missing break in switch statement for format->cpp[0] case 4 <- looks like 32bpp mode on ast got broken?
15:42 danvet: pq, read it carefully once more, slapped an r-b on top
15:52 daniels: https://gitlab.freedesktop.org/wayland/weston/-/blob/master/protocol/weston-direct-display.xml is the 'you'll never be able to import an EGLImage so don't try' protocol
15:52 daniels: and yes, for KMS we import dmabufs directly into GBM and bypass EGL
15:55 Lyude: imre_: would you perhaps be up to reviewing https://patchwork.freedesktop.org/series/77671/ today?
15:58 imre_: Lyude: ok, happy to do that, but give me some more time
15:59 Lyude: imre_: np
15:59 imre_: in two days
16:02 pepp: ok, so if EGL import is only used in the non-direct-scanout case then I guess it makes sense to refuse to import TMZ buffer in a non TMZ compositor
16:10 daniels: there is a caveat - I don't know how other compositors behave, but Weston at least will kill your Mesa client if it submits something that can't be imported as an EGLImage - unless you use that extension
16:11 daniels: (the rationale is that being able to use something in planes is very much _not_ guaranteed and often impossible - we need a reliable fallback that we know works - just showing nothing isn't an option for us in the default case, because users think that's a bug and then go tell us it's a bug)
16:11 emersion: daniels: depends if create_immed is used
16:12 daniels: yeah, that's why I said 'Mesa client', because Mesa uses create_immed and thus has no way to handle errors :P
16:12 daniels: we could make it use the non-immed path, which then results in an eglSwapBuffers failure return which is realistically either a) not checked at all, or b) helplessly dumped into stderr with no actual recovery
16:12 emersion: i wonder if it would make sense to gte better error reporting with create_immed
16:12 emersion: get*
16:13 daniels: hm?
16:13 emersion: ie. not killing the connection
16:14 emersion: mesa could also use the non-immed path and wl_display_dispatch till the buffer creation succeeds
16:14 emersion: but that would have performance consequences
16:14 emersion: (?)
16:19 pepp: daniels: ok.. I'll implement "the reject TMZ buffer import" logic and test it with Weston to understand how it works
16:43 alyssa: https://people.collabora.com/~alyssa/test.xml <-- This seems like a dEQP bug?
16:43 alyssa: v_out = in0 - in1;
16:43 alyssa: iter 0, test 1: in0 = -9882, in1 = 28438, ref out = 27216 / 0x00006a50
16:44 alyssa: but... -9882 - 28438 = -38320, which overflows
16:46 alyssa: I guess it's really testing overflow behaviour then
16:47 alyssa: oh, right, wrap vs saturation
16:47 alyssa: nvm, my bad
16:58 jekstrand: alyssa: Just saw lower_ssbo.... If you use the right nir_address_format_64bit_bounded_global, you'll get bounds checking "for free". :)
16:58 alyssa: jekstrand: ah?
16:58 jekstrand: alyssa: We use that in ANV for bounds-checked SSBO access with global memory ops.
16:59 jekstrand: Where by "for free" I mean you don't have to write much code. I don't mean that it doesn't use any shader ops.
16:59 alyssa: fwiw the mali blob just sticks in an umin with offsets
17:00 alyssa: karolherbst: was nervous about that breaking buggy apps
17:00 alyssa: but we checked, it's in spec
17:00 jekstrand: I don't remember what I did for nir_address_format_64bit_bounded_global
17:00 alyssa: at least for GL (which the pass is for)
17:00 alyssa: if's to return 0 it looks like
17:00 jekstrand: It might have been a umin or it might have been control-flow. Both are allowed in Vulkan.
17:01 alyssa: fun :p
17:01 jekstrand: Looks like I use control-flow
17:01 jekstrand: But we could make a flag for that
17:02 jekstrand: In any case your all-caps comment gave me a bit of pause. :-P
17:03 alyssa: jekstrand: do you not appreciate SHOUTING IN NIR?
17:03 alyssa: =D
17:03 jekstrand: And I thought you might appreciate knowing how others have solved the "SSBOs are global" problem.
17:03 jekstrand: Nvidia has that problem as well
17:03 jekstrand: I don't know what karolherbst has done about it
17:03 jekstrand: daniels: Do you know why gitlab keeps failing to merge stuff when people click "merge" or when marge tries to? And is it fixable without just waiting for a GitLab update?
17:04 karolherbst: huh? (just came out of a meeting)
17:04 karolherbst: ohh ssbo stuff and robustness
17:04 danvet: who do I need to ping for v3d.ko?
17:05 karolherbst: didn't I had a patch for it?
17:05 danvet: or well iago toral's nick if https://blogs.igalia.com/itoral/2020/01/17/i-am-working-on-the-raspberry-pi-4-mesa-v3d-driver/ is to be trusted
17:05 alyssa: yeah but it was with an if thing which i didn't like so we agreed to ignore until later
17:05 karolherbst: jekstrand, alyssa: https://github.com/karolherbst/mesa/commit/047ec5a5fd8b4a5d0683ebb6ec0192e4d49b3c40
17:06 karolherbst: don't know what went actually in at this point
17:06 alyssa: a scary comment
17:06 karolherbst: but that's what we do in nouveau and it's just one additional instruction
17:06 daniels: jekstrand: please give me MR numbers, it's not something I've seen happen recently
17:06 karolherbst: maybe we could have different strategies on robustness here though
17:06 karolherbst: but usually returning 0 for reads do less harm
17:06 alyssa: karolherbst: branching is Not Fun over here
17:06 karolherbst: and especially games ported over from dx might assume 0 on different ocassions
17:10 x2s: Hi. I've got some questions about freesync support, how to test it and the vulkan support of it. Is this the right place?
17:14 tzimmermann: danvet, i've seen it
17:15 tzimmermann: although I never noticed any issues on my machine
17:21 gpoo: danvet: @itoral @apinheiro @chema on gitlab
17:23 jekstrand: daniels: !5395
17:23 danvet: gpoo, I mean the kernel driver, they're not around here?
17:23 danvet: not the v3dv vulkan one
17:24 gpoo: danvet: Jonathan Malek
17:24 daniels: jekstrand: urgh.
17:24 daniels: (NB that if people are clicking merge, we'll probably get that error since they've jumped marge's queue ...)
17:24 anholt_: oh, cool, so this finally happened. https://www.raspberrypi.org/blog/vulkan-update-now-with-added-source-code/
17:25 danvet: gpoo, hm not seeing much there either ...
17:25 danvet: maybe v3d Just Works (tm)
17:25 danvet:going to break it most likely
17:25 anholt_: danvet: basically, they haven't really had to do anything since I left it
17:25 alyssa: it wasn't open source before?
17:25 danvet: anholt_, I have some lockdep annotations for drm/scheduler
17:25 danvet: probably going to go boom
17:25 anholt_: alyssa: vulkan is new
17:26 danvet: gpoo, so I guess I need an email address to ping them on the patch which would need v3d.ko input
17:26 daniels: jekstrand: but looking at the logs, no-one's done that in a week now ...
17:26 jekstrand: daniels: I did it a week ago or so but only because marge failed
17:26 jekstrand: where by failed I don't mean CI failed I mean the merge failed
17:27 jekstrand: Others on my team are complaining about it as well
17:27 anholt_: yeah, I've been getting a lot of spam about it from marge
17:27 daniels: I know it was a horrible problem like a week ago. my understanding is that it was now not a problem, since everything I've looked at that's failed has been something unrelated
17:28 gpoo: danvet: oops. Jonathan is working on a different one. Iago Toral itoral at igalia.com
17:29 daniels: jekstrand: I can try to look at it this weekend, but I really am down to just instrumenting all the surrounding codepaths and trying to figure out why. that and/or making marge retry a few times with sleeps.
17:31 danvet: gpoo, thx
17:33 gpoo: np
17:50 austriancoder: Is there any foss game that uses compressed textures (etc, dxt, astc)?
17:54 HdkR: austriancoder: There's the Nintendo Switch emulator, but that is only FOSS in one sense :P
17:55 austriancoder: HdkR: :)
17:56 austriancoder:just looks for something to do some benchmarking
18:08 x2s: .oO( well, enabling it solves the first problem... )
18:11 anholt_: austriancoder: I remember repotrs of https://wz2100.net/ failing on vc4, which can't do dxt
18:20 x2s: and it's working for some games, but not for the one proton game. Hm.
18:53 mattst88: dcbaker[m]: are we planning to release 20.0.8 today?
18:54 dcbaker[m]: mattst88: was there any motion on the last three blockers? I pinged people yesterday but haven't checked to see if they responded yet
18:55 mattst88: let me check
18:56 mattst88: I think !3019 is done since you backported the omx patch. the commit has Closes: ... but somehow it didn't close the issue
18:56 mattst88: so I just did that
18:58 mattst88: I'm in favor of removing !2957 from the milestone, since it's triggered by a libva-utils test and has been open for 3 weeks without a response
19:01 mattst88: not sure about #2863. seems like it might be a real bug, but might only happen with -flto?
19:02 mattst88: also unclear if it's a regression or not.
19:03 mattst88: I wouldn't feel bad about releasing 20.0.8 without a fix for that, especially since we've already released 20.1.1
19:03 mattst88: I wouldn't even care about 20.0.8 except that 20.0.5+ has had that webgl regression that means I cannot stabilize it
19:05 FreeFull: HdkR: What sort of monster computer do you even need to emulate a Nintendo Switch
19:06 HdkR: FreeFull: Eh, some new-ish CPU with 4-8 cores, and preferably an Nvidia host GPU running the Nvidia blob
19:07 FreeFull: Oh. That doesn't sound too bad
19:07 FreeFull: I'm not a fan of NVidia, of course
19:07 HdkR: It's emulating Cortex-A57 CPUs clocked at 1Ghz, so it isn't completely terrible
19:07 FreeFull: 1GHz is still fairly high
19:07 FreeFull: For emulation
19:08 FreeFull: Since it's ARM, you can't do virtualisation, unless you happen to have an ARM host
19:08 jekstrand: If you're using something with a decent cross-jit, you can get reasonably good perf
19:08 HdkR: ^
19:08 FreeFull: JIT definitely does help
19:08 HdkR: Merry's Dynarmic is actually really good
19:10 mattst88: dcbaker[m]: yeah, honestly, let's just cut the 20.0.8 release and put 20.0 to bed
19:14 linkmauve: “19:50:14 austriancoder> Is there any foss game that uses compressed textures (etc, dxt, astc)?”, 0ad does use S3TC, as part of their compilation pipeline they convert all PNGs into it.
19:15 linkmauve: I happen to have recently continued its port to GLES 2.0, so be aware that you can build it that way.
19:21 mbakke: will https://gitlab.freedesktop.org/mesa/mesa/-/commit/f5a8958910f53d924d062cbf024cebe4134f757a make it to an eventual Mesa 20.0.8?
19:30 airlied: dos1: yes will process today, thanks!
19:34 kisak: dcbaker[m]: looks like https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4861#note_509171 is why mbakke is asking about that commit
19:36 mbakke: indeed, I tried staging/20.0 which did not fix the issue, but the f5a8958910f53d924d062cbf024cebe4134f757a commit applies cleanly and does solve the problem
19:37 mattst88: doesn't look like it, without intervention, since the commit doesn't have any tag that would cause it to be picked
19:38 mattst88: massive sigh
19:38 mattst88: yes, that needs to go into 20.0.8
19:40 airlied: doh
19:40 airlied: dolphin: will process today
19:45 austriancoder: anholt_: linkmauve: thx - will have a look
19:45 anholt_: linkmauve: nice. I've been meaning to get a 0ad trace into traces-db
19:46 linkmauve: Oh cool!
19:55 dcbaker[m]: mbakke, kisak, mattst88: I've pulled that commit into the staging branch
19:55 mattst88: thanks!
19:56 dcbaker[m]: hakzsam: there's a couple of radv patches from you near the top of the staging/20.0 tree that required me to do some backporting, do those look good to you? (I forgot to ask yesterday)
19:58 dcbaker[m]: dj-death: I think the iris: gem handle patch also had some conflicts, if you can make sure that looks good
20:00 mbakke: dcbaker: \o/ thanks
20:35 dj-death: dcbaker[m]: oh, right
20:35 dj-death: dcbaker[m]: it also needs another patch for 20.0
20:36 dcbaker[m]: dj-death: not the one that I just added? (the os_something_something returns int not bool)
20:37 dj-death: dcbaker[m]: yeah that one :)
20:38 dcbaker[m]: yay, I don't need more patches
21:52 airlied: anholt_, daniels : https://gitlab.freedesktop.org/kusma/mesa/-/jobs/3045297
21:52 airlied: seems to have excessive runtime
21:52 airlied: 3 hours between merges seems like a long way from 30mins
21:53 daniels: I suspect that machine has in fact died right at the end
21:54 daniels: that's calamitously outlying as a runtime
21:54 daniels: the build very consistently completes very quickly these days
22:17 anholt_: but also what was going on with it not timing out at 60min?