yrlf has quit [Read error: Connection reset by peer]
yrlf has joined #dri-devel
<mareko>
do people prefer a per-instruction (tex and intrinsic) CAN_SPECULATE flag, or just shader_info::speculating_can_page_fault?
soze has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
<mareko>
are there any ops where CAN_REORDER doesn't mean CAN_SPECULATE?
<mareko>
non-memory ops, that is
Nasina has joined #dri-devel
haaninjo has quit [Quit: Ex-Chat]
kzd has quit [Ping timeout: 480 seconds]
epoch101_ has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
Company has quit [Quit: Leaving]
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
u-amarsh04 has quit []
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
u-amarsh04 has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
alane has quit []
alane has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
soze has joined #dri-devel
u-amarsh04 has joined #dri-devel
soze has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
soze has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
soze has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
ADS_Sr has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
dsimic is now known as Guest11541
dsimic has joined #dri-devel
Guest11541 has quit [Ping timeout: 480 seconds]
soze has joined #dri-devel
glennk has joined #dri-devel
krushia has quit [Quit: Konversation germinated!]
soze has quit [Ping timeout: 480 seconds]
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
krushia has joined #dri-devel
Nasina has joined #dri-devel
soze has joined #dri-devel
soze has quit [Ping timeout: 480 seconds]
soze has joined #dri-devel
i-garrison has quit []
soze has quit [Ping timeout: 480 seconds]
gnuiyl has quit [Remote host closed the connection]
gnuiyl has joined #dri-devel
yrlf has quit [Ping timeout: 480 seconds]
mwalle has quit [Quit: WeeChat 3.8]
i-garrison has joined #dri-devel
NiGaR has quit [Read error: Connection reset by peer]
NiGaR has joined #dri-devel
yrlf has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
soze has joined #dri-devel
GreaseMonkey has quit [Read error: Connection reset by peer]
GreaseMonkey has joined #dri-devel
aibackendsnow has joined #dri-devel
itoral has joined #dri-devel
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
soze has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
dolphin has joined #dri-devel
sima has joined #dri-devel
mvlad has joined #dri-devel
mwalle has joined #dri-devel
<aibackendsnow>
have you ever noticed as to how adders are at all implemented inside the hardware blocks? it's as genius as possible. even hardware does nothing digit by digit, the implementation is 8 full or half adders on 64bit hardware, so probability theory riddles out 4.2B combinations there indeed on 32bit, cause you are at 0 or 1 to start with as all over again as like uncertainty was restarted
<aibackendsnow>
every time, but hardware allows to fix higher valued combinations per power as equal probabilities too not only due to it's high entropy design, in fact when we used this say Mart's or Cornells encoding in hardware things might turn out slimmer even in hw, but that would not be very secure, very fast would the ISA or sw command stream get reverse engineered and there would be no
<aibackendsnow>
alternative. Regardless of what your demands are here, no one is going to respect them since you were wrong I was correct. I have not coded the compiler, but the work is straightforward there. So today drones only need bayesian probability which essentially means it can have an easy ai backend on the onboard microcontroller or cpu. The backend gets drained by sensor data and it learns
<aibackendsnow>
itself on the fly as it was a human brain. War is lame stuff, but europes 8xx billion almost trillion dollars separated for artillery other munition and drones last which are cheap to manufacture, is quite a usably big sum in those terms, and Europe has all the capacity and skill to carry out militarization very fast. There is no question we could not combat russians and destroy their
<aibackendsnow>
lines altogether, but in the end do you want to destroy nations like Russians, they look like us don't they, they are smart too aren't they? There is no ultimate truth that Trump is so bad, he has his points too and Elon has them too. And elon supporting white races or cheering to them more, cause he is white, is also allowed position. Me i said i also am not racist, but in africa it's
<aibackendsnow>
often the danger part get's spotted, and primarly cause african tribe predators are not friendly nor intelligent enough, but this yeah never applied much to large and advanced black communities in united states , who very often can be very friendly and intelligent.
u-amarsh04 has quit []
sghuge has quit [Remote host closed the connection]
soze has joined #dri-devel
sghuge has joined #dri-devel
u-amarsh04 has joined #dri-devel
cascardo has joined #dri-devel
cascardo_ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
aibackendsnow has quit [Ping timeout: 480 seconds]
soze has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
fab has joined #dri-devel
frieder has joined #dri-devel
soze has joined #dri-devel
jfalempe has joined #dri-devel
soze has quit [Ping timeout: 480 seconds]
pepp has quit [Ping timeout: 480 seconds]
sgerhold has joined #dri-devel
apinheiro has joined #dri-devel
vliaskov__ has joined #dri-devel
vliaskov__ has quit [Read error: Connection reset by peer]
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
soze has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
kts has joined #dri-devel
sgruszka has joined #dri-devel
soze has quit [Remote host closed the connection]
rasterman has joined #dri-devel
vliaskov has joined #dri-devel
jkrzyszt has joined #dri-devel
soze has joined #dri-devel
<mlankhorst>
sima: I'm looking into preventing overcommit on xe, and there are cases that we want to ensure sysmem is not evicted too. For vram, we can use dmem cg, but how should we handle system memory?
<K900>
]'[
<K900>
Oops
<K900>
Cat says hit
<K900>
*hi
soze has quit [Ping timeout: 480 seconds]
haaninjo has joined #dri-devel
soze has joined #dri-devel
warpme has joined #dri-devel
<ella-0>
Hi. Does mesa have a clear policy on the use of LLMs and other AI "assisted" developer tools when contributing?
feaneron has joined #dri-devel
mripard has joined #dri-devel
Nasina has quit [Remote host closed the connection]
Company has quit [Remote host closed the connection]
Company has joined #dri-devel
Company has quit [Remote host closed the connection]
Company has joined #dri-devel
<sima>
mlankhorst, need to allocate memory with GFP_ACCOUNTING or whatever the exact flag is
<sima>
and then make sure we account against the right memcg
<sima>
and all behind a kconfig/module_opt opt-in so we don't break anything existing
kts has quit [Ping timeout: 480 seconds]
<sima>
at least that's what I thought the consensus was with all the discussions with tejun and others
<mripard>
I guess it's kind of related to the patches I sent last week too, but how we should track system memory isn't really clear to me
<mripard>
for GEM, if we track differently the memory allocations between backends, it will look super weird and be a nightmare to configure
<mripard>
plus the fun things like the driver has changed backends, so now your allocations aren't tracked by the same cgroup anymore
<mripard>
so I really think we should be allocating all buffers through dmem, but then it's also weird to allocate something from GFP but not have it show up in memcg I guess
<mripard>
(plus, concepts like region size in dmem doesn't map super well to the main DMA allocator for example that doesn't really have a fixed size AFAIK)
haaninjo has quit [Quit: Ex-Chat]
warpme has quit []
<sima>
mripard, we need to allocate all buffers through memcg GFP_ACCOUNT
<mripard>
sima: it doesn't make sense for some of them
<sima>
iirc tejun has been pretty clear that dmem should be only for stuff that memcg wouldn't track
<sima>
mripard, for cma it might make sense to track it in both memcg and a cma limit (which could be dmem, not sure)
<javierm>
sima: cma is not really system memory since that region is carved out IIUC
<mripard>
Then dmem is useless to me I guess. I wished I had learned about that like a year ago or something.
warpme has joined #dri-devel
<sima>
javierm, it's not carved out, it's shared
<mripard>
ish
<sima>
and relies on memory migration to throw stuff out
<mripard>
it can be reused for cache
<sima>
yeah it's only for GFP_MOVEABLE
<mripard>
that's it
<sima>
anon memory too I thought
<sima>
essentially anything that try_to_migrate() can get moving
<mripard>
oh right, maybe
<javierm>
sima, mripard: ah, I see
<sima>
(exceptions apply, which is where the fun starts)
<mripard>
but still, it's not shared-shared :)
<javierm>
I didn't know that. I thought could only be used for cma allocs
<sima>
mripard, yeah but in really big machines there's entire numa nodes which are GFP_MOVEABLE only
<sima>
to allow hotunplug
<sima>
and those aren't accounted differently in memcg either afaik
<sima>
javierm, nah that was the old carveout, and people didn't like it because it wastes memory when not in use
<javierm>
sima: got it
bolson has quit [Ping timeout: 480 seconds]
<mripard>
sima: eventually, it's a matter of API and what you allocate your memory from
<mripard>
with heaps, v4l2 dma contiguous backend, or GEM DMA backend, you would allocate the buffer from dma_alloc_attrs
<mripard>
and you have no guarantee that it will be in A) RAM, B) under Linux control
<mripard>
and rolling a dice to know in which cgroup a call to dma_alloc_attrs is going to be tracked doesn't sound great
<sima>
hm right getting GFP_ACCOUNTING in there could be really tricky
<sima>
mripard, I guess it would need to be a new dma_alloc attr so you get accounting, if it's a struct page backed memory range
<sima>
since you might not even get cma but plain discontig pages, made contig with the magic of iommu
<mripard>
I don't see what's wrong with just accounting it in both
<mripard>
reworking dma_alloc_attrs to get pages / folios (and easier accounting) was something I discussed in my series last week to
<mripard>
but that's kind of separate from the discussion about how we want to account it
<mripard>
and I think any solution based around "CMA/dma-coherent goes one way, GFP the other" is not going to work
<sima>
mripard, but then allocating shmem pages in dmem feels very wrong imo
<mripard>
because then, if we configure our system to limit the dmem allocations, and then we lose that accounting over an upgrade, it's a UAPI regression
<mripard>
and all we need to do to trigger it is to merge a patch switching GEM backends, and we merged plenty of those
guludo has joined #dri-devel
<Company>
mareko: since you asked yesterday: I tested my benchmark on AMD - it's 6500, so gen 10.5 I think - and I get 1650fps with radeonsi and 1100fps with zink. So it's not as bad as with Intel, but still bad
<Company>
benchmark is GSK_RENDERER=ngl GDK_DEBUG=no-vsync GSK_DEBUG=full-redraw gtk4-widget-factory - and I run it on F42, so Mesa 25.0 and GTK 4.18
Nasina has quit [Read error: Connection reset by peer]
Lynne has quit [Read error: No route to host]
Caterpillar has joined #dri-devel
warpme has quit []
Nasina has joined #dri-devel
Nasina has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
<sima>
mripard, yeah that's why I'm not a big fan of accounting cma as dmem
<sima>
it's just memory, that's where it physically is, and if we change the allocator that fact wont change
<sima>
but if you account it as dmem then there's all the fun like "so ... userptr"
<sima>
and similar things
<sima>
way back I thought special dmem for all system memory gem allocations would be good, but tejun convinced me that the corner cases are a bit too awkward
<sima>
mripard, and do we really have that many changes of dma vs shmem backends in drivers? I'd assumed that's a hw constraint
<sima>
or are people picking the dma backend for lack of knowledge?
krei-se has quit [Ping timeout: 480 seconds]
<javierm>
sima: it also happens in the other direction IIRC, people using the GEM shmem backend but then the driver switching to GEM DMA to avoid shadow buffering
<sima>
hm
krei-se has joined #dri-devel
<sima>
well this wouldn't be an issue if dmem isn't used for accounting of either still
<sima>
I think the one that's awkward is switching from ttm to shmem for some of the tiny vram cards we have
<sima>
but then I'm not sure people really care that much about that 4M framebuffer, if it's even that large
ADS_Sr has quit [Remote host closed the connection]
ADS_Sr has joined #dri-devel
<sima>
mripard, javierm I'm also not super worried about regressions at the fringes, because by default we don't enforce any limits
<sima>
so even if we do have a regression I think there's a small chance we'll get an actual bug report
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
<mripard>
sima: if we don't account CMA, then we shouldn't account any heap or similar regions
<mripard>
in which case, memcg == dmem
<sima>
why memcg == dmem?
<mripard>
if we account only system memory in dmem, what's the point
<sima>
we don't account system memory in dmem at all
<sima>
only vram or well device memory
<sima>
that was the point of dmem
<mripard>
what do you call "device memory" ?
<sima>
stuff that's not tracked by memcg essentially
<sima>
*possibly tracked
<mripard>
this is.. worse ?
<sima>
so "doesn't have struct page or is a zone_device range"
<sima>
how so?
<sima>
btw gtg now, but maybe chat with mlankhorst about this
<mripard>
going back to dma_alloc_attrs, so memory region to allocate from are set in the DT, for that one device
<sima>
since I thought we had pretty solid agreement that dmem is not going to track anything in system memory
<mripard>
so for one particular device, on the same platform, using the same driver and kernel, you might get dmem or memcg accounting?
<sima>
yeah
<mripard>
how is that remotely workable for distros?
<sima>
I mean, that's already the case for all the big gpu drivers
<sima>
if it's igpu, it's entirely memcg
<sima>
if it's dgpu, it's dmem + overflow stuff tracked with memcg
<mripard>
AMD at least doesn't do any tracking
<sima>
I don't think distros can set limits for this realistically
<robmur01>
the problem with dma_alloc is that the caller must assume it's dmem and treat it as such, but under the hood it may well not be :(
<sima>
ok really gtg now, ttl
<robmur01>
mripard: BTW I think I saw you replied, will catch up on the thread later
Nasina has joined #dri-devel
ADS_Sr_ has joined #dri-devel
ADS_Sr has quit [Read error: Connection reset by peer]
Nasina has quit [Read error: Connection reset by peer]
pq has quit [Quit: brb]
pq has joined #dri-devel
warpme has joined #dri-devel
ADS_Sr_ has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
itoral has quit [Remote host closed the connection]
Nasina has joined #dri-devel
nerdopolis has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
pepp has joined #dri-devel
ADS_Sr has joined #dri-devel
warpme has quit []
ADS_Sr has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
kzd has joined #dri-devel
ADS_Sr has joined #dri-devel
asrivats_ has joined #dri-devel
viric has joined #dri-devel
<mripard>
sima: if distros can't use it, I'll go back to what I was saying then. dmem is useless to me, I've wasted my time, and we still have a problem to solve.
odrling has quit [Remote host closed the connection]
<calico>
k I just wanted to make sure I ended to the right place before posting my copypaste question
<calico>
Here's an issue I'm getting on my SolidRun HC LX2 which has a Radeon RX 550 GPU plugged in into the PCIe 8X port. Here's some pics of the issue: https://imgur.com/a/KyAHnYd
<calico>
At the time (2-3 years ago), the only existing patch was that one made by jnettlet for Mesa (from SolidRun):
<calico>
So I applied both two (memcpy + dri conf), restarted the PC and it changed nothing.
<calico>
According to ld.so man, I should add this "/usr/lib/aarch64-linux-gnu/libmemcpy.so" into "/etc/ld.so.preload" in order to override the glibc memcpy and I htink I should put the dri conf here: /usr/share/drirc.d/01-honeycomb-x11.conf
<calico>
So, well, I don't know what I did wrong. It seems to work for both jnettlet and for other guys in the SR community ... even on Mesa 25
<psykose>
try `LD_DEBUG=all <someapp>` and check the preload is actually loaded
asrivats_ has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
<calico>
According to lsof it is indeed loaded ... but I could try LD_DEBUG=all again ...
<calico>
btw I also did some tracing with `strace -o log glxinfo` and the drirc.d conf seems to be loaded correctly.
dolphin has quit [Quit: Leaving]
ADS_Sr has joined #dri-devel
<calico>
psykose: anyway to pipe ld_debug output to file only?
<psykose>
2> file
asrivats_ has quit [Ping timeout: 480 seconds]
<calico>
also found LD_DEBUG_OUTPUT
jsa1 has joined #dri-devel
<calico>
will take a while
<alyssa>
mareko: per-instruction CAN_SPECULATE is useful to model cases when we know a given instruction is safe but we don't know that in general
<alyssa>
e.g. accesses to internal driver memory that is guaranteed to be there is SPECULATE even if we don't have that guarantee on app accesses
<alyssa>
honeykrisp uses this in a few places
<alyssa>
also for us speculating load/store is different from speculating textures
<calico>
psykose: result ... export LD_DEBUG_OUTPUT=ld_debug.txt; LD_DEBUG=all firefox shows libmemcpy.so is loaded http://0x0.st/8Qli.18567
<psykose>
yea looks fine
bolson has joined #dri-devel
<calico>
about the 01-honeycomb-x11.conf ... is there a way to force all apps to disable -GL_ARB_buffer_storage? like a "*"
<calico>
btw I'm on gentoo
<calico>
and I compiled libmemcpy myself through an ebuild
asrivats_ has joined #dri-devel
<psykose>
something like MESA_EXTENSION_OVERRIDE=-GL_ARB_buffer_storage probably
<psykose>
in env
<calico>
just added it into /etc/env.d/99mesa and it is still broken
<psykose>
is it actually set
<mareko>
alyssa: GL can speculate anything that's reorderable
<calico>
psykose: not sure it was set? but then I ran export MESA_EXTENSION_OVERRIDE=-GL_ARB_buffer_storage before starting Xorg and it work
<psykose>
work as in it fixed the issue or
<calico>
seems to have fixed it yes
<psykose>
what's the name of your xorg executable
<mareko>
alyssa: ddx/ddy can't be sunk into control flow, but can be hoisted (i.e. speculated) out of control flow
<calico>
psykose: there's /usr/bin/Xorg and there's also /usr/bin/X that points to /usr/bin/Xorg ...
<psykose>
that should work then afaik
<psykose>
not sure why executable="Xorg" didn't match it
jhugo has joined #dri-devel
<calico>
I'll try to add X to the conf file
<calico>
I shouldn't have to add Firefox and other apps to that file too right?
<psykose>
if you run `ps aux | grep X` do you see Xorg or X
<psykose>
i forget if symlinks resolve the name or not
<psykose>
a quick test says apparently no
<psykose>
which makes sense
<calico>
I see X ...
<psykose>
:)
<psykose>
well there you go
<calico>
damn
<calico>
three weeks lost for a freaking X
<psykose>
happens
<psykose>
and yeah you don't have to set it for apps pretty sure
<psykose>
so just another line in drirc should be the only change
<psykose>
or figuring out why stuff is using X on gentoo i guess, but that doesn't matter really
<calico>
just wish there will be a proper fix someday ...
<calico>
not just patching the memcpy and disabling the ARB buffer ...
cyrinux has joined #dri-devel
<calico>
but well, thank you a lot psykose you made my day
<K900>
I'm pretty sure this is attempting to work around hardware errata
<K900>
So the proper fix would require a new silicon stepping
<calico>
well ... my Shapphire RX 550 from 2017 costed about than CAD 200 or even less ... I don't think AMD nor Nvidia would make as cheap GPU anymore
<K900>
It's not the GPU that's the problem
<K900>
It's the SoC
<psykose>
reminds me of the altra pci errata
<psykose>
every generation of arm stuff has cursed pcie somehow :(
<calico>
I know the GPU not the problem ... I was just saying it's not worth putting a CAD 700$+ Radeon RX 5700 XT or wathever newer high end GPU on a SR HC LX2 workstation :P
<psykose>
that's actually 3 gens old now!
<psykose>
:D
<sima>
mripard, well if distros want to use it, then it also needs to work for amd and other big gpu
<sima>
and as-is dmem isn't enforcing yet
<sima>
plus I'm not sure how distros will use this with your design, you still need to somehow tell them which dmem a gpu is allocating from
<sima>
and how much there is
<sima>
feels like that's the missing part, once you can autoconfig first time around you can just do that again if the hw changes
<sima>
and I kinda cound "different dt" under different hw
<sima>
at least for regressions
<K900>
calico: I don't think the exact GPU matters here
<mripard>
sima: I agree about it needs to be more widespread, see the series in your inbox from last week
<K900>
It's very likely the PCIe interface that's broken
<K900>
So any GPU will have some sort of issue
<calico>
k
<sima>
mripard, yeah I'm behind on mail :-/
<mripard>
but if you say that we can't use it because it's very wrong, I'm not going to waste more time on it
<mripard>
also, "different DT" might also mean "different firmware"
rgallaispou has joined #dri-devel
<mripard>
which, again, can change over an upgrade
<sima>
I guess I need to catch up on mails and ponder this some
vliaskov has quit [Ping timeout: 480 seconds]
<calico>
btw on the same HW, I also got the GPU to fail to start on kernel 6.12.16 ... so I had to downgrade to 6.6: http://0x0.st/8QlW.txt (dmesg logs with colors)
woskova has quit []
<calico>
should probably post that on a radeon IRC channel if any
rsalvaterra has quit []
Caterpillar has quit [Quit: Konversation terminated!]
ADS_Sr has quit [Remote host closed the connection]
ADS_Sr has joined #dri-devel
woskova has joined #dri-devel
rsalvaterra has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
frieder has quit [Remote host closed the connection]
ptrc has quit [Remote host closed the connection]
ptrc has joined #dri-devel
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
Lynne has joined #dri-devel
Lynne has quit [Remote host closed the connection]
Lynne has joined #dri-devel
sgruszka has quit [Quit: Leaving]
anholt has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
anholt has joined #dri-devel
vliaskov_ has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
ybogdano has quit [Quit: Ping timeout (120 seconds)]
ybogdano has joined #dri-devel
jsa1 has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
soze has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
riteo has joined #dri-devel
feaneron has joined #dri-devel
guludo has quit [Quit: WeeChat 4.5.2]
soze has quit [Remote host closed the connection]
guludo has joined #dri-devel
soze has joined #dri-devel
fomys_ has quit []
tzimmermann has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
soze has quit [Remote host closed the connection]
soze has joined #dri-devel
<calico>
psykose (or any dev here): Could you help me as well with this? http://0x0.st/8Q0A.html ... Xorg refuses to start on my old ASUS A8V motherboard that has a Radeon HD 4650 AGP GPU (I also tried another HD 4650 to make sure)
<calico>
Some years ago I also tried older kernel versions and it was also broken.
<psykose>
no idea personally, never used one of those
<calico>
k but how can I track the failure easily ftrace?
<calico>
that thing have been broken since years
<calico>
the "radeon r600" should be supported by mesa btw
davispuh has joined #dri-devel
Caterpillar has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
rsalvaterra has joined #dri-devel
kts has joined #dri-devel
glennk has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
jsa2 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
jsa2 has quit [Ping timeout: 480 seconds]
jsa2 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
jsa2 has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
<benjaminl>
if I want to put a 64-bit int in driconf, is just making it a string and parsing it in the driver a reasonable option, or should I add a new type?
NiGaR has quit [Read error: Connection reset by peer]
NiGaR has joined #dri-devel
<alyssa>
mareko: "GL can speculate anything that's reorderable"
<alyssa>
I don't think that's true
<alyssa>
consider a dynamically indexed load_ubo, in an app that does not use robustness
<alyssa>
a shader like `if (bound_the_whole_ubo) { load_ubo(big index) }`
<alyssa>
and the app only binds the whole ubo sometimes
<alyssa>
if you speculate that load, you might get a page fault, depending on your hardware
<alyssa>
"but AMD's load_ubo is robust, it's fine" I hear you complain
<jenatali>
"does not use robustness" - is that a thing in GL?
<alyssa>
the whole point of can_speculate is communicating that precisely to NIR
<alyssa>
jenatali: yes, it's the default
<alyssa>
robust buffer access is only added in gl4.x/gles3.2
<jenatali>
Ooh
<alyssa>
in practice competent hw will be robust anyway because of d3d
<jenatali>
Right
<alyssa>
but it's not a spec requirement by any means
<alyssa>
and it's not true for loads of mobile hw
<jenatali>
Makes sense, I just had my "older API == robust" glasses on I guess
<alyssa>
it's more like "microsoft == robust" :p
<jenatali>
:P
mbrost has joined #dri-devel
<glehmann>
GL probably also cannot speculate bindless textures?
<mareko>
or even bindless textures can set it if the driver/hw is robust for it
<alyssa>
that misses a lot of cases, including cases that are per-instruction
<mareko>
examples?
kts has quit [Ping timeout: 480 seconds]
<alyssa>
ok, let's suppose you have SGPRs for the # of samples, and for the address of a table of sample positions
<alyssa>
and you lower load_sample_pos to load_global_constant(SGPR base address + math)
<alyssa>
that load can always be speculated, because we guarantee inside the driver that the sample position table is always present and filled out
<alyssa>
but (depending on API usage) none of the loads originating from the app can be
<alyssa>
only the driver knows
<alyssa>
hence why we have a per-intrinsic flag (and you're right that we need a per-tex flag too)
<mareko>
load_sample_pos lowering can clamp the address
<alyssa>
right, how does the driver tell NIR that it's clamped? by setting the can_speculate bit on that load
<mareko>
though load_global_constant would have a speculatable flag
<alyssa>
it already does.
<alyssa>
maybe I don't understand what you're proposing
<mareko>
can_reorder, and if there is access, then also can_speculate, are required of course
<mareko>
and then we just need to determine that in glsl_to_nir and other NIR generators
<mareko>
for that determination, options->robust_{regular, bindless} are required, and that should be it
vimproved has quit [Remote host closed the connection]
<mareko>
DXVK/DX9-11 can also set can_speculate on almost everything reorderable for RADV
<alyssa>
how would DXVK forward that information thru?
<alyssa>
new vk ext?
<mareko>
I guess
vimproved has joined #dri-devel
feaneron has quit [Quit: feaneron]
feaneron has joined #dri-devel
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
ADS_Sr has quit [Read error: No route to host]
Calandracas has quit [Remote host closed the connection]
ADS_Sr has joined #dri-devel
akhilpo has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
epoch101 has quit []
ADS_Sr has quit [Ping timeout: 480 seconds]
ADS_Sr has joined #dri-devel
fab has quit [Quit: fab]
Nasina has joined #dri-devel
ADS_Sr has quit [Ping timeout: 480 seconds]
<JEEB>
&1
mbrost has joined #dri-devel
mvlad has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
jessica_24 has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
ADS_Sr has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<glehmann>
alyssa: without descriptor indexing, descriptors have to be valid if they are statically used. so all accesses can be speculated
<glehmann>
well, if buffer/image access is always robust, which isn't required in core vk
Duke`` has quit [Ping timeout: 480 seconds]
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
<DemiMarie>
calico: the only feasible way to get the GPU to work on a platform with busted non-device PCI BARs is to map the BAR as device memory (I forget which type) to work around the hardware bugs, and then patch the kernel to emulate unaligned access
Nasina has joined #dri-devel
<DemiMarie>
calico: I don’t know if that is your specific problem
<DemiMarie>
Asahi might carry an out of tree patch for this as it would allow using eGPUs on Apple silicon. It is unlikely that such a patch would be accepted upstream.
<calico>
DemiMarie: you're talking about my gpu problem on the SR HC LX2?
<DemiMarie>
calico: one possible cause of GPU problems on ARM
<DemiMarie>
I don’t know if it is your particular problem as I know nothing about that particular SoC
<DemiMarie>
What I do know is that many Arm platforms do not support cache-coherent PCIe BAR memory
<calico>
k thx for the info ... will tell it to jnettlet
ADS_Sr_ has joined #dri-devel
ADS_Sr has quit [Read error: No route to host]
vliaskov has joined #dri-devel
<calico>
DemiMarie: what about my other issue with the Radeon HD 4650 AGP?
soze has quit [Ping timeout: 480 seconds]
Nasina has quit [Read error: Connection reset by peer]
<DemiMarie>
calico: if it is real AGP I would consider the hardware obsolete and replace it if possible
<DemiMarie>
AGP was a predecessor to PCIe
<DemiMarie>
actually no, but it is definitely obsolete
<calico>
I know ... but I'd like a lot to get the ASUS A8V of my childhood to work again :P
<DemiMarie>
calico: Software rendering would be the simplest thing to try
rasterman has joined #dri-devel
<calico>
uuuh ... I think the driver for cards of that era (2005-2010) is also broken for PCIe ones ...
<calico>
even though Mesa should support it
Nasina has joined #dri-devel
<DemiMarie>
Does software rendering work?
ADS_Sr_ has quit [Read error: No route to host]
ADS_Sr has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
riteo has joined #dri-devel
<calico>
you mean with radeon.modeset=0 or nomodeset? ... yes
Nasina has quit [Read error: Connection reset by peer]
guludo has quit [Quit: WeeChat 4.5.2]
iive has joined #dri-devel
NiGaR has quit [Ping timeout: 480 seconds]
NiGaR has joined #dri-devel
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
soze has joined #dri-devel
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]