ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<karolherbst>
maybe some robustness req requires bound checking? dunno
<karolherbst>
so for supporting CL in Vk I think the best idea would be to have an extension structk to CmdDispatch where one either sets the additional space (including alignment gaps) or the total space
Ristovski has joined #dri-devel
<zmike>
hm I wonder if it has to be const or if spec const would work
<zmike>
have to check spec
<zmike>
would really rather not have to push through another spec for something this trivial considering how much work specs are
<karolherbst>
zmike: I'd just make it part of the accepting CL SPIR-V ext
<karolherbst>
don't really see a good way of dealing with it otherwise
ybogdano has quit [Ping timeout: 480 seconds]
<zmike>
if it's a spec const then it should be possible for drivers to reuse existing shaders
<karolherbst>
and how could we even use a spec const for that?
<zmike>
?
<zmike>
by passing it as a spec const?
<karolherbst>
but it's not a value inside the kernel
<zmike>
ah it's not in there at all?
<zmike>
excruciating
<karolherbst>
only the kernel parameter
<karolherbst>
but you can also call other kernels as functions
<karolherbst>
....
<zmike>
excruciating
<karolherbst>
yeah.. very
<karolherbst>
sure.. we could lower it to a function local array, but that also means touching the spir-v on dispatch time which I'd rather not to given it's a hot path
<zmike>
you could do like zink does and store the spirv offset for the value
<zmike>
that would make modifying it fast
<karolherbst>
it's fast now anyway
<karolherbst>
you just change the value in the kernel input buffer
<zmike>
then there's no problem! 🙏
<karolherbst>
yeah.. we just need to pass in the total size because hardware kind of needs to know
<karolherbst>
well.. when dispatching
<karolherbst>
mareko: currently looking at "si_llvm_declare_compute_memory" and I was wondering if stuff could be changed in a way, that I can pass in the shared_size into when gallium calls into launch_grid and not when creating the CSO
<karolherbst>
also .. why does LLVM even need to know the size?!?
<karolherbst>
mhh.. maybe we could just make an unsized array and call it a day?
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<karolherbst>
okay.. I was wrong.. ir3 actually cares about the shared mem size and it even affects register allocation :O
<karolherbst>
well.. seems like I'll be passing the additional mem needed instead of the total one then :(
<karolherbst>
and let drivers figure out if they have to do antyhing in case the kernel has variable shared mem size
agx has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest313
macromorgan has joined #dri-devel
Guest313 has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
kts has joined #dri-devel
Daanct12 has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
<HdkR>
What's the current state of the 22.3 release?
kts has joined #dri-devel
<HdkR>
22.2 even
kts_ has joined #dri-devel
kts_ has quit []
kts has quit []
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
Daanct12 has quit [Read error: Connection reset by peer]
Daaanct12 has joined #dri-devel
Daaanct12 has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
Daanct12 has joined #dri-devel
jewins has joined #dri-devel
jewins has quit []
<tjaalton>
HdkR: no dcbaker here to tell where we are. it's been a month since the previous rc..
<HdkR>
Has anyone else noticed that if you have all broadcom vulkan installed that vulkaninfo will crash when it tries to query GPU groups with VK_KHR_device_group_creation?
<HdkR>
Checking if this is a "just me" thing
<HdkR>
Yep, pretty gnarly bug in v3dv_EnumeratePhysicalDeviceGroups where it claims there is compatible GPU
kts_ has quit []
Duke`` has joined #dri-devel
kts has joined #dri-devel
sdutt has joined #dri-devel
sdutt__ has quit [Remote host closed the connection]
JohnnyonF has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<emersion>
note that "have had a dozen or so patches accepted" isn't accurate
<emersion>
i got rejected when i tried
vliaskov has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
tursulin has joined #dri-devel
<pq>
KunalAgarwal[m], I don't understand your problem.
JohnnyonF has quit [Read error: Connection reset by peer]
jkrzyszt has joined #dri-devel
kts has joined #dri-devel
lynxeye has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
<pq>
Plagman, I don't remember anything about that. It has been six months, so I'd think it's worth a resend with all the R-bs and whatnot added, so it's clear where it stands.
<pq>
Plagman, also, if you want me to see it, please CC me explicitly. I don't track dri-devel@ anymore, trying to focus more.
<pq>
Plagman, looks like my first comment was "what is the use case?" so the new cover letter or commit messages should explain that.
<pq>
otherwise it's just the same discussion from scratch
sarahwalker has joined #dri-devel
<emersion>
pq, was there a user-space impl for it?
<emersion>
(Plagman, new uAPI always needs a user-space patch to demonstrate usage, as a requirement for merging)
<pq>
emersion, I dunno, I forgot all about it. :-)
rasterman has joined #dri-devel
sarahwalker is now known as Guest341
<pq>
emersion, too bad Vanfanel is offline, but btw. it sounded like he would want to use the presentation-time extension and then wait after the presentation timestamp - if he literally wants to wait after the last frame has been shown.
<emersion>
i've mentioned this
<pq>
ah, I didn't spot that.
<pq>
emersion, what's your opinion about clients waiting until frame has been shown, btw? Obviously it reduces the available time budget, but any other disadvantages?
<emersion>
what kind of client are we talking about here?
<emersion>
isn't wl_surface.frame better?
Daaanct12 is now known as Daanct12
<emersion>
sway allows users to configure a delay for wl_surface.frame, so users can reduce latency for hand-picked clients if they want to
<pq>
that's a good question, why would anyone want to wait after actually presented
<emersion>
otherwise wl_surface.frame is sent as the same time as the presentation-time event
<pq>
Right, so sway always gives less than a refresh period of time for a client to render, while Weston OTOH always gives exactly the whole refresh period of time for clients. Weston sends frame callbacks when it itself kicks the composition to GPU & KMS.
tintou has quit [Quit: Client limit exceeded: 20000]
<emersion>
sway by default composites at wl_surface.frame time too
<emersion>
but can be configured to behave like weston
<emersion>
so the default case is, clients have 1 frame worth of time to render, and sway lags 1 frame behind
<pq>
weston starts compositing at wl_surface.frame emission.
<emersion>
and the best case is, clients have just the right amount of time to render, and sway has just the right amount of time to render
<emersion>
all manual knobs though
<pq>
The final solution is somewhere in the wayland-protocols merge requests to be more explicit about how to attain the lowest latency. I guess "want to wait after presented" is just a band-aid until that's ready.
<MrCooper>
emersion: "wl_surface.frame is sent as the same time as the presentation-time event" sounds like frame events are sent way too late
<pq>
MrCooper, not really... depends on what the goal is.
pcercuei has joined #dri-devel
<pq>
MrCooper, frame callbacks could be sent as late as, say, 1 ms before the compositor composites, which means that all clients have 1 ms of time to render and submit, but also latency is close to minimum possible.
<pq>
if a compositor composites at, say, 2 ms before vblank, and sends frame callbacks at the same time as presentation-time presented events, there is still most of the refresh period left for clients to draw again.
columbarius has quit [Ping timeout: 480 seconds]
<pq>
bit if a compositor composites much earlier, then it's that much less time for clients for the next draw
<airlied>
karolherbst: hey how does rusticl bind global resources
ella-0 has quit [Read error: Connection reset by peer]
<pq>
KunalAgarwal[m], looks like you are missing all the code for the output buffer.
<pq>
KunalAgarwal[m], I don't understand that code at all.
<pq>
KunalAgarwal[m], please also reconfigure your Matrix bridge to not use web links.
<pq>
KunalAgarwal[m], might help if you explain in English what that code is doing.
fahien has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat has joined #dri-devel
Ella[m] has quit []
Ella[m] has joined #dri-devel
Ella[m] has quit []
Ella[m] has joined #dri-devel
Ella[m] has quit []
Ella[m] has joined #dri-devel
Ella[m] has quit []
Ella[m] has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<enunes>
anholt: hi, I made some progress on enabling deqp-egl on my CI boards, without needing any monitor setup, but I got a couple of things I could use some help with
<enunes>
anholt: I got it to work with this horrible hack Option "DPMS" "false"
linkmauve has left #dri-devel [Error from remote client]
<enunes>
anholt: second thing, it looks like deqp-egl OOMs on these boards with 1G of memory. I would want a single .toml suite with deqp-gles2 (4 parallel jobs) and then deqp-egl (2 parallel jobs) but it doesnt seem possible to specify --jobs in toml, is that right?
bmodem has joined #dri-devel
<karolherbst>
airlied: thorugh set_global_binding
<karolherbst>
there isn't a hard binding going on, but that function kind of tells drivers the resource is going to be as global mem in a shader
<karolherbst>
the kernel pipeline is more or less equal to what clover is doing
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
kts has quit []
ngcortes has quit [Read error: Connection reset by peer]
<airlied>
karolherbst: ah radeonsi was blowing away all the uniform vars in finalize_nir
<airlied>
karolherbst: so rusticl was getting confused
<karolherbst>
uhhh... :/
<karolherbst>
yeah.. it shouldn't do that :D
<karolherbst>
but I wonder why that's relevant actually.. let's see...
<airlied>
karolherbst: assign locations doesn't work
<karolherbst>
ohh right, that's the thing called after all of that
<karolherbst>
mhh...
<dolphin>
airlied: any plans for pulling the previous drm-intel-gt-next or are you waiting for a new one with the fixed-up patches?
<karolherbst>
airlied: I was also looking into moving req_local_mem from cso creation time into launch grid and was seeing that radeonsi actually needs it to build the LLVM.. any ideas?
itoral has quit []
lkw has joined #dri-devel
<karolherbst>
it's the si_llvm_declare_compute_memory stuff
<airlied>
dolphin: did I not pull it?
linkmauve has joined #dri-devel
<airlied>
or was there another one?
<airlied>
dolphin: point me at a patchwork link if I misse done:)
<airlied>
missed one
<karolherbst>
airlied: guess I could call it before finalize_nir, but then I also wonder why radeonsi nukes those uniforms
<airlied>
karolherbst: no idea why, mareko might think it saves cycles later
<airlied>
karolherbst: why the need to move req_local_mem?
<karolherbst>
so I can create the CSO before launching it
<dolphin>
airlied: my bad, there was just a ton of new patches added and my dim status-fu was weak
<dolphin>
maybe dim status should display the last merged tag, too...
<airlied>
karolherbst: so I don't think llvm can avoid that
<airlied>
it probably gets used for bounds checking static accesses
<karolherbst>
but how does that actually work for CL then?
macromorgan has joined #dri-devel
<mareko>
karolherbst: uniforms are dead code after lowered to ubo
<karolherbst>
right... I guess this topic would be resolved by using a proper ubo anyway
<mareko>
no idea what the topic is
<karolherbst>
just rusticl relies on the uniforms being there after finalize_nir
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
gio has joined #dri-devel
heat_ has quit [Remote host closed the connection]
rahul_janga has joined #dri-devel
heat_ has joined #dri-devel
sdutt has joined #dri-devel
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #dri-devel
bmodem has quit []
linkmauve has left #dri-devel [Error from remote client]
jewins has joined #dri-devel
<karolherbst>
airlied: another thing I was wondering about how we can make the transition to using cb0 instead, but the nir interfaces are a bit problematic there
pcercuei has quit [Read error: Connection reset by peer]
<karolherbst>
cb0 as in like GL uniforms
linkmauve has joined #dri-devel
pcercuei has joined #dri-devel
jewins has quit [Quit: jewins]
Company has joined #dri-devel
jewins has joined #dri-devel
FireBurn has joined #dri-devel
<FireBurn>
With great stuggle I've built rusticl, but I'm not sure how to use it now it's actually build, clinfo shows its there but no devices
<karolherbst>
FireBurn: have to enable drivers like with clover: LP_CL=1 or IRIS_ENABLE_CLOVER=1
<FireBurn>
Does it work with radeonsi?
<karolherbst>
no
srslypascal is now known as Guest356
srslypascal has joined #dri-devel
<karolherbst>
working on that though and I think airlied got real close
cengiz_io has joined #dri-devel
kts has joined #dri-devel
<FireBurn>
LP_CL=1 clinfo should show a device right?
<karolherbst>
yeah
<karolherbst>
well you also need to point towards the ICD file
<FireBurn>
Number of devices 0
<karolherbst>
OCL_ICD_VENDORS should point to it, but there is also devenv which should just do it automatically I think? Not sure if that works out so great
<karolherbst>
FireBurn: what's the plattform used?
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
<FireBurn>
Platform Name rusticl
<karolherbst>
is libclc installed?
<FireBurn>
Yeah
<karolherbst>
mhh
<FireBurn>
llvm build with -DLLVM_ENABLE_DUMP=ON
<FireBurn>
The SPIRV backend is enabled
<karolherbst>
yeah, it wouldn't compiler otherwise
<karolherbst>
wondering what's up with llvmpipe...
<FireBurn>
I'm using llvm-15, clang-15, lld-15 and spirv-llvm-translator from the 15 branch
<karolherbst>
FireBurn: I assume you also enabled the softpipe gallium driver?
<FireBurn>
Oh do I need to override the gallium driver too?
Guest356 has quit [Ping timeout: 480 seconds]
<karolherbst>
uhm.. no, you shouldn't
<karolherbst>
I suspect it fails somewhere..
<karolherbst>
FireBurn: updated to latest main?
<FireBurn>
Yip
<karolherbst>
the only reason llvmpipe won't load would be not finding libclc
<FireBurn>
IS there a debug environment variaable
<karolherbst>
yeah.. not yet. seems like I might want to add one to print some things happening, but generally there aren't many places it can go wrong once rusticl is loaded
<FireBurn>
Libclc failed to load. Please make sure it is installed and provides spirv-mesa3d-.spv and/or spirv64-mesa3d-.spv
<karolherbst>
:)
<karolherbst>
there ya go
<karolherbst>
could be that we get the path wrong, because that's really a hacky mess atm (but same for clover)
<karolherbst>
I suspect it didn't install the *.spv files
<FireBurn>
Just the amdgpu ones
<karolherbst>
yeah.. that's the problem then
lkw has quit [Ping timeout: 480 seconds]
<karolherbst>
I know some distributions updated their packages (e.g. Fedora), but the one you are using might not be
<karolherbst>
would make sense ti file a packaging bug if that's the case
<karolherbst>
but if you installed it yourself, you have to enable the spirv-llvm-translator tooling before handling libclc
phomes has quit [Quit: Page closed]
<FireBurn>
So that's now in/usr/share/clc/spirv-mesa3d-.spv
<karolherbst>
the 64 bit one as well?
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
<FireBurn>
I'll add that now, thought it was a naming thing
<FireBurn>
./luxmark: line 12: 788003 Aborted (core dumped) ./luxmark.bin "$@"
<karolherbst>
hum...
<karolherbst>
that's with llvm-15, right?
<FireBurn>
That was on luxball, yeah llvm-15
<karolherbst>
speicifc release or git tag?
<FireBurn>
15.0.0
<karolherbst>
currently on 13, because that's what my distribution ship. Maybe I'll hit it as well on 15
<karolherbst>
Mind filing a bug so we can track it?
<karolherbst>
(also suggest improving the README for all the points you needed to figure out)
<FireBurn>
Yeah I was trying to update the gentoo ebuilds to add it in
<FireBurn>
On scene hotel lobby, it's using 100% CPU and 26% of memory on a 64GB system
<karolherbst>
yeah... compiling big kernels is a bit problematic atm
<karolherbst>
I'll work on that hoefully this week
<FireBurn>
Cool
<karolherbst>
clover has the same issue though as atm we inline everything to one big functions
<karolherbst>
and those kernels can pile up millions of SSA values :(
<FireBurn>
I might switch back to the open ROCm stuff, I got it build using the system llvm, but had issues running it along side radeonsi due to it adding the same options twice, and it's totally busted with llvm-15 atm
<airlied>
karolherbst: the first patch I wrote was lower kernel input to ubo0
<airlied>
and binding input data to cb0
lemonzest has quit [Quit: WeeChat 3.5]
fxkamd has joined #dri-devel
fab has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
<FireBurn>
mesa: CommandLine Error: Option 'h' registered more than once!
<FireBurn>
LLVM ERROR: inconsistency in registered CommandLine options
<FireBurn>
rocm now working with system llvm-15, works great with luxmark-3 if I disable fast-math (think it's a known libclc issue)
<FireBurn>
luxmark 4 fails unless I use softpipe
fab has quit [Ping timeout: 480 seconds]
rahul_janga has quit [Ping timeout: 480 seconds]
cengiz_io_ has joined #dri-devel
<karolherbst>
yeah.. fast math is kind of broken on AMD.. no idea why, some LLVM bug
<karolherbst>
airlied: okay, cool. Do you have the patches somewhere?
lkw has quit [Ping timeout: 480 seconds]
<karolherbst>
though cb0 is a bit annoying to handle, so I am bit careful of making that change
Duke`` has joined #dri-devel
cengiz_io has quit [Ping timeout: 480 seconds]
<airlied>
karolherbst: not in patch form, still haven't got a test to execute
<karolherbst>
ahh, I see
frieder has quit [Remote host closed the connection]
<karolherbst>
airlied: what gallium API are you using? Because we can't use set_constant_buffer for that and I didn't check what's the proper API for binding cb0
<airlied>
karolherbst: I'm hacking it inside the driver
<airlied>
but using set_constant_buffer
<karolherbst>
I see
<karolherbst>
that's not going to work for drivers not lowering uniform to ubos though
<karolherbst>
I think...
<karolherbst>
or maybe it is, but cb1 is ubo0
<karolherbst>
unless lowered
<airlied>
just use set_constant_buffer with load_uniform maybe, not sure what is best there
lemonzest has joined #dri-devel
<karolherbst>
load_uniform is really 32 bit centric though :/
* airlied
wonders if that is my bug
<karolherbst>
or well... not byte based
<karolherbst>
it's more "component" based than anything really
dviola has joined #dri-devel
lkw has joined #dri-devel
<karolherbst>
I think if we want to use cb0 for real, we have to make load_uniform to take a byte address instead of whatever it takes today
<airlied>
karolherbst: just ue cb1 :-)
<karolherbst>
heh
<karolherbst>
well we want to use real ubos for constant memory at some point though
<karolherbst>
airlied: though I think we can mix cb0 with load_kernel_input for now
<karolherbst>
I'll dig into this and figure out what's the actual correct way of binding cb0 through gallium
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan_ has joined #dri-devel
macromorgan has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
Guest341 has quit [Remote host closed the connection]
macromorgan_ has quit [Ping timeout: 480 seconds]
kbingham has joined #dri-devel
jadahl has joined #dri-devel
<karolherbst>
airlied: yeah soo.. just using cb0 doens't seem to work on irist, but I was sure I made it work in the past.. maybe I did something else back then
<karolherbst>
ahh because iris puts it into a special one.. uhh
sdutt has quit []
sdutt has joined #dri-devel
<anholt>
enunes: --jobs is outside the toml, yeah
<anholt>
we do need to add some support for splitting some sets of tasks to single-threaded at some point, for some piglit display stuff. that might help you when someone gets around to it
<enunes>
anholt: thanks, so for now I'm ok to have a separate job for it so I can specify a different job limit
<anholt>
yeah
<enunes>
any thoughts on the xorg config hack thing or that pending MR?
<anholt>
sorry, I don't have any context
<karolherbst>
airlied: uhh.. every path is quite some work. If I want to use cb1, I'd have to bind a real ubo with a proper struct definition and everything. If I want to use cb0, I have to change backend compilers to actually use cb0 for load_kernel_input, and If I want to fix load_uniform, I have to touch all the backend compilers as well... kind of prefer doing the cb0 at load_kernel_input option as this is probably the easiest path
<karolherbst>
for now at least
<karolherbst>
want to use a proper ubo, but then we lose cb0 :/
<enunes>
it seems that on some embedded platforms, at least Amlogic ones using meson-drm, Xorg fails to detect the correct device to use as the display, so currently it still needs some manual config file to work
<enunes>
I could get it to work in CI with that manual config, but we probably dont want it in CI
<enunes>
I dont know enough about Xorg internals to know if it is a bug there or the driver is reporting something wrong
<enunes>
at least that MR claims to have fixed it but it's stale now for 2 years
<anholt>
sounds like something's real busted in your stack and it needs some love? you shouldn't ever need a config file.
<enunes>
well it's not even my stack, it's the display stack :)
tursulin has quit [Ping timeout: 480 seconds]
<anholt>
as a GL/VK driver author, working with the displays attached to your platform is part of the job. :P
<enunes>
but yeah we really shouldn't need a config though currently it only works with it, I dont know much really where to start to get it fixed for Xorg. it does work with other display hardware or other applications
<anholt>
1) make sure you have kmsro set up for that display. 2) read the xorg log 3) start putting debug printfs in dmabuf handling code?
<Plagman>
the one sentence summary is that devcoredump is cool and desirable for telemetry/reporting and we'll be using that (it's been added to amdgpu since that convo), but we still need an actual api for session management in response to gpu errors, as some amount of cleanup might be required depending on what triggers it or who's active at the time (some apps that don't have robustness, etc) - graphics api robustness hooks are out of scope for
<Plagman>
this, this is happening outside of the gfx client
sravn has quit [Remote host closed the connection]
sravn has joined #dri-devel
Haaninjo has joined #dri-devel
ybogdano has joined #dri-devel
jeeeun8413 has quit []
<lina>
Sooooo I just reached the Panfrost kernel driver line count and so far my driver only initializes the GPU and receives one statistics message. Doesn't even know anything about rendering yet.
jeeeun8413 has joined #dri-devel
<lina>
Yeah, these Apple GPUs are overcomplicated...
<lina>
(Half of that is just declaring and populating the giant shared memory structures needed to initialize the GPU firmware...)
<HdkR>
:D
<anholt>
enunes: what gpu device is this?
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
mvlad has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
warpme___ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
orbea has quit [Read error: No route to host]
Duke`` has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
Newbyte has quit [Write error: connection closed]
DavidHeidelberg[m] has quit [Write error: connection closed]
YaLTeR[m] has quit [Write error: connection closed]
masush5[m] has quit [Write error: connection closed]
ella-0[m] has quit [Write error: connection closed]
ralf1307[theythem][m] has quit [Write error: connection closed]
frytaped[m] has quit [Write error: connection closed]
PiGLDN[m] has quit [Write error: connection closed]
mripard has quit [Write error: connection closed]
cwfitzgerald[m] has quit [Write error: connection closed]
sigmoidfunc[m] has quit [Write error: connection closed]
JosExpsito[m] has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
Anson[m] has quit [Write error: connection closed]
kunal_10185[m] has quit [Write error: connection closed]
x512[m] has quit [Write error: connection closed]
dafna33[m] has quit [Write error: connection closed]
danylo has quit [Write error: connection closed]
xerpi[m] has quit [Write error: connection closed]
unrelentingtech has quit [Write error: connection closed]
r[m] has quit [Write error: connection closed]
Soroush has quit [Write error: connection closed]
martijnbraam has quit [Write error: connection closed]
robertmader[m] has quit [Write error: connection closed]
GeorgesStavracasfeaneron[m] has quit [Write error: connection closed]
reactormonk[m] has quit [Write error: connection closed]
naheemsays[m] has quit [Write error: connection closed]
Mis012[m] has quit [Write error: connection closed]
moben[m] has quit [Write error: connection closed]
Mershl[m] has quit [Write error: connection closed]
egalli has quit [Write error: connection closed]
ambasta[m] has quit [Write error: connection closed]
RAOF has quit [Write error: connection closed]
Dylanger has quit [Write error: connection closed]
robertfoss[m] has quit [Write error: connection closed]
zamundaaa[m] has quit [Write error: connection closed]
Andy[m] has quit [Write error: connection closed]
doras has quit [Write error: connection closed]
yshui` has quit [Write error: connection closed]
viciouss[m] has quit [Write error: connection closed]
Tooniis[m] has quit [Write error: connection closed]
testing has quit [Write error: connection closed]
pac85[m] has quit [Write error: connection closed]
pushqrdx[m] has quit [Write error: connection closed]
DemiMarie has quit [Write error: connection closed]
eyearesee has quit [Write error: connection closed]
dcbaker has quit [Write error: connection closed]
knr has quit [Write error: connection closed]
sjfricke[m] has quit [Write error: connection closed]
Strit[m] has quit [Write error: connection closed]
nyorain[m] has quit [Write error: connection closed]
jasuarez has quit [Write error: connection closed]
jekstrand[m] has quit [Write error: connection closed]
kunal10710[m] has quit [Write error: connection closed]
AlexisHernndezGuzmn[m] has quit [Write error: connection closed]
onox[m] has quit [Write error: connection closed]
michael5050[m] has quit [Write error: connection closed]
Ella[m] has quit [Write error: connection closed]
nielsdg has quit [Write error: connection closed]
hasebastian[m] has quit [Write error: connection closed]
znullptr[m] has quit [Write error: connection closed]
jenatali has quit [Write error: connection closed]
T_UNIX has quit [Write error: connection closed]
gagallo7[m] has quit [Write error: connection closed]
Sumera[m] has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
tleydxdy has quit [Write error: connection closed]
Guest202 has quit [Write error: connection closed]
Vin[m] has quit [Write error: connection closed]
zzoon[m] has quit [Write error: connection closed]
kunal_1072002[m] has quit [Write error: connection closed]
hch12907 has quit [Write error: connection closed]
KunalAgarwal[m] has quit [Write error: connection closed]
kusma has quit [Write error: connection closed]
mairacanal[m] has quit [Write error: connection closed]
undvasistas[m] has quit [Write error: connection closed]
gdevi has quit [Write error: connection closed]
ramacassis[m] has quit [Write error: connection closed]
Mangix has joined #dri-devel
<karolherbst>
lina: well.. hopefully once more stuff is figured out it might be possible to simplify thing
arisu has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
chipxxx has quit [Read error: No route to host]
ngcortes has quit [Ping timeout: 480 seconds]
arisu has quit [Remote host closed the connection]
arisu has joined #dri-devel
fab has quit [Quit: fab]
lkw has quit [Quit: leaving]
ybogdano has joined #dri-devel
lygstate has joined #dri-devel
ngcortes has joined #dri-devel
gio has quit [Ping timeout: 480 seconds]
jenatali has joined #dri-devel
<jenatali>
Ugh I was apparently reconnected an not identified...
<jenatali>
karolherbst: I'm on leave at the moment so barely following along but I'm interested in this line of thinking and potentially hooking up rusticl to the d3d12 gallium driver in favor of not maintaining a separate runtime for us eventually
<jenatali>
karolherbst: In a few weeks I'd love to have a more in-depth conversation about what we do currently to see how it lines up with what you're thinking. Maybe at XDC if you're going to be there?
<karolherbst>
jenatali: yeah, I'll be on XDC and even giving a talk about rusticl
<jenatali>
Cool
<jenatali>
Looking forward to it
<karolherbst>
jenatali: anyway, for zink we are planning to add a new SPIRV program type so drivers can consume the SPIR-V directly
<karolherbst>
which I think is all you'd need on top the current thing
<jenatali>
Yeah DXIL is getting close, but still doesn't have pointers - but the lowering for that isn't too bad
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
<karolherbst>
yeah.. my thinking was just that it might be easier for you to handle the SPIR-V than getting a nir passed in. Though I suspect you already have all the translation code done for NIR...
<karolherbst>
not sure what would be better for you
<jenatali>
The bigger problem is still the typed vs typeless images I think. Maybe I'll try to convince our HLSL team to support typeless images/textures where the return type only comes from instructions
<jenatali>
Not sure. All the lowering is nir right now but we could just run vtn on it
<karolherbst>
we could wire up CL through zink first and then you could say "look, adding support for that in HLSL would allow us to bridge the 15% perf gap to zink" :P
<jenatali>
Just a matter of making the bindings line up
<jenatali>
Lol I'm sure we've got lower hanging fruit for CL. Notably the 32bit fma
<karolherbst>
heh
<karolherbst>
probably
gouchi has quit [Remote host closed the connection]
<jenatali>
Having to use the version from libclc bloats code size SO much, but we need it for precision
<karolherbst>
yeah.. you really need both in the IR
<jenatali>
Yeah. It's on the backlog. Maybe in shader model 6.8
<karolherbst>
it's the only sane way of handling it. Could also be an instruction modifier, but...
<jenatali>
We've got it for doubles, just not floats. Kind of crazy TBH
<karolherbst>
...
<jenatali>
Anyway, I'm gonna get back to vacation, just wanted to let you know I'm interested and if you're able to hold off on making big decisions for a little while I'd love to participate more in the discussion
<karolherbst>
atm I just want to lower the launching overhead of the gallium API :)
<karolherbst>
nothing which should impact d3d12
<jenatali>
Well the ubo stuff is relevant I think
<karolherbst>
sure, but with my change it makes the kernel input buffer behave exactly like GL compute uniforms
<jenatali>
But yeah nothing impacts me yet since we're not supporting CL via gallium yet
<karolherbst>
the other thing is I want to move the "local_mem" property into launch_grid, so I can create the CSO before launching
<karolherbst>
which is a must :)
lygstate has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]