ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<DemiMarie>
Why do GPUs not just use ordinary pointers?
<karolherbst>
they do.. for most/some parts
<karolherbst>
it kinda depends
<karolherbst>
not using pointers comes with the advantage of being able to cache/preprocess things
<karolherbst>
like e.g. on nvidia GPUs constant memory can be placed in so called constant buffers being of 64k in size and you have 8-18 slots of those
<karolherbst>
they are normal VRAM, but pre uploaded in a cache having register read speed
<karolherbst>
sometimes hardware is designed around doing some pre computations on bind resources before you can actually use them in shaders or other operations
<karolherbst>
sometimes you get huge cache benefits in having them organized in smaller heaps
benjamin1 has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
<Lynne>
if you use descriptor buffers with buffer refs, they're real pointers even in the shader
jewins has quit [Ping timeout: 480 seconds]
<karolherbst>
mareko: seems like 9d7eab2ab17b3ffcf8c965c9e7cf89ff1bf2b7ac regression some CL workloads, I just have no idea why yet :)
<karolherbst>
but I'm seeing GPU hangs and resets
<karolherbst>
navi 22
columbarius has joined #dri-devel
<airlied>
maybe it should be left on for compute shaders
co1umbarius has quit [Ping timeout: 480 seconds]
<karolherbst>
I know that a kernel doing fmod causes resets
<karolherbst>
but some others were fine
kasper93 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
kasper93_ has quit [Ping timeout: 480 seconds]
<karolherbst>
mhhh `vec2 16 div ssa_41 = isub ssa_40.xx, ssa_39` radeonsi crashing on that...
<airlied>
it's like there is just some sync somewhere else in the shader that is going wrong
<karolherbst>
ohh.. it's a different bug
<karolherbst>
somehow the LLVM value of a vec2 value only has one component
<karolherbst>
but also looks like a regression.. let's see...
<karolherbst>
I also did upgrade my testing machine to fedora 38, so I get llvm 16 now
<karolherbst>
could also lead to some fun problems, but seems to be fine for now
benjamin1 has joined #dri-devel
<karolherbst>
okay.. that one is caused by d692d433f28e0a170685dbcfd941d68e6d767182 radeonsi: use nir_lower_alu_to_scalar correctly
<karolherbst>
funky...
kasper93 has quit [Remote host closed the connection]
<karolherbst>
I don't see why, but it does cause regressions...
<airlied>
robclark: one of the commits in your fixes pull is missing an Sob
<airlied>
drm/msm/dp: enable HDP plugin/unplugged interrupts at hpd_enable/disable is commited by Abhinav but has no sob from them
<airlied>
please fix it and let me know to pull it
<robclark>
ugg... wasn't CI supposed to save me from this?
<airlied>
dim would have
<airlied>
use dim :)
<robclark>
airlied: sent a resend.. drm-msm-fixes-2023-06-08
columbarius has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
<karolherbst>
uhh.. seems to be more regressions :') I really should add rusticl on hw jobs to CI
<airlied>
yeah now that it runs on hw, you totally should
<karolherbst>
just piglit isn't really enough, but I guess I can still start with piglit for iris + radeonsi
Company has quit [Quit: Leaving]
<karolherbst>
get_linear_ids is also bonkers.. but I'll figure it out tomorrow
sravn has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
caef^ has quit [Remote host closed the connection]
anshuma1_ has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
diego has joined #dri-devel
Duke`` has joined #dri-devel
bgs has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<airlied>
karolherbst: took a quick look at fns on radeonsi, got the basic IR translation going, but as we are using the shader calling convention, there's a bunch of implicit ctx to shuffle into each fn
<airlied>
there is a lot of implicit stuff unfortunately
heat_ has quit [Ping timeout: 480 seconds]
phree has joined #dri-devel
sravn has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
fab has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
bgs has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
tursulin has joined #dri-devel
fab has joined #dri-devel
jmondi has joined #dri-devel
phree has quit [Quit: Page closed]
benjamin1 has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
lynxeye has joined #dri-devel
pcercuei has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
kasper93 has joined #dri-devel
smilessh has joined #dri-devel
smiles_1111 has quit [Read error: Connection reset by peer]
vliaskov has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab is now known as Guest2568
<sergi>
<anholt> "sergi: what happened that the..." <- Hi anholt,
<sergi>
I've just realized there is a message mentioning that I missed answering. The ci-uprev tool looks for the "image-tags", but it needed to be more competent to know about the arch renaming. Even worst, it silently ignores the situation. This has been solved with a recent merge request in the tool. If there are missing changes to do an uprev, it stops and reports the trouble.
Guest2568 has quit [Quit: Guest2568]
fab_ has joined #dri-devel
swalker__ has joined #dri-devel
fab_ is now known as Guest2569
<karolherbst>
airlied: yeah... what if the called function only has primitives or arrays of such as parameters? Does that help?
swalker_ has joined #dri-devel
swalker_ is now known as Guest2570
Haaninjo has joined #dri-devel
anshuma1_ has quit [Ping timeout: 480 seconds]
anshuma1_ has joined #dri-devel
swalker__ has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: I think for now we we should always inline everything _unless_ a driver registers a callback to identify what's safe to inline. But I have no idea how that interface should look like yet... but if it only depends on the function arguments it might not be impossible
Haaninjo has quit [Quit: Ex-Chat]
frankbinns has joined #dri-devel
<karolherbst>
another radeonsi regression: 39da12b7c7c522e1bb5a51b7310a2b68d30a04aa ac/llvm: clean up visit_load_local_invocation_index and visit_load_subgroup_id :')
<daniels>
konstantin_: ^ instead of triggering the entire pipeline with every job, can you please use .gitlab-ci/bin/ci_run_n_monitor.py --target '$jobname'? that will mean that your radv RT experiments won't be tying up Raspberry Pi resources anymore
<konstantin_>
ok
cmichael has joined #dri-devel
<HdkR>
The Pi just needs to grow some RT functionality so it is worth testing on :P
i509vcb has quit [Quit: Connection closed for inactivity]
junaid has quit [Remote host closed the connection]
mvlad has joined #dri-devel
<javierm>
tzimmermann: hi, provided a few examples on the mailing list of use cases for what Geert was asking about
djbw_ has quit [Read error: Connection reset by peer]
<airlied>
karolherbst: the problem is implicit things like load_workgroup_id etc
<javierm>
tzimmermann: with my fedora developer hat, I only care about your series but with my maker dev hat I agree with Geert that we need the flexibility for different configurations
<airlied>
those come in via registers initially, and if a function access them you have to have some way to funnel them down
<daniels>
konstantin_: thanks
<konstantin_>
HdkR: Any driver that supports buffer device address can also support RT
<HdkR>
konstantin_: good good. The Pi will be running Control with RT soon enough then
<konstantin_>
No promises, but I have a raspberrypi 4 :P
<karolherbst>
airlied: we could collect read sysvals per function
<karolherbst>
I really don't want to require backends to come up with some ABI because not having that should be good enough. Some of those libclc functions are massive enough to cause such problems, so my assumption is that we can cut down a lot of the size just by reducint inlinings of huge clc functions, everything else is just nice to have.. probably
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<tzimmermann>
javierm, am i stupid? could you please EILI5 to me what FB_CORE is good for?
<tzimmermann>
ELI5
jfalempe has quit [Quit: Leaving]
<tzimmermann>
javierm, i honestly don't understand why the existence or default of FB_DEVICE should be tied to native fbdev drivers
<javierm>
tzimmermann: you are definitely not :) Probably I'm just bad at explaining things
<javierm>
tzimmermann: there are multiple use cases AFAICT. You could need either a modern kernel-space (only DRM drivers) or modern user-space (only DRM programs)
<javierm>
tzimmermann: your patch series is when you want both a modern kernel-space and user-space and that's great, we would probably adopt that in fedora
<tzimmermann>
sure, same here
<javierm>
tzimmermann: the FB_CORE is to allow all real fbdev drivers to be disabled but still have DRM fbdev emulation
<javierm>
that's when you want a modern kernel-space (only DRM drivers) + old user-space (only fbdev programs)
<tzimmermann>
i got that as well
<javierm>
tzimmermann: in that case you want FB_DEVICE but only for DRM fbdev emulation
<tzimmermann>
no
<tzimmermann>
if i have old userspace, i want it to run on my drivers. whether that is fbdev or DRM doesn't matter
<tzimmermann>
so i need FB_DEVICE
<tzimmermann>
unconditionally
<javierm>
tzimmermann: yeah, but then you need to explicitly disable all the fbdev drivers
<tzimmermann>
why?
<javierm>
would be great to have a single Kconfig symbol to say "I want to disable all native fbdev drivers"
<tzimmermann>
why?
<javierm>
just to make the config simpler ?
<tzimmermann>
why?
<javierm>
I mean, we have a bunch of Kconfig symbols to disable a set of stuff, why we couldn't have one for fbdev native drivers ?
<javierm>
that's what Geert was asking IIUC and I mentioned that I already posted a series for that, which funnily had even the same symbol name (FB_CORE)
<javierm>
he was asking if there could be an option to *only* support fbdev through DRM emulation
<javierm>
because right now in fedora we have CONFIG_FB enabled (for drm emulation) and need to explicitly disable all the drivers. It makes no sense to me
<tzimmermann>
what you are describing is entirely unrelated to my patchset
<javierm>
tzimmermann: it is unrelated yes, that's why I said that are complementary
<tzimmermann>
let me make my point: the only relevant question for FB_DEVICE is "do i have an old fbdev userspace?" if so, FB_DEVICE=y. otherwise FB_DEVICE=n is preferable. whether that fbdev device is provided by aDRM or an fbdev driver is irrelevent
<javierm>
tzimmermann: yeah, the only open question for your patch-set is if FB_DEVICE should be y if !DRM
<tzimmermann>
it should just be y or n
<tzimmermann>
i guess y would be the better setting
<javierm>
yeah and distros can explicitly disable it
<javierm>
tzimmermann: at least to unlock your series. We can later revisit as follow-up
<tzimmermann>
the whole discussion about the actual existence of an fbdev userspace seems artificial to me. you have examples, but those would be covered by FB_DEVICE=y
<javierm>
tzimmermann: yes, but then it would mean to either a) explicitly disable all the fbdev drivers (what I currently do) or b) keep those fbdev drivers enabled even if not needed
<javierm>
tzimmermann: anyways, let me say again that this whole discussion is unrelated to your patch-set and we can have it later
<javierm>
I'll post as RFC on top once your patches land
cath has left #dri-devel [#dri-devel]
<tzimmermann>
i'm thinking about FB_DEVICE_DEFAULT_ENABLE=<bool> plus an module parameter. it would allow distributions to soft-disable the device, but give users a option to override the setting and bring back the device.
<tzimmermann>
if fb.fb_enable_device=1 has been given to the module or kernel, the device would be created
<tzimmermann>
i assume that we (SUSE) has users that might have a requirement for the fbdev device
kts has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: I think that is too complicated for no clear benefit. We are soon disabling even X11 support so fbdev user-space can really just go away too
<javierm>
if there are still fedora users needing fbdev, then can have a custom kernel build with copr or just use a different distro that supports legacy stuff
<tzimmermann>
that's ~10 lines of code
<javierm>
tzimmermann: yeah, is not the code itself but giving users the choice
<javierm>
now, a kernel config option to build custom kernels that support fbdev (in kernel or user-space) makes sense to me
<javierm>
and where kernel-space is only DRM + emulated fbdev
<javierm>
tzimmermann: I mentioned in the thread that the FB_CORE discussion brought by Geert is really orthogonal to your series and we can have that discussion as follow-up
<javierm>
tzimmermann: I've reviewed all the patches that Sam didn't. Please let me know if there are some tags still missing
<tzimmermann>
javierm, thanks a lot for your work
<tzimmermann>
i'll resend the next version early next week
<javierm>
tzimmermann: great! I'm pretty sure we will adopt that config in Fedora. We only really need fbdev for fbcon and ({efi,vesa}fb) for nvidia
<tzimmermann>
javierm, FB_CORE would be selected by FB and DRM_FBDEV_EMULATION?
<alyssa>
* convert_from_ssa + locals_to_regs + vec_to_movs have new versions producing intrinsics
<alyssa>
* helpers to allow backends to parse intrinsics as-if they were nir_registers so they don't need to improve their crappy copyprop
<alyssa>
* intel/fs, intel/vec4, midgard, and nir-to-tgsi converted to use intrinsics + helpers
<alyssa>
this is about feature complete for what I was hoping for in this series
Duke`` has joined #dri-devel
<alyssa>
so I am hopeful that it'll be ready for serious review on Monday and we can get this in sooner than later
<alyssa>
at which point... phase 2 is converting each backend one-by-one
<alyssa>
though hopefully I can get everyone on board and we can do the backends in parallel
<alyssa>
It's not *hard* to convert a backend, but there are a bunch of them
<karolherbst>
yeah... I kinda want to get rid of the pre SSA phase in codegen, it's just... uhh... a lot of code to read
<karolherbst>
most of the lowering is done pre SSA for _whatever_ reason
<karolherbst>
I think most of the code is already SSA compatible, but...
<alyssa>
shrug
<alyssa>
I hear there's a shiny new SSA-based backend coming
<alyssa>
for nouveau
<karolherbst>
yeah... I don't know what happens to me if I suggest covering all the ISAs codegen covered :D
<alyssa>
ahahaha, fair
<karolherbst>
codegen supports like... 4 ISAs
<alyssa>
>_>
<alyssa>
right, well
<karolherbst>
5 actually
<alyssa>
if you have good backend copyprop, you don't need the helpers and can just translate intrinsics
<alyssa>
that's probably the least invasive option here
<karolherbst>
yeah.. probably good enough
<karolherbst>
I don't know if codegen has good copyprop, but it has copyprop
<alyssa>
oh hmmmmm
<alyssa>
I wonder if llvmpipe would be happy to eat the intrinsics directly
<alyssa>
since it's just materializing loads/stores anyway
<alyssa>
so I don't think the helpers would actually help
<karolherbst>
in codegen that's probably entirely fine, just emiting a mov to/from a non SSA value should be good enough at least...
<alyssa>
yep
mbrost has joined #dri-devel
greenjustin has joined #dri-devel
zehortigoza has quit [Quit: Coyote finally caught me]
zehortigoza has joined #dri-devel
djbw_ has joined #dri-devel
Guest2570 has quit [Remote host closed the connection]
ultra is now known as BenjaminBreeg
smilessh has quit [Read error: No route to host]
smilessh has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
BenjaminBreeg has quit []
smilessh has quit [Read error: Connection reset by peer]
Ultra has joined #dri-devel
Ultra has quit [Quit: Ultra]
<emersion>
pq: some qualcom person replied to the color KMS API thread
<emersion>
hm, i should've asked more about their hw
fab has quit [Ping timeout: 480 seconds]
BenjaminBreeg has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
imre is now known as Guest2593
imre has joined #dri-devel
Guest2593 has quit [Ping timeout: 480 seconds]
anshuma1_ has quit [Ping timeout: 480 seconds]
anshuma1_ has joined #dri-devel
bb2045 has joined #dri-devel
<bb2045>
Hi all, can someone give me a refresher on how to fossilize a pipeline with mesa/RADV? `VK_INSTANCE_LAYERS=VK_LAYER_fossilize FOSSILIZE_DUMP_PATH=. ./program_name` doesn't seem to do the trick for me for some reason.
<agd5f_>
airlied, fixed
<agd5f_>
airlied, new PR sent
* alyssa
stares back at Alyssa from years ago
<alyssa>
Is f2i32(fceil(x)) actually the same as f2i32.rtp (and so on)
* alyssa
raises eyebrow suspiciously
<alyssa>
firm maybe?
<alyssa>
seems like it might have precision issues potentially
anshuma1_ has quit [Ping timeout: 480 seconds]
anshuma1_ has joined #dri-devel
<alyssa>
maybe it's ok.. but not really a source modifier. maybe I will rework this code then.
aravind has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
aravind has joined #dri-devel
BenjaminBreeg has quit [Remote host closed the connection]
BenjaminBreeg has joined #dri-devel
<jenatali>
Those should be the same
<alyssa>
jenatali: ok.. 2020 Alyssa thought so too but it smells funny
lynxeye has quit [Quit: Leaving.]
<alyssa>
Maybe should introduce NIR opcodes for directed rounding for clarity if nothing else
<bb2045>
(nvm my earlier question- FOSSILIZE=1 worked just fine :) )
<jenatali>
alyssa: There's already intrinsics for that from CL
heat has quit [Read error: Connection reset by peer]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
gawin has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
frankbinns1 has joined #dri-devel
gawin has quit [Quit: Konversation terminated!]
frankbinns has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
frankbinns1 has quit [Remote host closed the connection]
jewins has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
Guest2487 has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
benjamin1 has joined #dri-devel
sassefa has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
sassefa has joined #dri-devel
jfalempe has quit [Quit: Leaving]
<DavidHeidelberg[m]>
mupuf: you'll be happy, working on separating kernel from Mesa3D CI repo now. I guess we can easily transition to cpio modules, not sure with firmware thou, that will take longer.