01:21 luc: Hi, I notice that ctx->Driver.FinishRenderTexture() has gone from mesa source tree long time ago. so now how do we make sure the texture has been rendered done (IOW pixels already in vram) before it is fetched in the following render commands in the scene where render-to-texture is used. I mean, especially for tbr gpu, if without flush on render-to-texture, the next texture2D() on that preceding texture could fail to fetch
01:21 luc: up-to-date texel, couldn't it?
02:06 airlied: luc: finish_render_texture still exists
02:27 luc: yes, there are so many states to be invalidated, i am not sure which would invoke gallium->flush eventually
05:55 KungFuJesus: ok bisected, the commit giving me trouble: ec7afd2c24
08:25 MrCooper: DemiMarie zamundaaa[m]: to be pedantic, non-linear modifiers generally define alignment constraints, the linear modifier is an exception (for which there's currently a proposal to create variants with alignment information)
08:27 MrCooper: luc: rendering to a texture and then sampling from it generally doesn't require a full-blown flush
08:27 DemiMarie: MrCooper: Does that mean that it is possible to validate the parameters of a given buffer, given _only_ the format, its non-linear modifier, and the offset/width/height/stride/size of each plane?
08:27 MrCooper: in principle, yes
08:28 DemiMarie: What about in practice?
08:28 DemiMarie: Would any issues be fairly easy to find through hardware-in-the-loop fuzzing?
08:28 MrCooper: I'm sure you're familiar with the joke about theory vs practice :)
08:29 DemiMarie: Yes, I am :0
08:29 DemiMarie: What I would prefer is if drm/drm_fourcc.h also included validation code.
08:30 DemiMarie: I already know from zamundaaa that the AMD drivers are buggy in this area.
08:32 DemiMarie: MrCooper: Would it be reasonable for all future formats to include validation code, code to build a tiled buffer on the CPU, and code to parse the tiled buffer on the CPU? The idea is that this would serve as an executable specification of the format.
08:34 MrCooper: KungFuJesus: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12048 / https://gitlab.freedesktop.org/mesa/mesa/-/issues/11933
08:35 MrCooper: zmike: ^ bisected to a dril commit of yours
08:38 luc: MrCooper: I guess it indeed doesn't if gpu is IMR, but on some TBR gpus, the rendered texture may stay in the buffer on chip without flush
08:39 MrCooper: nothing like a cache flush which suffices?
08:39 MrCooper: a full flush will surely murder performance for that kind of use case
08:43 zamundaaa[m]: MrCooper: well, the alignment constraint seems to be different on different GPUs in practice
08:43 MrCooper: same modifier should mean the same thing regardless of device, that's the point of modifiers
08:44 MrCooper: it sounds like some modifiers might not be well-defined / there are driver issues
08:44 zamundaaa[m]: In theory
08:45 zamundaaa[m]: Yes
08:45 MrCooper: is this about pitch or offset alignment?
08:46 emersion: to me alignment is hw-specific potentially?
08:46 MrCooper: not supposed to be for non-linear modifiers
08:46 emersion: alignment is about placement, placement is not covered by modifiers
08:47 MrCooper: you're talking about offset alignment, better be explicit
08:47 emersion: maybe in practice there is a "natural" alignment for a given modifier, but i don't think this is a hard rule
08:47 emersion: eh
08:48 emersion: what do you mean by "alignment constraints" then?
08:48 MrCooper: pitch alignment
08:48 emersion: right
08:49 MrCooper: there's also the alignment between multiple 2D "slices"
08:50 MrCooper: or even alignment of the size of a single slice
08:52 zamundaaa[m]: MrCooper: well, it only takes one of them to be different for the image to be wrong
08:52 DemiMarie: emersion: If I understand modifiers correctly, I should be able to validate Wayland linux-dmabuf requests without knowing which hardware is in use.
08:53 zamundaaa[m]: In the issue I linked, I think it's offset alignment though
11:05 mlankhorst: I've been trying the modeset client code, and I was hoping tiled displays would be supported correctly
11:05 mlankhorst: Initially, the x/y offset is correctly detected, but later on ignored when actually setting the FB.
11:05 mlankhorst: I found a small bug in pan_set() which overwrites, but I don't think it's the only one
11:21 tzimmermann: klankhorst, i doubt this code has seen much testing
11:23 tzimmermann: mlankhorst ^
11:30 mlankhorst: tzimmermann: thought so. Right now it shows the first half of the FB twice instead. Hoping to find the remaining bug, it's curious..
11:30 mlankhorst: I don't see x/y being set elsewhere
11:32 tzimmermann: the tile-mode handling a mistery to me
11:32 mlankhorst: Yeah same, unfortunately. It's detected correctly and then completely has its results discarded
11:33 mlankhorst: Trying to work my way up to wayland :)
11:47 MrCooper: FWIW, this should be handled internally by the Wayland compositor, not affect the Wayland protocol per se
11:50 mlankhorst: Yeah, but I think I need to change the driver to sync vblank for both halves
14:15 zmike: MrCooper: uhhhh
14:27 SpieringsAE: marex: I'm trying to port some imx8mp based boards from the nxp kernel to mainline and I am 90% there, but there is one specific display chain that is driving me crazy and I was wondering if you maybe knew something. So the chain goes like this lcdif1 -> mipi-dsim -> sn65dsi84 (actually 85) -> dual lvds display
14:27 SpieringsAE: also sorry if this is not the place to ask
14:29 SpieringsAE: I got it so that the display mode is exactly the same, the registers in the sn65dsi85 are the same, but its not working. I feel like the lcdif1 -> mipi-dsim should work too, because I did already get that working with an sn65dsi86
14:58 kikuchan: Hello, I'm developping a generic MIPI DSI/DPI(+SPI) dual stack panel driver: https://gist.github.com/kikuchan/b247698b6606cbfbd006a7b08b397c22
14:58 kikuchan: Before posting to the ML, 1. could anyone help me please? It's not tested on DSI panels yet. 2. any suggestions please?
15:17 freesoulsgoing: it does most of the time appear that switch has just a simple eeprom 32bit addressing wide at max. So ram lookup tables or flash/hdd eeprom emulation based lookup tables would do the same thing, fpga is there quite rarely. It is not a problem of any kind, so encoder to compressed needs loop or dma, where as decoding back to verbatim uses small lookup table. mul instruction in a loop is
15:17 freesoulsgoing: enough, very simple stuff, but i gotta say i am leaving now, this year lots of devils get handled around the world, as the conflicts and fraud etc has progressed and has to be handled by force. i work with smallest chip accelerator being atom era hw that I support terms of integrated gpu r300, earlier ones i do not have myself, and are no longer sane to be bought. Yeah i won't bother
15:17 freesoulsgoing: you anymore.
17:21 freesoulsgoing: The state is very solid allround, my lists entries have been all achieved and i no longer have to come here, i said the memory densities possible ontop of systems i actually initially did not see possible days back, so it's bit cherry on the cake that i dug those out finally, the defense modifications safety and security work i no longer cover publicly. So all of you have been let or
17:21 freesoulsgoing: set free of my spam as of now.
17:34 KungFuJesus: zmike: ah, I had half a mind to open an issue and ask whether or not you knew a reason that this would break support for nv30/nv40
17:34 KungFuJesus: I'm starting to suspect it's endianness independent and it's just nobody has these GPUs anymore to test
17:35 zmike: can confirm I do not have those gpus
17:35 KungFuJesus: hmm, I don't have time to actively investigate this until tonight but maybe you can give me some ideas to try?
17:39 KungFuJesus: Hmm, it might still be endian dependent. Both filed issues that bisected to that problematic commit are on ppc64. And a comment about the pipe format there might be the ticket
17:45 freesoulsgoing: So the final words is that, it's somewhat world wonder as to how much we can store to computer memory, and the programming society and sciense made no mistakes overall regardless of how bitter i was, but i think you would agree that people who started conflict with me have been only lying and scamming in world, their activity of entire absurd was and is known to me, and i think you
17:45 freesoulsgoing: agree also it's very disturbing to the world , and big absurd , they might need to be handled not to do such things, what you'd end up agreeing one way or another if you have intelligence which is expected, we would have so much better things to do then make war if such prospects or suicidal scammers did not push insanity. So its a bummer, quite sad situation that i saw coming though,
17:45 freesoulsgoing: cause i delt with such humans for decades before coming here, and they never straightened up not even today.
18:11 KungFuJesus: zmike: yeah I think it's something screwy with the pipe format being selected. I think the old way used endian independent pipe formats and this enables configs that are endian dependent
18:19 KungFuJesus: it looks as though this macro was intended to be used on big endian architectures: https://gitlab.freedesktop.org/mesa/mesa/-/blob/20b34007014953f5bce7c0073879320c706273a7/include/drm-uapi/drm_fourcc.h#L108
18:21 KungFuJesus: this whole fourcc lookup table thing is new it seems and I don't know exactly how it's supposed to work. The previous working version of this driconfig code with big endian predated this: https://gitlab.freedesktop.org/mesa/mesa/-/blob/3de62b2f9a6cbcf3fea1d33af98be20505421d4b/src/gallium/targets/dril/dril_target.c
18:23 mattst88: just curious, are you investigating the DRI-doesn't-work-on-big-endian issue? (https://gitlab.freedesktop.org/mesa/mesa/-/issues/12048)
18:26 KungFuJesus: I am, yes
18:27 mattst88: great
18:31 KungFuJesus: in as much as I can, anyway. Not sure if I understand if these formats pertain to endianness on the device or the host CPU
18:46 KungFuJesus: I guess I'll have to look at the egl configs coming out of init_dri2_configs and compare the before and after. I do notice that peglGetConfig is called rather than a config being explicitly constructed where the R, G, B, & A sizes are checked against drilconfigs, so the issue may reside further up the stack somewhere
21:47 jenatali: Heads up, looks like some asan/ubsan jobs might be close to bumping up against timeouts sometimes: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/69274488
21:48 jenatali: This pipeline had 5 asan/ubsan failures, one of them was a re-run that also failed, but the third run of that job eventually passed
22:14 KungFuJesus: lol, oh fun, init_dri2_configs is called when the gallium module is initialized, with a startx. Getting to this in a debugger is going to be difficult
22:15 KungFuJesus: guess I can run startx from gdb
22:31 KungFuJesus: man this is impossible to intercept with a debugger. Does anyone know how to step through dril's functions?
22:32 KungFuJesus: I added the dri module as a symbol file and it's resolving symbols from it but it's never hitting them
22:33 KungFuJesus: I kind of wonder if setuid with X11 is to blame here, I should recompile with that bit removed
22:44 KungFuJesus: yeah I can't break on this function for the life of me, Either I'm doing it in the wrong places or all of the dlsym() based resolution is subverting a debugger somehow
23:12 zmike: are you running Xorg directly?
23:12 zmike: otherwise you won't hit it
23:12 zmike: startx is not Xorg
23:18 KungFuJesus: there's also the fact that it clobbers the tty
23:18 KungFuJesus: what's a good way to do this?
23:18 KungFuJesus: I'm a little surprised that gdb doesn't follow the forked processes launched by startx
23:19 KungFuJesus: zmike: it looks like your main change in here besides making it cosmetically better was calling EGL functions to get these configs. Am I right?
23:20 zmike: sure
23:20 zmike: I usually debug it by detaching a screen from the tty and then reattaching it over ssh
23:21 KungFuJesus: ah, modern x launches have some issues with that, particularly with permissions. You usually have to launch from the provided ptys
23:22 KungFuJesus: I did find a way to startx from a remote shell at one point again but I don't recall what I had to change to make that work
23:22 zmike: yea you probably need to also edit the /usr/bin/Xorg wrapper to make it do what you want
23:43 KungFuJesus: ahh, I believe there's yet another issue hiding in here that's preventing X from starting entirely. I'm curious where that one began
23:43 KungFuJesus: might have to bisect to get to the bottom of that, too
23:47 KungFuJesus: lol, yeah, that's a separate issue. A complete revert of ec7afd2c still results in X not launching
23:48 KungFuJesus: maybe I'll bisect on a tree with that commit cherry picked out or something