ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Haaninjo has quit [Quit: Ex-Chat]
co1umbarius has joined #dri-devel
<benjaminl>
so I'm debugging some CTS failures in NVK, and I'm pretty sure I've determined that the gpu is entirely skipping global ld instructions on fragment shader helper invocations
<benjaminl>
looking through envytools and the ptx docs, the only thing I can find that's supposed to behave like this is texture instructions that have 'liveOnly = 1' set
columbarius has quit [Ping timeout: 480 seconds]
<benjaminl>
anybody know if this is a known/expected thing?
itsmeluigi has quit [Quit: Konversation terminated!]
<airlied>
benjaminl: yes there is a kernel path
<airlied>
patch that has been floating around for ages
<benjaminl>
oh, lol
<benjaminl>
I would not have expected this to be a kernel thing :)
<dottedmag>
Has anyone got ccls or clangd working on Mesa repository (or any other LSP server)? ccls just hangs for me, and clangd does not understand #if properly.
kj has quit [Quit: leaving]
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
kj has joined #dri-devel
<pq>
airlied, I'm sure the email I sent was not addressed to your skynet.ie address, yet googlemail still complains to me that cannot deliver to skynet.ie. Do you know what that is about?
<pq>
airlied, it was addressed to your linux.ie though.
<airlied>
yeah linux.ie is mostly dead
<pq>
should I just drop it from the cc list when I see it?
vliaskov has joined #dri-devel
sarahwalker has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
<dottedmag>
Do non-DRI backends for libgbm exist? Open source?
karolherbst has joined #dri-devel
<emersion>
dottedmag: there is minigbm but AFAIK it's still a full reimpl instead of a backend
<emersion>
apart from that, closed-source NVIDIA
<dottedmag>
Got it, thanks
<emersion>
there may be others, but i'm not aware of any
<pq>
tnt, if your desktop environment does not automatically react to hot-unlpug by disabling the unplugged output, I might even call that as expected, though not good, behaviour: a video signal can conceptually be emitted into a disconnected connector, and I'd guess that usb-c in HDMI(?) mode might not do anything else at the same time.
<tnt>
pq: there is no DE basically raw X almost. But thing is, I don't want the output to get disabled/off because then windows that were there will be moved to the remaining active output ... Ideally I just want them to not be visible until I either reconnect or I explicitely turn it off. And that's what it does on my old laptop using the 'intel' DDX. The output would be turned off but then everything that was on it would end up
<pq>
dottedmag, did you arrange clangd to find compile_commands.json for your build dir? I usually just symlink that file from build dir to project root, but never tried with Mesa.
<dottedmag>
pq: I did not, I will try. I guessed it picked it up by itself, as _some_ of things worked.
rasterman has joined #dri-devel
<pq>
dottedmag, I think it can guess a lot, but not the build config.
<dottedmag>
I'm trying to navigate Mesa from MacOS, and that means libgbm is disabled, so it does not even appear in compile_commands.json :-/ C preprocessor is a gift that keeps on giving... headaches.
junaid has joined #dri-devel
<pq>
tnt, I can imagine how that could be caused by intel vs. modesetting DDX driver, but I don't know for sure. (It seems your long irc lines might be getting truncated.)
junaid has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
<tnt>
pq: yeah, probably, but other drivers (nvidia and amd) have a not far off behavior for the hdmi/dp output. They don't move it to a VIRTUAL output, but they just say disconnected but then they correctly detect when I replug ...
<tnt>
which here isn't the case for the intel driver.
<dottedmag>
I think I understand now how libgbm works. Creating a buffer delegates to Mesa src/loader that loads a dri/<driver>_dri.so from Mesa and calls create_resource_with_modifiers in that driver. Is this a correct rough approximation?
<dottedmag>
(and yes, there is a shortcut in libgbm to create a dumb buffer, and a loadable backends in there etc)
<emersion>
yes
<emersion>
then each driver has a driver-specific IOCTL to allocate memory
<DavidHeidelberg[m]>
Hazematman: hmm, I noticed it was failing after Debian 12 uprev, bit I see there is more info in the logs now
<karolherbst>
dcbaker: sooo.. there is a weirdo annoying rustup + meson problem. I suspect that meson checks if rustc changed, but with rustup it might not, even if the binaries get updated :')
JohnnyonFlame has quit [Read error: Connection reset by peer]
Surkow_ has quit [Remote host closed the connection]
<jenatali>
In an ideal world I'd debug it but I don't have time atm
<jenatali>
I really need to actually debug all of the failures in that baseline and get issues filed on them...
FireBurn has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
<alyssa>
Yea..
<alyssa>
I don't think any driver passes piglit.
<jenatali>
Yeah but we have a lot more fails than most
<alyssa>
yeah, fair
yuq825 has quit []
bbrezillon has quit [Ping timeout: 480 seconds]
bbrezillon has joined #dri-devel
kzd has joined #dri-devel
sima has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
<alyssa>
in practice, how many patches do apps draw with tess?
<alyssa>
like, is the expectation that you draw just a few patches but they generate 1000s of vertices?
<alyssa>
I'm trying to figure out the memory budget
<alyssa>
with the obvious limits and packing, you get a worst case of ~80KiB per patch for the tessellator output
<alyssa>
If the app draws a dozen patches, that's totally fine
<alyssa>
if the app draws 100,000 patches... that's less ok
junaid has joined #dri-devel
Company has joined #dri-devel
<Company>
yesterday I played with the GTK Vulkan stuff on my desktop, and my AMD gave me these memory properties: https://gitlab.gnome.org/-/snippets/5909 - and that got me wondering about how I'm meant to pick the memory type to put my textures into
<Company>
because there's only 2 heaps - GPU and CPU memory I suppose - but 11 different types
<Company>
do I just pick the first one that has the flags I want? Do I look for an exact match?
<Company>
why are there even 11 types - I assume it's not just to confuse people
bmodem has joined #dri-devel
sravn has joined #dri-devel
<MrCooper>
Company: it's mainly about the heap (device-local VRAM vs system memory) & propertyFlags, not sure what the types 'usable for' nothing are about though
<Company>
what's the technical difference between those types, say types 0 and 3, the DEVICE_LOCAL vs DEVICE_LOCAL | HOST_VISIBLE?
lemonzest has quit [Quit: WeeChat 3.6]
<Company>
I suppose one does extra work to set up page table entries or something?
<MrCooper>
both are accessible by the GPU; the latter is directly accessible by the CPU as well, the former not
<Company>
yeah, I got that
<Company>
but why would I ever choose the one with less features?
<CounterPillow>
because it's potentially faster
<Company>
so my assumption should be fewer features = faster?
<MrCooper>
some device-local VRAM can be physically inaccessible to the CPU due to PCIe BAR restrictions
<CounterPillow>
Your assumption should be "pick what I actually need"
<Company>
MrCooper: shouldn't that end up in 2 heaps then?
rz_ has joined #dri-devel
<MrCooper>
dunno
<Company>
CounterPillow: so that means "don't pick the first one that includes the flags I want, instead search for the memory type that's an exact match" I guess?
junaid has quit [Remote host closed the connection]
<CounterPillow>
I'd look for an exact match, and then widen from there, but I'm no expert on this at all (someone who writes Vulkan drivers should probably chime in)
<Company>
I suppose making it 2 heaps is bad because if you only care about DEVICE_LOCAL and only use type 0, then you'd be locked out of the 2nd heap
<MrCooper>
something to keep in mind is that any CPU reads (even implicitly for read-modify-write) from device-local VRAM will send performance down the drain
lemonzest has joined #dri-devel
Duke`` has joined #dri-devel
<Company>
well yeah, I'm not trying to do fancy stuff (like revivve cairo-gl ;))
<Company>
I'm just trying to understand what's going on so I don't do stupid things
rz has quit [Ping timeout: 480 seconds]
<Company>
I was quite proud that the Vulkan stuff I did on intel only wasn't just working flawlessly on this AMD, it was also fast
<MrCooper>
well, that's one stupid thing to avoid :) in general, it's safer to stay away from device-local VRAM if there's any CPU access, unless you're 100% sure it's one of the rare cases where it's slightly faster than system memory
<Company>
my assumption so far was to only vkMapMemory() if it's HOST_CACHED
<MrCooper>
certainly if there's a non-0 chance of any CPU reads
<MrCooper>
if not, uncacheable might be slightly faster
<Company>
the question is what to do about texture uploads
<Company>
so I use a custom buffer and CopyToImage()
<Company>
or do I map the image's memory directly?
<Company>
(is "upload" the term used for copy-to-vram even? Or is that just something we use in GTK?)
<emersion>
"upload" is somewhat commonly used
<mattst88>
karolherbst: did you make that MR?
frieder has quit [Remote host closed the connection]
sarahwalker has quit [Remote host closed the connection]
eukara has quit [Remote host closed the connection]
<tzimmermann>
jani, i'm not involved in any of the sound code. do what ever makes the most sense
cmichael has quit [Quit: Leaving]
junaid has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
junaid has quit [Read error: Connection reset by peer]
orbea has quit [Remote host closed the connection]
orbea has joined #dri-devel
i509vcb has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
nchery is now known as Guest5587
nchery has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
<dcbaker>
karolherbst: Yeah, I've looked into it. There's not much we can do on the Meson end because of the way rustup is designed. They wrap all of the tools, and that wrapper never gets updated, so from ninja's point of view nothing has changed. This would require some kind of rustup change, either in the wrapper itself, or with some sort of file ninja can watch. Say, a consistent file on disk that just contains the toolchain version
<karolherbst>
dcbaker: mhh.. I suspect that's not feasible becasue rustup also allows you to set per directory overrides
<karolherbst>
there is a ~/.rustup/settings.toml file which encodes all of this, but things might change after the ninja project was created
rasterman has quit [Quit: Gettin' stinky!]
smiles_1111 has quit [Ping timeout: 480 seconds]
<dcbaker>
I mean, in the worst case if there was some kind of token locally like .rustup_version we could check the sourcedir root for that, but for this to be at all reliable it would have to be something that Meson and Rust agreed on
<karolherbst>
I suspect a global `rustc --version` check is out of question?
<karolherbst>
could you have an always running target writing that output to a file and ninja only retriggers job based on the content changing?
<bl4ckb0ne>
thanks again for the feedback on !18847 zmike, sorry it took so long to answer
FireBurn has quit [Read error: Connection reset by peer]
idr has joined #dri-devel
nchery is now known as Guest5592
nchery has joined #dri-devel
Guest5592 has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
nchery has quit [Ping timeout: 480 seconds]
thellstrom1 has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
<dcbaker>
karolherbst: that makes a no-op rebuild suddenly not very no-op. In the past Jussi and others have been very much of the opinion "no-op builds *must* be no-op, unless as project explicitly creates an always_dirty target"
<dcbaker>
I wonder if this is something that I could convince rustup to do for us... I can file a bug and see what they think
junaid has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
<airlied>
pq: yes drop it on sight
nchery has quit [Ping timeout: 480 seconds]
jagan_ has quit [Remote host closed the connection]
rz_ has quit []
Guest5510 has quit []
Danct12 has joined #dri-devel
Dr_Who has quit [Read error: Connection reset by peer]
<karolherbst>
like if 128 is the normal block size, 127 the last block and you have 16 blocks, the last block doesn't run from id 1920 (15 * 128), but rather from 1905 (15 * 127)
rz has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
<karolherbst>
but I think this will require changing the llvmpipe shader ABI?
ultra has quit [Ping timeout: 480 seconds]
ultra has joined #dri-devel
<karolherbst>
though I think this can be easily be done by providing both values: block and last_block and the offsetting is always done with block or something...
<karolherbst>
dunno... didn't really looked into how all that actually works yet
ngcortes has joined #dri-devel
djbw has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
<karolherbst>
mhhhh
<karolherbst>
this is all part of system value lowering...