ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Kayden has joined #dri-devel
<tlwoerner>
gfxstrand: let me know what email address you'd like to use, i'll add you to the mentors list, google will send you an invite, you'll need to agree to their terms, then i can add you to the 2023 roster
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
<karolherbst>
"Authentication error: expired or invalid token" this gsoc website :)
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
lemonzest has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
andremorishita has quit [Read error: Connection reset by peer]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<mohamexiety>
it's impressively bad, honestly
<mohamexiety>
keeps logging you out randomly too
<karolherbst>
maybe somebody should submit a gsoc project to google to "write a new gsoc webpage"
<mohamexiety>
ahahahaha yes
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
yuq825 has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
i509vcb has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
rsalvaterra has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
Company has quit [Quit: Leaving]
mohamexiety has quit [Quit: Konversation terminated!]
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
aravind has joined #dri-devel
efpwcdo^ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
jfoshea has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
mbrost has joined #dri-devel
Zopolis4_ has joined #dri-devel
bmodem has joined #dri-devel
bgs has joined #dri-devel
bmodem has quit []
dviola has quit [Quit: WeeChat 3.8]
itoral has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
shankaru has joined #dri-devel
digetx has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit [Ping timeout: 480 seconds]
mbrost has quit []
digetx has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
godvino has joined #dri-devel
lemonzest has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
fab has joined #dri-devel
srslypascal is now known as Guest9857
srslypascal has joined #dri-devel
Guest9857 has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
bmodem1 has joined #dri-devel
bmodem has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
kts has joined #dri-devel
bmodem has joined #dri-devel
bmodem1 has quit [Read error: Connection reset by peer]
kem has quit [Ping timeout: 480 seconds]
guru_ has joined #dri-devel
moa has joined #dri-devel
bluebugs has quit [Read error: Connection reset by peer]
oneforall2 has quit [Read error: Connection reset by peer]
mmenzyns_ has quit []
godvino has quit [Quit: WeeChat 3.6]
mmenzyns has joined #dri-devel
fab has quit [Quit: fab]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
kem has joined #dri-devel
bmodem1 has joined #dri-devel
bmodem has quit [Read error: Connection reset by peer]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
tursulin has joined #dri-devel
crabbedhaloablut has joined #dri-devel
fab has joined #dri-devel
rszwicht has joined #dri-devel
thenemesis has joined #dri-devel
pcercuei has joined #dri-devel
srslypascal has quit [Quit: Leaving]
srslypascal has joined #dri-devel
thenemesis_ has joined #dri-devel
thenemesis has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest9883
srslypascal has joined #dri-devel
<ishitatsuyuki>
if I'm changing a CI image and want to test the updated pipeline in CI, do I need to do it in the default branch of my fork?
Guest9883 has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
srslypascal is now known as Guest9887
srslypascal has joined #dri-devel
Guest9887 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest9889
srslypascal has joined #dri-devel
Guest9889 has quit [Ping timeout: 480 seconds]
sarahwalker has joined #dri-devel
swalker_ has joined #dri-devel
thaytan has quit [Ping timeout: 480 seconds]
swalker_ is now known as Guest9892
lemonzest has joined #dri-devel
rasterman has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
Surkow|laptop has joined #dri-devel
thenemesis has joined #dri-devel
loki_val has joined #dri-devel
thaytan has joined #dri-devel
crabbedhaloablut has quit [Ping timeout: 480 seconds]
thenemesis_ has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
loki_val has quit []
crabbedhaloablut has joined #dri-devel
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
jfalempe has quit [Quit: Leaving]
jfalempe has joined #dri-devel
ubitux has quit [Ping timeout: 480 seconds]
ffsd has joined #dri-devel
ffsd has left #dri-devel [#dri-devel]
ssdfdsf has joined #dri-devel
thenemesis_ has joined #dri-devel
thenemesis has quit [Read error: Connection reset by peer]
devilhorns has joined #dri-devel
djbw_ has quit [Read error: Connection reset by peer]
ubitux has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
agneli has quit [Remote host closed the connection]
agneli has joined #dri-devel
vliaskov has joined #dri-devel
thenemesis_ has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
thenemesis has joined #dri-devel
thenemesis_ has joined #dri-devel
thenemesis has quit [Remote host closed the connection]
ubitux has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
thenemesis has joined #dri-devel
thenemesis_ has quit [Read error: Connection reset by peer]
<pundir>
fwiw the crash is reported with a very very old version of popular benchmarking app, not sure if it is the application which is at fault here
kts has quit []
ssdfdsf has quit []
kts has joined #dri-devel
kts has quit []
devilhorns has quit []
<javierm>
tzimmermann: sigh, I just pushed that typos fix patch and I see you have comments. It seemed trivial enough...
<javierm>
tzimmermann: ah, I fixed one of your comments before applying indeed
thenemesis has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, happens. maybe ask him to type up an update
<javierm>
tzimmermann: it's OK. As mentioned I fixed before applying the issue you pointed out and for the other I belive a separate patch would be better anyways
_xav_ has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, do you remember danvet's series about fixing the vfio-aperture problems. we talked about it not too long ago. i wanted to see if this can be merged somehow
<javierm>
tzimmermann: I do, yes. There are some patches in that series that I believe you can just merge
<javierm>
I had that email in my TODO list to answer
<tzimmermann>
javierm, kind of. the bug comes up occationally and I wanted to fix it for a while.
MajorBiscuit has joined #dri-devel
pcercuei has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
<javierm>
tzimmermann: yeah, me too. I've answered to Samuel now
<tzimmermann>
javierm, let me see if i can get something to work. daniel's solution was that we only ever kick out aperture owners on the primary device. that seems fine
<javierm>
tzimmermann: something that I don't understand / remember, for these dual GPU machines, the aperture range is shared between PCI devices?
<tzimmermann>
javierm, IDK. how those that work?
<tzimmermann>
'does'
<tzimmermann>
javierm, IIRC the nvidia.ko modules picks up any framebuffer has been configured by efifb. even if the memory is on a different card
<javierm>
tzimmermann: yes, I think there are two differnt issues there and are somewhat related
<tzimmermann>
and if vfio releases the apertures of 'nvidia-hw-2', it will remove the efifb of 'nvidia-hw-1'
<tzimmermann>
nvidia.ko never tests if the console fb is actually within its PCI BARs
<tzimmermann>
i don't have the code here, but that's how i remember
<javierm>
tzimmermann: I don't think is nvidia-hw-{1,2} but integrated GPU (i.e: Intel iGPU) and discrete Nvidia GPU
<tzimmermann>
is was
<javierm>
tzimmermann: and you can connect different display outputs to different GPUs, i.e: DVI to intel and HDMI to Nvidia
<tzimmermann>
same problem then: nvidia-hw will pick up the efifb that operates on intel-hw. vfio then removes efifb when it forwards nvidia-hw to the guest system
<javierm>
and when people want to use vfio as you said, it will kick out efifb but I thought that only if matched the aperture range for the booting device
<tzimmermann>
ok, could be
<javierm>
tzimmermann: so if you pass-through the device that owns the efifb aperture, then is expected that it will go away right?
<javierm>
tzimmermann: because you just aperture_detach_devices(base, size), it shouldn't conflict...
<tzimmermann>
i'm reading through the bug report: sysfb_disable() removes the efifb device unconditionally
<tzimmermann>
even for the secondary card
<tzimmermann>
we only want to to that on the primary one
<danvet>
tzimmermann, yeah sorry still trying to find some bw to revisit that series
Arsen has quit [Read error: Connection reset by peer]
<danvet>
if you feel like there's a subset that you can land feel free to push them
Arsen has joined #dri-devel
<danvet>
and yeah part of it is that I didn't come up with a good idea for gam500 yet :-/
<tzimmermann>
danvet, no problem. i'll pick the easy patches and try to figure out something for the rest
<danvet>
javierm, I think vgaarb also does some work to keep track of the primary
<danvet>
tzimmermann, yeah but it's gma500
<danvet>
seems better to hide the ugly there than inflict it on common code
<javierm>
tzimmermann: so if we have have a SoC with two GPU / display controllers, then it may be a problem :)
<tzimmermann>
i'd just push calls to fb_is_primary device() into aperture helpers
<danvet>
tzimmermann, isn't that more or less dropping the cleanup?
<javierm>
danvet: it is indeed kicking out from our plate :)
<tzimmermann>
danvet, the cleanup has been controversial AFAICT
<danvet>
tzimmermann, I guess you could expose a __ helper just for gma500 to be able to open code whatever it needs
efpwcdo^ has quit [Ping timeout: 480 seconds]
<danvet>
tzimmermann, well the reason I've done it is that a lot of drivers just get it wrong
<javierm>
tzimmermann: now I remember that I proposed a patch that was if (primary) sysfb_disable(); but with a #ifdef CONFIG_X86 guard
<javierm>
and danvet said that it was horrible :)
<tzimmermann>
danvet, for gma500, we'd have to read the framebuffer range from HW regs. that's all
<tzimmermann>
the _pci aperture helper doesn't work
<danvet>
yeah hence the two calls or something
<tzimmermann>
so we kick out the full range
<javierm>
tzimmermann: I think the two calls proposed by danvet is the least bad option
<danvet>
I guess I really need to respin this thing instead of slacking on other stuff now :-)
<tzimmermann>
why are you so eager to chage gma500?
<tzimmermann>
change
<danvet>
it's the dead driver
Company has joined #dri-devel
<danvet>
keeps the special case away from new drivers
<danvet>
fewer changes for new drivers to be screwed up or inconsistent
<tzimmermann>
just let it kick the full range. no one cares about gma500
<danvet>
yeah, hence 2 calls
<tzimmermann>
it's not worse than some SoCs
<danvet>
one call to kick the full range
<danvet>
one call to kick the sysfb primary
<danvet>
which might be vgacon or some horror like that
heat_ has joined #dri-devel
<danvet>
and vgacon is pretty much the reason why we need to track pci primary, since that's really another word for "legacy vga decoding device"
<javierm>
tzimmermann, danvet: btw, why we have aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE) in the non-pci aperture_remove_conflicting_devices() ?
heat has quit [Read error: Connection reset by peer]
<javierm>
I guess there are some arches with VGA that are no x86 ?
<tzimmermann>
what's wrong with making sysfb_disable() conditional in aperture_remove_conflicting_devices() ?
<tzimmermann>
any be default, we kick out everything. for non-primary devices, we are more careful
<javierm>
probably we should use fb_is_primary_device() in aperture_remove_conflicting_pci_devices()
<tzimmermann>
javierm, that's what i've been advocating the whole time :)
<javierm>
tzimmermann: ah ok :)
<tzimmermann>
we want to do the full treatment by default. and if we detect a non-primary device, we ignore sysfb and vgacon. it's just that fb_is_primary_device() gets it wrong, because it returns 0 by default
<tzimmermann>
it should return 1 by default
<tzimmermann>
so that 'is-primary' is the default
<javierm>
tzimmermann: indeed
<tzimmermann>
my bios has options to disable the ROM shadowing. would the detection still work?
<danvet>
tzimmermann, hm grepping for vga_get shows some in-tree users: i915, qxl, virtio
<danvet>
tzimmermann, javierm I'm lost on what you're trying to tell me
<tzimmermann>
this appears to be yet another rabbit hole
<javierm>
danvet: in response to your either it's the primary or it's shadowed the rom
<javierm>
but just ignore me :)
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
<danvet>
javierm, well with primary I meant "whatever vgaarb thinks is the boot device" and then there's the shadow fb check on top
<danvet>
I have no idea whether that makes sense
<danvet>
maybe the shadow fb check should be moved into vgaarb?
<danvet>
but also this is probably an orthogonal can of worms
pendingchaos has quit [Ping timeout: 480 seconds]
<javierm>
danvet: right, that's what I understood and that's why I pointed to the comment of that vga_is_boot_device() function in vgaarb
<danvet>
javierm, fw device is another thing than rom shadowing?
<danvet>
s/?//
<danvet>
i.e. I'm not seeing the relevance ...
<danvet>
well it sometimes is the fw device, but it's kinda different things
<javierm>
danvet: I see. Got it, sorry for the confusion then
<javierm>
thought that were basically the same and we could replace that check for primary by a is_boot_device()
<danvet>
like rom shadowing is just a way to make the pci option rom on the vga device run faster
<danvet>
afaiui at least
<danvet>
which generally then installs the necessary handlers to provide the fw screen
<danvet>
which is then hopefully captured by the boot code correctly and passed on
<danvet>
javierm, yeah I think in theory they should always match
<javierm>
danvet: right, but if there are bios that disables that optimization as tzimmermann said, then it isn't a great heuristic
<danvet>
maybe it's just different heritage
<danvet>
javierm, yeah but we don't require both, just one or the other
<danvet>
I guess we could try deleting the shadow rom check and see whether anyone complains
<javierm>
danvet: agreed, hence my comment to use that is_boot_device() instead of the shadow rom check
<danvet>
and if they do, maybe better to fix up vgaarb to get that situation right
<danvet>
javierm, well atm it uses both
<danvet>
combined with an OR
<javierm>
danvet: ah! I finally understood your point. So then it should be safe to just drop that rom check
<javierm>
tzimmermann, danvet: guess the outcome of this conversation would be to realize that there are too many can of worms and just let nvidia loss its VT if doesn't register an emulated fbdev
<javierm>
and then will discuss again in a few months and have to remember all this :)
<tzimmermann>
:D
<danvet>
yeah I'm trying to at least respin the patch series and add a lot more comments
<danvet>
for the record and all that
<javierm>
danvet: that could be great
<tzimmermann>
danvet, there are too many different devices througout the code IMHO: primary default, default device, boot device, firmware device. it's hard to understand what they stand for
<tzimmermann>
javierm ^
<danvet>
tzimmermann, I'm tempted to just leave fb_is_primary_device as-is
<danvet>
since it's really just about what the default fbcon should be
<danvet>
unless you're thinking of cleaning up the x86 implementation to just use the vga boot device?
<danvet>
and drop the shadow rom check
<javierm>
tzimmermann: agree that's confusing
<tzimmermann>
danvet, i'm not going to touch this code
<tzimmermann>
it's too confusing for now
<danvet>
yeah same tbh
<danvet>
like I frankly don't really care how fbcon picks the "right" driver :-)
<javierm>
yeah, same. It's too confusing for me and for sure if we touch it, we will break someone setup
fxkamd has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
mbrost has joined #dri-devel
<danvet>
I just stumbled over the hyperv pci stub driver
<danvet>
is this like on windows where you need dummy drivers to avoid a warning in the device manager because there's no driver for a device?
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #dri-devel
pendingchaos has joined #dri-devel
JohnnyonF has joined #dri-devel
pendingchaos has quit [Read error: No route to host]
pendingchaos has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Read error: No route to host]
pendingchaos has joined #dri-devel
pendingchaos has quit []
pendingchaos has joined #dri-devel
heat_ has quit [Remote host closed the connection]
pendingchaos has quit [Read error: No route to host]
heat has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
LaserEyess_ has quit []
LaserEyess has joined #dri-devel
fab has quit [Quit: fab]
pendingchaos has joined #dri-devel
<danvet>
tzimmermann, since I just noticed loongson driver ready for merging?
Zopolis4_ has quit []
<tzimmermann>
danvet, i wanted to take another look. i told him about a better design, but nothing has moved AFAIK. hopefully this won't backfire. but in general, this should be mergable
<danvet>
tzimmermann, javierm has the switch to simpledrm happened? asking since I wonder whether I really should fight geert on fbdev validation or just move on to only fixing them for drm and ignoring everything else
<javierm>
danvet: for at least fedora and opensuse (AFAIK) it has happeed for a couple of releases now
<tzimmermann>
danvet, at least opensuse has switched
<javierm>
I believe arch did it too
<tzimmermann>
ubuntu has support as well IIRC
<danvet>
cool
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
godvino has quit [Read error: No route to host]
kzd has joined #dri-devel
jkrzyszt has joined #dri-devel
guru_ has quit []
oneforall2 has joined #dri-devel
fab has joined #dri-devel
Haaninjo has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
godvino has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
pcercuei has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Duke`` has joined #dri-devel
pcercuei has joined #dri-devel
macromorgan_ has quit []
macromorgan_ has joined #dri-devel
macromorgan_ has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
<macromorgan>
so I'm having an odd issue I was hoping someone could help direct me where best to troubleshoot. When I suspend my system I get a completely blank screen when I resume. If I use modetest to test a test image with a different size plane though the screen works again after I ctrl+c out of it.
<macromorgan>
as best I can tell with a register dump the registers themselves on the hardware are identical before and after suspend. (this is for a Rockchip system with the VOP2 driver)
<macromorgan>
and it affects both DSI and HDMI outputs after suspend
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
lemonzest has quit [Ping timeout: 480 seconds]
godvino1 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
godvino has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
jernej_ is now known as jernej
godvino1 has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
mdroper has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
mbrost has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
ubitux has joined #dri-devel
mbrost has joined #dri-devel
efpwcdo^ has joined #dri-devel
efpwcdo^ has quit [Remote host closed the connection]
pcercuei has quit [Quit: leaving]
pcercuei has joined #dri-devel
pcercuei has quit []
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
fxkamd has quit []
pcercuei has joined #dri-devel
i509vcb has joined #dri-devel
Guest9892 has quit [Remote host closed the connection]
<alyssa>
anholt: My concern is memory usage, which has knock-on effects on compile time because of malloc etc
<alyssa>
this adds 32 bytes to every fadd instruction
<dj-death>
actually I think the LSC unit on DG2 can do up to vec64 in some case if I'm not mistaken
<anholt>
for the swizzle. also, nir_constant is concerning and I worry we're going to want to have a dynamically allocated values[] :(
<dj-death>
just for the lulz
<alyssa>
dj-death: thing is, nobody's hardware is actually doing ALU of that size
<alyssa>
and certainly not doing unconstrained swizzles at that size
<alyssa>
actually, even Midgard which has native i8vec16 ALU (!) has *tons* of constraints on the swizzle
<karolherbst>
yes
<karolherbst>
if you increase the vec size, please also reduce memory consumption
<karolherbst>
optimize against the vec4 case
<jenatali>
Yeah, seems like there needs to be some kind of special return type for loads that return larger datasets
<alyssa>
karolherbst: my point is that even vec4 hardware doesn't necessarily want this
<robclark>
swizzle could be packed (assuming no one introduces vec256)..
<alyssa>
robclark: it's already only 8-bits per component
<karolherbst>
yeah, but for vec4 it doesn't matter much
<robclark>
right, but it could be.. 5b?
<alyssa>
10b with the new vec16 then
<karolherbst>
robclark: sooo.... uhm... some people think about that
<alyssa>
er
<alyssa>
vec32
<robclark>
but maybe the better plan is just have union { something[4]; ptr *more_than_vec4_case; }
<alyssa>
20 bytes?
<alyssa>
robclark: with my scalar ISA hat on, I don't want swizzles in NIR at all
<robclark>
anholt: 5 bits will hold 0..31
<robclark>
err, alyssa
<karolherbst>
mood
<karolherbst>
yes, let's just remove the swizzle and lower it
<karolherbst>
let backends optimize it :P
<alyssa>
I can't tell if you're joking
<karolherbst>
maybe we can just assume I'm not and see how far we'll get with it?
<alyssa>
I don't think it'd be catastrophic to make that change for my compilers, only concern for Midgard is that its copyprop can't see through phis which might regress moves but I'm not super worried
<karolherbst>
yeah sooo..
<alyssa>
bigger issue is that it *is* a significant change for vec4 compilers and we have a bunch of those that are minimally maintained
<karolherbst>
my hw doesn't have swizzling at all, soo...
<alyssa>
same here for everything but midgard
<alyssa>
well
<alyssa>
sort of
<alyssa>
bifrost/valhall have a 2-bit swizzle for i16vec2
<karolherbst>
uhhh
<karolherbst>
pain
<alyssa>
yes
<alyssa>
that compiler is ingesting SSA directly so if I need to copyprop harder, whatever
<karolherbst>
yeah
<karolherbst>
whatever
<alyssa>
Anyway, there is a part of me that would really like to have no swizzle on the nir_alu_src
<karolherbst>
anyway
<alyssa>
(implicitly an identity swizzle)
<alyssa>
(or maybe an optional broadcast?)
<karolherbst>
there needs to be some trade. You add more components, you also reduce memory consumption :D
smiles_1111 has quit [Ping timeout: 480 seconds]
<alyssa>
and a nir_op_swizzle that does vec->vec with the swizzle passed specially
<alyssa>
IDK if that'd be ALU or intrinsic or what
<karolherbst>
I think when I bumped wiht all the opts it was like ~5%
<alyssa>
I guess ALU with a constant source for the swizzle itself would be fine
<alyssa>
although would need special handling in nir_print src to not suck
<alyssa>
Oh, wait, duh
<alyssa>
different swizzle ALU op per vector size, maybe
<karolherbst>
we kinda traded -10% with +15%
<alyssa>
swizzle{2,3,4,8,16} ops taking that many constant sources, acting like a vec+extract together
<karolherbst>
anyway
<karolherbst>
bumping the max vec size has a huge impact
<alyssa>
on scalar hardware, swizzle ops would never be seen since the vectors get lowered
<alyssa>
on vector hardware, swizzle ops translate to a vector move
<anholt>
alyssa: texture ops (for example) return vectors, you'd still need swizzle ops to access their components.
<alyssa>
i.e. "foo = swizzle4 bar, 3, 2, 1, 0" translates to "foo = mov bar.wzyx"
<karolherbst>
why?
<jenatali>
FWIW, in DXIL, which is a scalar SSA, when an instruction needs to return multiple values (e.g. a load of 4 values at once), it returns a special struct which has extract functions to retrieve the relevant scalars. Seems something like that (a return value that's multiple max-size vectors) with extract helpers would work
<karolherbst>
there is nothing that says that you need swizzle ops for tex results
<karolherbst>
that's a hw detail
<alyssa>
anholt: right, you need a swizzle1 ("extract"), also just a move
<alyssa>
the SSA-based RA compilers are already doing this in the backend
<karolherbst>
yeah, that's just a nop
<karolherbst>
on sane hw at least
<anholt>
yeah. I was just confused by "swizzle ops would never be seen since the vectors get lowered"
<anholt>
they wouldn't be lowered in NIR, the backend would definitely see them
<anholt>
I'm not saying this is a terrible idea, just that it's invasive to every driver.
<alyssa>
yeah, absolutely
<alyssa>
this isn't really "we should do this" and more "if I were building NIR today knowing what I know now, I wouldn't have put that damn array in nir_alu_src, and now you want to make it BIGGER?"
<anholt>
given that we haven't even eliminated nir_register from src/dsts yet, I'm skeptical of making this change
<alyssa>
even lower hanging fruit, the abs/neg flags
<alyssa>
none of the modern backends use them and we got so close to deleting them
<alyssa>
but a pile of legacy hw is using them for stuff and yeah.
<karolherbst>
I wouldn't be opposed to make evertyhing vec4+ very special in nir and reduce max components to 4 again
<karolherbst>
or rather
<karolherbst>
swizzles are 4 comps max or any other restrictions
<karolherbst>
only thing you'd get above 4 is linear allocation of values
<karolherbst>
or we just remove the swizzle and make it an alu op only thing
<karolherbst>
and then backends deal with it themselves
<jenatali>
That might work... CL stuff might get tricky though
<jenatali>
I don't remember if they can do swizzles on arbitrary ops though or if they end up as dedicated mov instructions
<karolherbst>
doesn't really matter
<alyssa>
yeah, how does vec16 spirv look like?
<jenatali>
The same as vec4
<karolherbst>
if we remove swizzles from the IR and just do vec4 ssa_1 = nir_swizzle(ssa_0, 0x5) whatever, then backends can inline it in the consumer or something
pcercuei has quit [Quit: leaving]
<jenatali>
Fair
<alyssa>
karolherbst: that's my above "wishful thinking, would take months of rewriting everybody's backends to land"
<karolherbst>
yeah...
<alyssa>
and I agree with anholt, if we can't even remove abs/neg and nir_register, no way we can do that.
<enunes[m]>
jenatali yes, I'm away for a few days though, David Heidelberg should have disabled it for now
<jenatali>
Right, I missed that it was disabled, the MR I was looking at just hadn't been rebased, thanks!
jewins has joined #dri-devel
invertedoftc096 has joined #dri-devel
luc4 has joined #dri-devel
<danvet>
robclark, I've done a quick diff for the fence deadline modeset regression
<danvet>
do you want to take over or should I like bake this into a patch if it turns out correct?
<danvet>
well maybe two patches
* gfxstrand
reads backlog
<gfxstrand>
alyssa said I might have opinions...
<karolherbst>
yes, tldr: vec32
<gfxstrand>
Ok, it's about what I thought. 32-wide uniform SEND messages.
<gfxstrand>
On the one hand, vec32 makes total sense in that context. On the other hand, I really don't want to add another 16B to nir_alu_src.
<karolherbst>
we need a more general solution for wide vectors I think
<karolherbst>
or ehh
<karolherbst>
a different solution
<gfxstrand>
here's a crazy thought... We could make nir_alu_src::swizzle a pointer and just allocate all the memory for it at the end of the instruction but only allocate as much as needed.
<karolherbst>
Maybe we just figure out what's the max component hw can swizzle and above that we just manage it differently?
<karolherbst>
mhhh
<gfxstrand>
Then the only things to get 32B of swizzle would be things that actually need it which is pretty much nothing.
<gfxstrand>
It'd make copying ALU sources around a giant PITA, though. :-/
<karolherbst>
wouldn't it make nir_alu_instr a giant pita generally?
<gfxstrand>
Yeah, but the sources is where it'd really hurt
<gfxstrand>
IDK that we copy them around all that much today but we do some
<karolherbst>
what I mean is.. we can't make nir_alu_src variable in length without rewriting how sources of nir_alu_instr are accessed
<karolherbst>
but yeah...
<gfxstrand>
Did you read what I typed?
<gfxstrand>
It would make it work for 95% of cases. We'd just have to fix up the few times that we copy whole nir_alu_src around which isn't that many.
<karolherbst>
ohh, right...
<karolherbst>
I wonder if we should just dtich the swizzle from the IR
<gfxstrand>
That's tricky
<karolherbst>
it's alerady a huge memory consumption and you almost never need it
<gfxstrand>
You never need it for scalar back-ends
<gfxstrand>
We really want to keep it for vec4
<karolherbst>
right, but even then
<karolherbst>
I do wonder if converting swizzles to an alu instruction backends could optimize into hw swizzles is actually the solution
<karolherbst>
or if we'd come up with something better
<gfxstrand>
IDK that I want to trust vec4 back-ends to be smart about copy-prop and coalescing.
<gfxstrand>
Not that smart, anyway
<karolherbst>
the idea was.. if the source is a nir_swizzle, just use that
<karolherbst>
but yeah.. I see your point
invertedoftc096 has quit []
<gfxstrand>
But we could probably cut the swizzle down to uint8_t[4] if we wired through a nir_op_has_swizzle()
<gfxstrand>
Or `nir_alu_instr_has_swizzle()`
<gfxstrand>
or something
invertedoftc096 has joined #dri-devel
<karolherbst>
mhh
<karolherbst>
here is an idea
<karolherbst>
we just allocate all possible combination of swizzles and then point to that...
<karolherbst>
might actually need less memory
<karolherbst>
mhh
* gfxstrand
does math
<karolherbst>
well probably not with 32 components
<karolherbst>
but we could e.g. do it for all 4 component ones
<gfxstrand>
Yeah, no, 32^32 is way too many. :-P
<karolherbst>
and if somebody needs more, it's dynamically allocated
<karolherbst>
could even share it across all shaders
<gfxstrand>
That's basically the same pain as my "make it part of nir_alu_instr at the end" plan
<karolherbst>
though currently we use 128 bit per alu src
<gfxstrand>
Just even more compact
<karolherbst>
and a pointer would be 32/64
<karolherbst>
yeah...
<gfxstrand>
It's not a horrible idea, it just has the same problem where we'd need to do a tricky refactor
<gfxstrand>
But refactors can be done
<karolherbst>
might want to keep in mind that we might have to grow that sooner or later :(
fab has quit [Quit: fab]
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
* gfxstrand
is contemplating adding nir_tex_instr::backend_flags
<gfxstrand>
To go with src_type_backend0 and src_type_backend1
<gfxstrand>
backend1 and backend2, rather
Duke`` has quit [Ping timeout: 480 seconds]
<robclark>
danvet: half your diff is patch I've already sent.. but nerfing it for modeset also sounds like a good idea (but won't be able to look until a bit later so feel free to send a patch)
<danvet>
robclark, oh right yours actually fixing something
<danvet>
robclark, you've pushed it somewhere already?
elongbug has quit [Remote host closed the connection]
<danvet>
I guess I can take care of the needs_modeset one if I get a tested-by or so
<robclark>
no.. I think it has some t-b's.. maybe someone could push it to drm-misc for me?
elongbug has joined #dri-devel
elongbug has quit [Read error: Connection reset by peer]
<danvet>
robclark, tzimmermann r-b'ed it already but I guess assumed you have commit rights
<danvet>
robclark, I'll push it
elongbug has joined #dri-devel
<DemiMarie>
Sorry if there is a bad place to ask, but I don’t know of a better one! Why can’t implicit derivatives be in non-uniform control flow?
<gfxstrand>
Helper pixels.
<robclark>
thx
moa has quit [Read error: Connection reset by peer]
<DemiMarie>
gfxstrand: what do you mean?
moa has joined #dri-devel
<gfxstrand>
The way implicit (or indeed explicit) derivatives work is that hte hardware is dispatched in blocks of 2x2 pixels, usually tightly packed within a wave. The dFdx/dFdy as well as texture ops with implicit derivatives look at the other pixels in that 2x2 to compute the derivative.
<danvet>
robclark, kinda one reason I don't like topic pulls, it means I somehow also end up being responsible for applying the fixes :-P
<gfxstrand>
If a triangle only covers some of the pixels in any give 2x2, all 4 are dispatched and the inputs are interpolated to exend past the edge of the triangles into those extra pixels.
<gfxstrand>
These extra pixels are called "helper" pixels and their corresponding fragment shader invocations are called helper invocations.
<gfxstrand>
Now, back to your original question...
<gfxstrand>
If a dFdx, dFdy, or texture op with implicit derivatives is executed in non-uniform control flow, we have nothing guaranteeing that all 4 pixels within the 2x2 group actually reach that operation. If, say, only 3 of them do then the 4th will have garbage data and the derivative will be no good.
<gfxstrand>
Uniform control-flow guarantees that all the data we need is there.
<robclark>
danvet: if you want I can send PR for fixes.. but hopefully there is only one or two
<gfxstrand>
Of course, uniform is way more strict than we actulaly need. Typically, what you really need is just 2x2-subspan-uniform but all these specs were written long before we had that specific language in the spec.
<gfxstrand>
I made an attempt a few years ago to loosen things up a bit so that 2x2-uniform was all that was required but ran into problems. It's been a while so I don't remember which hardware struggled with it.
<danvet>
robclark, then I'm still responsible for applying them if it's just a pr with a single patch
elongbug has quit [Quit: Leaving]
<DemiMarie>
gfxstrand: Would an accurate summary be “if not all of the pixels compute the implicit derivative at the same time, the ones to arrive first will get garbage data from those that have not arrived yet, and the pixels that come later might see data that has been clobbered”?
<robclark>
danvet: I guess you get to apply it in some form or another regardless ;-)
<jenatali>
"Yet" isn't necessarily accurate, other pixels might not ever arrive if the non-uniform control flow is a branch
Haaninjo has quit [Quit: Ex-Chat]
<gfxstrand>
DemiMarie: Some may not get there ever
<danvet>
robclark, well the big integration pulls are kinda unavoidable, but I don't mean those
<DemiMarie>
gfxstrand jenatali: true!
<Lynne>
any advice on debugging a piece of shader code that keeps crashing GPUs and llvmpipe (it's a black box even with debug info on)?
<Lynne>
the exact same piece of code runs fine elsewhere
<Lynne>
just not in the spot I'd like it to run in
elongbug has joined #dri-devel
<Lynne>
gpu assisted validation is out, I use descriptor buffers + bda
<Lynne>
(running any descriptor code with validation just hangs the GPU currently)
bgs has quit [Remote host closed the connection]
MajorBiscuit has quit [Quit: WeeChat 3.6]
<zmike>
is it a descriptor issue?
<Lynne>
no, my descriptors are fine, I've tried both BDA + ssbo, both crash
<dj-death>
Lynne: what driver ?
<Lynne>
it's a parallel prefix sum shader I'm running, if I remove it, the code runs fine
<Lynne>
RADV and lavapipe (this one just segfaults)
<zmike>
does lavapipe segv inside llvm?
<Lynne>
possibly, I'm seeing nothing in gdb, just pointers
<zmike>
you could try instrumenting src/gallium/auxiliary/gallivm/lp_bld_nir_soa.c with lp_build_print_value calls to bisect the runtime execution
<zmike>
though that semi depends on having some familiarity with nir
<zmike>
I'm heading out for the day, but if you're still having issues with it in ~12h ping me with a branch and some vague instructions and I can try hunting it down
<Lynne>
I speak native x86 and arm64 assembly, if that helps
<zmike>
and then using that you can gdb through the shader's build from that file
<zmike>
lp_build_print_value(gallivm, "somename", LLVMValueRef) will print whatever value to stdout in all the active lanes
<zmike>
best used with MESA_SHADER_CACHE_DISABLE=1 LP_NUM_THREADS=0
<zmike>
this should let you determine where in the shader it's crashing pretty easily
<Lynne>
thanks, I'll give it a go
<zmike>
good luck
rasterman has quit [Quit: Gettin' stinky!]
<Lynne>
I'm printing, how do I gdb using that?
luc4 has quit []
pcercuei has quit [Quit: dodo]
Zopolis4_ has joined #dri-devel
digetx has quit [Read error: Connection reset by peer]
digetx has joined #dri-devel
<anholt>
dj-death: heads up, since you also have done perfetto stuff: I'm working on getting command buffer handles attached to command buffer events, and getting debug names associated with handles.
<zmike>
Lynne: you don't gdb using it, you just keep adding prints until you've isolated the instr that's causing the crash (since you don't see any prints that you've added to it)
gouchi has joined #dri-devel
gouchi has quit [Quit: Quitte]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
tzimmermann_ has joined #dri-devel
<Lynne>
hmm, I was able to fix the crash in llvmpipe by grossly overallocating (expecting to read 128mib, had to allocate a gig to keep it happy)
<Lynne>
output looks correct though, so I wonder why it's overreading that hugely
<Lynne>
radv still crashes, even if allocating 8gib
tzimmermann has quit [Ping timeout: 480 seconds]
<Lynne>
the device address has 0x8xxxx... as the top bit, surely it's not taking that literally and accessing petabytes of memory
<zmike>
could be stride issue
<zmike>
you can print the loaded offsets from gallivm
rszwicht has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
<Lynne>
debugPrintfEXT reveals my push data is junk
<Lynne>
but then how are the addresses fine if they come after the stride (also in the push data)?