00:05 dcbaker[m]: The original mass effect uses it if you have an AMD cpu. Even if that AMD cpu doesn't have 3dnow....
00:15 kisak: supposedly fixed https://www.tomshardware.com/news/game-dev-patch-amd-ryzen-black-blob-bug-mass-effect
00:39 jenatali: airlied: Would you be the right person to take a look at proposed changes to the drisw frontend?
00:40 airlied: jenatali: I've no idea, so that probably means yes, sroland/jrfonseca might also be invested in that area
00:40 dcbaker[m]: kisak: I have a bulldozer, and for me there are whole cut scenes that just cause the game to crash if you load them. So I have to play with the cutscenes off :(
00:40 dcbaker[m]: maybe that will fix my problem
00:41 dcbaker[m]: or maybe just upgrading my bulldozer to something not almost 10 years old... :)
00:41 jenatali: airlied: Sounds good, thanks. Found some sync issues trying to hook up glon12 like zink
00:41 airlied: jenatali: I had some vague fence work in there done somwhere
00:41 kisak: dcbaker[m]: yeah sorry, the article does say "We verified that the game does not use 3DNow! instructions directly (only the system DLLs do)." but I don't know if that means system dlls are bundled in the game
00:43 dcbaker[m]: I don't know either. I also haven't played on windows newer than windows 7, so maybe on windows 10 it just works
00:43 jenatali: airlied: Specifically https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7937/diffs?commit_id=9f6e4b7638ee4916f3a4fbbf0b5a6abc23d43fed, which is https://gitlab.freedesktop.org/mesa/mesa/-/commit/ece2cc3352f52858587d13092b4300b0d6447760 ported from wgl -> drisw
00:45 airlied: jenatali: https://gitlab.freedesktop.org/airlied/mesa/-/commits/llvmpipe-wip-scenes/ has a drisw patch in there as wel
00:45 airlied: sounds like you might be fixing similiar thing
00:45 airlied: https://gitlab.freedesktop.org/airlied/mesa/-/commit/c1ef2b851394f4e1ff5f21adb3613fbc95d3013b
00:46 jenatali: airlied: Yep, sounds about the same. Though apparently I missed the fence_finish? Or is the WAIT flag equivalent to that?
00:47 jenatali: But yeah without that I was getting all kinds of corruption with the d3d12 driver, looks much better with that
00:48 airlied: jenatali: the wait does that
00:49 airlied: so might be better to just use yours :-P
00:49 airlied: though need to look at the msaa interaction there
00:50 jenatali: Haven't tried MSAA... probably all kinds of broken :P
01:26 airlied: jenatali: if I change printf to 8-byte header will that be a pain for CLon12
01:27 airlied: ?
01:27 jenatali: airlied: Nah, just requires a change to the runtime, but not a big one
01:27 jenatali: I've already got a few tweaks pending based on the rest of the changes: https://github.com/microsoft/OpenCLOn12/pull/12
01:27 jenatali: What's one more :P
10:19 pq: Reading EGL spec, I got the idea that pbuffers do not necessarily have the swap behavior as "preserved", is that so?
10:20 pq: Or can I simply rely on the spec saying that for pbuffers eglSwapBuffers has no effect, meaning that swap behavior is preserved?
10:20 emersion: why not use the buffer age extension to find out?
10:20 pq: because Mesa EGL surfaceless does not seem to have it.
10:21 emersion: oh, really?
10:21 pq: not advertised for me, no
10:22 pq: OTOH, buffer_age is not even enough for what I'm doing, I really want to depend on "preserved" on a pbuffer.
10:22 emersion: i thought pbuffers are just like any other EGLSurface
10:23 pq: Mesa certainly does not expose any EGLConfig with pbuffer | preserved bits
10:24 pq: EGL spec also says " If surface is a single-buffered window, pixmap, or pbuffer surface,eglSwapBuffers has no effect."
10:24 emersion: yeah, you don't even need to eglSwapBuffers… but then you only have a single buffer, no double buffering
10:25 emersion: so if you're doing screen capture at the same time, it isn't great
10:25 pq: I specifically do not want double-buffering
10:25 emersion: well, i guess you can just never eglSwapBuffers, and always work with the back-buffer then
10:26 pq: I wrote a test to Weston's damage region handling, and I'm trying to take screenshots of the damage. So I must have the equivalent of buffer_age=1 to avoid unwanted damage.
10:26 pq: pbuffers are never double-buffered anyway, AFAIK
10:27 pq: and a pbuffer EGLSurface is really handy in avoiding special-case paths just for headless operation
10:29 emersion: would be nice to have double-buffered headless EGLSurfaces thoughj
10:29 emersion: though*
10:29 pq: use GBM platform?
10:29 emersion: yeah…
10:30 pq: you even get a dmabuf out that way
10:30 emersion: that's what we ended up doing indeed
10:31 pq: I don't need a dmabuf, and I don't care about managing the DRM devices in this case, and it should work also with sw gl.
10:32 pq: So my question boils down to: can I assume that a pbuffer EGLSurface always has the "preserved" swap behavior?
10:36 MrCooper: pq: if there's a single buffer only, I'd expect SwapBuffers to be a no-op, preserving the buffer contents
10:36 pq: can a pbuffer surface then have more than one buffers?
10:42 MrCooper: not in EGL AFAIK (they can in GLX)
11:11 pq: okay, I'll try relying on that then. And if it turns out false, a Weston CI test will fail.
11:11 pq: thanks!
11:13 MrCooper: np, hopefully it won't turn into famous last words :)
11:17 pq: funny that one cannot query EGL_SURFACE_TYPE from a surface
11:30 pq: success!
12:25 cwabbott: jekstrand: wow, looks like this nir_tex_instr::dest_size is even more confused than i thought
12:27 cwabbott: glsl to nir uses float for 32-bit floats and float16 for 16-bit floats, but nir_lower_cl_images_to_tex always uses sized types
12:29 cwabbott: the dxil backend has some contortions to throw out the size and then add it back, and so does freedreno, and intel just silently turns float into float32 and int into int32
12:30 cwabbott: and the implementation of TXQ in ttn just looks totally busted... it never sets a type on the nir txs instruction then reads it
12:30 cwabbott: i have no idea how that ever worked (probably not?)
12:31 cwabbott: oh, and panfrost also has similar contortions
12:31 cwabbott: if only this had been fixed when we added 16-bit support to glsl_to_nir...
17:04 cwabbott: I'm looking at this job: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/6046839 which probably fails because of a nir_validate failure, but I don't see any way to get the stderr output to see what it was
17:08 MrCooper: cwabbott: have you tried downloading the job artifacts to check if there's anything in there?
17:08 anholt: MrCooper: I get a 500 when I try
17:08 cwabbott: yes, from a quick look it's not there
17:08 MrCooper: anholt: hence download, not browse :)
17:09 cwabbott: well, there are artifacts, but not for the test that failed
17:09 cwabbott: and no "log of all things" file either
17:10 anholt: I'd raise an issue against the ci label and tag the authors of that stuff. though I know they're doing a full rewrite right now.
19:09 Lyude: anyone around who has irc op privileges in #intel-gfx? looks like the guy who always spams #nouveau is there (I assume that's who he is judging on how he writes). figured i'd mention it here since he's not in here and I'd rather not feed the trolls
20:29 DrNick: #llvm on OFTC finally figured out how to ban him so he's returned to his old haunts
20:29 airlied: anyone want to write a graphicsbot :-)
22:06 airlied: jekstrand: since you know all the crazy ideas, ralloc + vulkan memory allocators?
22:07 airlied: or more importantly, should I really care at all about vk memroy allocators
22:13 ajax: i feel like they can't really be that important since we never call the pfnInternalAllocation
22:13 ajax: but i also have no idea
22:16 ardera: I compiled mesa 20.2 to do some debugging with "-Ddri-drivers=", "-Dgallium-drivers=vc4,v3d,kmsro", "-Dglx=disabled" and debug buildtype
22:18 ardera: now "glDeleteFramebuffers" and "glDeleteTextures" somehow became wired to "noopDeleteFramebuffers" and "noopDeleteTextures".
22:18 airlied: ajax: yeah my feeling is bleh on their usefulness outside of embedded scenraios
22:18 airlied: ajax: and ralloc esp for the lavaqpipe pipeline and possible command buffer would make life a lot easier
22:19 ardera: anyone know how I can let them not be noops again?
22:48 tanty: MrCooper: I think "0781d9825b31d55aa350dfe158a314eb663e9c5d" broke the images generation ?
22:48 tanty: I'm having this:
22:48 tanty: https://gitlab.freedesktop.org/tanty/mesa/-/jobs/6055839
22:48 tanty: it seems like MESA_BASE_IMAGE is not defined when FDO_BASE_IMAGE gets its value (?)