08:54sima: airlied, I've rolled all trees to -rc2 and processing mripard's drm-misc-next pr right now
08:54sima: with that everything pending should have been taken care of and it's back to you
08:55sima: tzimmermann, re the use-after-free bug, I wonder whether helpers should clear the pointers after hw_done, to catch these bugs
08:56sima: but I'm also not sure whether that really holds for all drivers since even if you use helpers fully the rule is that both hw_done and flip_done together are the barrier, and not a single one alone
08:56sima: and flip_done generally happens from irq handlers and has it's entirely own refcounting for that reason to avoid big time lolz
08:57sima: so clearing in hw_done would be the right thing for most drivers, but I think not all, and later on we cannot clear the pointers safely in generic code anymore I think ...
09:00sima: airlied, in case you missed, there's a conflict in amdgpu between -rc2 and drm-intel-next, so pull request to sort that out would be good sooner I guess
09:01sima: agd5f, hwentlan__ jani rodrigovivi ^^
09:01sima: it's a minor one, but conflict due to one driver tree in another driver is a bit icky :-)
10:58calebccff: lumag: yes, it's just that the pipeline doesn't get initialised properly by msm_fb afaict?
10:59lumag: calebccff, I hadn't had any particular issues with 6.6. Do you have any additional details?
11:01calebccff: lumag: the display keeps the bootloader splash screen all the way until gdm loads. it should be replaced by the penguins with fbcon but it just never is. if i kill gdm then fbcon becomes visible and works perfectly fine
11:04babyfaceolder: For what I would found a company otherwise, if I were not knowing security of the systems, of course I know all the possible vulnerabilities, you think you are better than me? You are good at stalking and bragging with your porn on my territory only, and legal paychecks you never had, you rob money from others, me I do not like your presence nor I will ever pay you again.
11:14babyfaceolder: If the systems were remaining vulnerable to any of such simple attacks or intrusions, it would defeat the whole purpose of founding anything, sure I am aware.
11:15babyfaceolder: It's just the money I let robed from myself, was not a big deal financial ways to me, it was fair trade to get those people out, if they do not go, they will get charged.
11:16lumag: calebccff, which system are working on?
11:17lumag: also, if you have a remote access to the board, could you please mask the gdm and check whether the console appears in the end even w/o gnome?
11:18lumag: A captured debugfs/dri/0/state with the disabled gdm3 might also be interesting
11:18lumag: and a dmesg, of course :-D
11:27tzimmermann: sima, it certainly doesn't hurt
11:27tzimmermann: i'll look into fixing the actual bug
11:41sima: tzimmermann, thx
15:24eric_engestrom: airlied: in mesa b38879f8c5f57b7f1802e you wrote "swrast vulkan requires gallium swrast"; is that still true? what kind of things are needed to be untangled to get lavapipe without llvmpipe? (and also, this is a minor interest of mine, so if it's a huge task you can just say that and skip all the details :P)
16:05elderbabyface: First you would see, that 128times128 register file of 64bit compressed values is easy to be stored. That means you have 128 banks each containing 128 registers, so the scaffold is at max at 16777216 that's 16millions only so 512 of such banks is maximum unsigned int at 4.2B, you can call them sectors and banks and registers, and indexing is done 128is max regidofaregbank, 128 is max sectorid of register bank and 128 is max bankidofsectors, and
16:05elderbabyface: there are two heads , very easy task to access those registers, but at first would you be able to calculate as to how much it stores? so storage is 256*128*128 1024digit values which is 4194304, so it totals at 4million, such formation is very easy to lay out, cause it has 256 digits for max value and 256 all free for indexing per inverse value, so register content is eliminate is taken as index-value, sector is taken as index minus sector,
16:05elderbabyface: where the interval is sector , and then two heads are taken as just additional 128 digits and their sectors alike, there is 128 digits free for whatever you want , reserved for aux, elias fano is claimed to be at 780k, so that is accommodating slightly more data, and is dead fast to access. in other words it's absolute maximum on 32bit arch 4.1 million 32bit compressed values.
16:16MrCooper: eric_engestrom: my understanding is that lavapipe is just glue between the Vulkan API and llvmpipe, so not sure "lavapipe without llvmpipe" makes any sense
16:17jenatali: That matches my understanding
16:18eric_engestrom: ack, but in that case can't we just not generate the .so bits for gallium and drop the constraint?
16:18karolherbst: yeah..
16:18karolherbst: lavapipe isn't a driver
16:18karolherbst: it's a frontend
16:18karolherbst: and llvmpipe is the only driver supported
16:19karolherbst: eric_engestrom: what so file?
16:19karolherbst: you mean the dynamic pipe-loader one?
16:19eric_engestrom: swrast_dri.so (or whatever it's called)
16:19eric_engestrom: (and its entrypoints and all that)
16:19karolherbst: that's the gallium megadriver
16:20eric_engestrom: yup
16:20eric_engestrom: but that's my point
16:20karolherbst: what would be the point of dropping it?
16:21eric_engestrom: `-D vulkan-drivers=all -Dgallium-drivers=` feels like it should be allowed, and if all we need to do is not include the swrast entrypoint and not generate the hardlink for the so, that feels reasonable to me?
16:21karolherbst: if you don't want OpenGL support, you have to disable all of OpenGL
16:21eric_engestrom: what do you mean?
16:21karolherbst: swrast_dri.so is the driver part of the gl loading mess
16:22karolherbst: it has nothing to do with lavapipe
16:22karolherbst: every frontend (as long as I'm not mistaken) except clover is using the state pipeloader, which means the driver gets linked in statically
16:23karolherbst: `/usr/lib64/dri/swrast_dri.so` isn't the llvmpipe driver, it's the dri OpenGL thing which gets loaded based on the requested OpenGL driver (like X says "the gl driver is called $driver_dri.so")
16:25karolherbst: and I think libEGL_mesa.so also uses that
16:25karolherbst: (and libGLX_mesa.so.0)
16:26karolherbst: anyway... try disabling all GL support and see if the dri/*_dri.so files disappear, becasue that's generally the way they get pulled in
16:27eric_engestrom: "disabline all GL support" -> you mean `-D gallium-drivers=`, right?
16:27karolherbst: no
16:27karolherbst: glx/egl/gles/etc...
16:27eric_engestrom: ah
16:27karolherbst: you will have to keep gallium-drivers=swrast no matter what
16:27karolherbst: otherwise lavapipe won't work
16:28eric_engestrom: shouldn't that be managed "under" the meson options?
16:28karolherbst: so how the static pipeloader works is, that the frontend links against all drivers it wants to work on. Lavapipe only links `driver_swrast`. But if you disable swrast it will just error out at runtime
16:28eric_engestrom: ie. the user passes `-D vulkan-drivers=all -D gallium-drivers=` and internally we include the llvmpipe parts needed for lavapipe
16:29karolherbst: eric_engestrom: why? gallium-drivers isn't GL specific
16:29karolherbst: it's for _all_ frontends
16:29eric_engestrom: ok, maybe I misunderstand gallium<->gl then
16:29eric_engestrom: ok
16:29karolherbst: gallium-drivers decides what vaapi/vdpau/rusticl/clover/stmesa/etc... support
16:30eric_engestrom: and gl/gles, right?
16:30eric_engestrom: but yeah ok, it's more than just gl
16:30karolherbst: yeah
16:30eric_engestrom: I think it makes more sense to me now
16:30eric_engestrom: thanks karolherbst !
16:30karolherbst: np
16:30eric_engestrom: (and MrCooper!)
16:37jenatali: eric_engestrom: If you were building both lavapipe and a different gallium frontend (like GL), you'd want one copy of llvmpipe on disk, not two, so it makes sense for lavapipe to dynamically link to the gallium megadriver instead of statically linking in another copy of llvmpipe
16:38karolherbst: jenatali: we don't dynamically link gallium drivers (except clover)
16:38jenatali: I guess you could theoretically special-case the situation where you weren't building gallium, but meh
16:38jenatali: karolherbst: All I meant was that the implementation is in a different so
16:39karolherbst: jenatali: it's not
16:39jenatali: Wait really? So lavapipe has a statically linked copy of llvmpipe?
16:39karolherbst: yes
16:39karolherbst: as every gallium frontend except clover
16:39jenatali: That... seems wasteful, but okay
16:39karolherbst: well
16:39karolherbst: it increases performance
16:40karolherbst: function calls across so files apparently are expensive
16:40jenatali: Debatable
16:40jenatali: You're already calling across the pipe interface
16:40karolherbst: so we've added megadrivers
16:40karolherbst: and the difference was significant
16:40jenatali: There's no perf difference if the pipe interface splits a module boundary
16:40karolherbst: jenatali: it's all statically linked
16:40karolherbst: like everything
16:41jenatali: Maybe the call to initialize the pipe interface is, but pipe-> calls look up a function pointer from a table. Whether that pointer is into the same module or a different one doesn't matter
16:41karolherbst: well.. somebody did benchmark it and the difference was significant
16:42Company: are compilers smart enough to figure out that the function pointer is always the same?
16:43Company: I would guess "no" but I don't know
16:43karolherbst: it doesn't matter, we've done the numbers, the numbers mattered, so we went with megadrivers
16:43Company: I suspect the benefit is more a cache thing where the code on both sides of the boundary lives close
16:43Company: I don't doubt the numbers, I'm interested in why the numbers came out thaat way
16:44karolherbst: here is the initial submission: https://lists.freedesktop.org/archives/mesa-dev/2013-September/045493.html
16:44Company: so I can think about more static linking
16:44karolherbst: might want to talk with anholt about details here
16:45Company: I will definitely watch the video
17:53airlied: eric_engestrom: hopefully question was sufficiently answered :-)
17:54airlied: i did consider lvp without using gallium api and sharing code instead, but it was messier
18:24llyyr: does anyone want to press a button on !25930?
18:55DavidHeidelberg: llyyr: done :)
18:55llyyr: thanks!
20:49Company: I just noticed that Mesa doesn't seem to complain in GLES if I use the wrong format/type in glTexSubImage2D() - but nvidia raises GL_INVALID_OPERATION as per spec
20:50Company: and GTK just switched to GLES and has remaining cases of that
20:50Company: and I wonder how to debug those - with a Mesa driver
22:33slim_: hi
22:33slim_: anyone online?
22:42slim_: does anyone knows how to type??
22:44slim_: why is this sever so dead?
22:45emersion: please calm down. it's not dead, but don't expect volunteers to be available for you 24/7
22:45emersion: instead of asking whether the channel is dead, i'd suggest asking your question
23:24lumag: pinchartl, Gracious ping regarding https://patchwork.freedesktop.org/series/122584/. You had some concerns about one of the previous iteration.
23:25lumag: I'd really like to get rid of the DRM code spread over USB and SoC/qcom subsystems.