ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
ybogdano has quit [Ping timeout: 480 seconds]
nchery is now known as Guest142
nchery has joined #dri-devel
nchery is now known as Guest143
nchery has joined #dri-devel
Guest142 has quit [Ping timeout: 480 seconds]
Guest143 has quit [Ping timeout: 480 seconds]
karolherbst has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
benettig has quit [Server closed connection]
benettig has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
SanchayanMaity has quit [Server closed connection]
SanchayanMaity has joined #dri-devel
Rayyan_ has joined #dri-devel
Rayyan has quit [Server closed connection]
mbrost has joined #dri-devel
sdutt has joined #dri-devel
kts has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
alyssa has joined #dri-devel
<alyssa>
airlied: if you don't intend on reviewing, could I at least get an ack on !18136?
<alyssa>
it apparently doesn't hose zink+radv and zmike acked, but this is your code so.
<daniels>
alyssa: he’s in Ireland atm, so it might be next week
<alyssa>
daniels: MR is from August, I'm not in a hurry :)
<alyssa>
(as long as it gets solved Eventually)
<daniels>
heh
zf has quit [Server closed connection]
zf has joined #dri-devel
camus has joined #dri-devel
exit70 has quit [Server closed connection]
<DrNick>
hmm bindgen chokes on emmintrin.h
<karolherbst>
uhhh....
<karolherbst>
DrNick: you have mixed llvm versions somehow :(
<karolherbst>
this happens if rust uses a different LLVM version than bindgen
<karolherbst>
I totally forgot about this annoying bug
<karolherbst>
*rustc
<karolherbst>
DrNick: just make sure that meson and ninja always run with the same PATH
exit70 has joined #dri-devel
<karolherbst>
I dont' really recall what the precise issue was, just that once you have a local compiled LLVM besides your system one, yo really need to be careful about that
<DrNick>
I don't have a locally compiled LLVM
<karolherbst>
huh
<karolherbst>
how did you install rustc?
<karolherbst>
and bindgen
<DrNick>
dnf install rustc
<DrNick>
rust links to LLVM 14, bindgen is complaining about a LLVM 14 header
<DrNick>
oh bindgen links to clang 13
<karolherbst>
uhhh....
<karolherbst>
might just as well use rustup :(
<karolherbst>
but I think I remember this now
<karolherbst>
yeah... I had the same issue
<karolherbst>
fedora fail :(
<karolherbst>
should add a note to the README.md file about that as well
<karolherbst>
DrNick: be lucky, when I hit this issue, I debugged it for an entire day 🙃
<karolherbst>
came out of nowhere
<alyssa>
I like DEbia
<alyssa>
Debia
<alyssa>
DEbian
<alyssa>
Debian
<alyssa>
4th times the charm
<DrNick>
dnf remove clang13-libs fixed it
<DrNick>
because clang13 and clang (14) both provide libclang.so.13
<DrNick>
because apparently the ABI didn't change
<DrNick>
and which one you get depends on which order the packages were installed and how the ld.so search path ended up
<DrNick>
that's a quality design right there
<karolherbst>
uhhhh
<karolherbst>
:(
<karolherbst>
the heck
<DrNick>
the fun thing is that there's a libclang-cpp.so.13 and 14, so that probably causes exciting problems
<emersion>
no, they're used to implement explicit sync
<emersion>
this one signals end of rendering operation, not vsync
<Vanfanel>
emersion: so these calls don't wait for eglSwapBuffers() to complete? Is there another way to do that?
<emersion>
weston uses eglSwapBuffers in a non-blocking fashion
robclark has quit [Server closed connection]
robclark has joined #dri-devel
<Vanfanel>
emersion: I understand it's up to the compositors to implement a blocking or non-blocking eglSwapBuffer(), right? Then, is there any compositor implementing a blocking eglSwapBuffers()?
<emersion>
no, it's not up to the compositor
<Vanfanel>
First major missconception, sorry
<emersion>
it's up to the EGL user
<emersion>
setting eglSwapInterval to zero and pacing the swaps correctly results in non-blocking eglSwapBuffers
<Vanfanel>
emersion: What I need is a blocking eglSwapBuffers(). I know it sacrifices performance but it's needed to honor a certain RetroArch setting.
<emersion>
i don't understand
<Vanfanel>
emersion: so, eglSwapInterval() to 1, and then eglSwapBuffers() will be blocking, right?
<emersion>
eglSwapBuffers blocks by default
<Vanfanel>
emersion: ah, I understand. Setting eglSwapInterval(0) is required for non, blocking, right?
eletrotupi has quit [Server closed connection]
eletrotupi has joined #dri-devel
<emersion>
ye
jimjams has quit [Server closed connection]
jimjams has joined #dri-devel
<Vanfanel>
emersion: and is that true for WLRoots-based compos and Weston? I mean: is blocking eglSwapBuffers() the current default on those as of current code?
<emersion>
for all platforms, all compositors
<Vanfanel>
emersion: ok, thanks! Again very patient with me, thanks
<emersion>
np
KunalAgarwal[m][m] is now known as KunalAgarwal[m]
<KunalAgarwal[m]>
pq: or anyone, can you help me with how to set external framebuffer as render target(not the opengl framebuffer)
<KunalAgarwal[m]>
I have my texture in framebuffer 1 which is read only, I want to (first transfer) set framebuffer2 as render target which can be written to
bwidawsk has quit [Server closed connection]
bwidawsk has joined #dri-devel
kts has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
pochu has quit [Quit: Lost terminal]
devilhorns has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
Daaanct12 has quit [Quit: Quitting]
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
genpaku has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<Vanfanel>
emersion: Still, there's something I don't quite understand. If eglSwapBuffers() performs an implicit buffer swap, how comes it can be blocking? Maybe I am not understanding what blocking means here: Does "blocking" mean it won't return untill the new buffer is on screen?
<emersion>
why do you call the buffer swap "implicit"? "eglSwapBuffers" is a pretty explicit buffer swap
<emersion>
yes, that definition is mostly correct i think, although "on screen" may not be 100% accurate
<emersion>
what the Mesa Wayland implementation does is submit the buffer to the compositor and then wait for a wl_surface.frame event
<vsyrjala>
isn't it supposed to block *before* the swap, not after?
<emersion>
ah, yeah, maybe
ambasta[m] has joined #dri-devel
Andy[m] has joined #dri-devel
bylaws has joined #dri-devel
chema has joined #dri-devel
RAOF has joined #dri-devel
cleverca22[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
colemickens has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dcbaker has joined #dri-devel
dafna33[m] has joined #dri-devel
DemiMarieObenour[m] has joined #dri-devel
Anson[m] has joined #dri-devel
Guest179 has joined #dri-devel
<emersion>
i don't remember off-hand
doras has joined #dri-devel
Dylanger has joined #dri-devel
danylo has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
Ella[m] has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
GeorgesStavracasfeaneron[m] has joined #dri-devel
frytaped[m] has joined #dri-devel
gagallo7[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
testing has joined #dri-devel
halfline[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
hch12907 has joined #dri-devel
heftig has joined #dri-devel
zzoon[m] has joined #dri-devel
jasuarez has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
kunal_1072002[m] has joined #dri-devel
Guest192 has joined #dri-devel
kusma has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
masush5[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
michael5050[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
eyearesee has joined #dri-devel
nielsdg has joined #dri-devel
nyorain[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
onox[m] has joined #dri-devel
pac85[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
r[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
robertfoss[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
sjfricke[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
Soroush has joined #dri-devel
unrelentingtech has joined #dri-devel
viciouss[m] has joined #dri-devel
MatrixTravelerbot[m]1 has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
pmoreau is now known as Guest202
<emersion>
so the blocking may be implemented via: wait for the last wl_surface.frame callback, then submit the new buffer to the compositor
<emersion>
regardless, the important part is that if you use eglSwapInterval(1), and you don't take too long to render, then you'll display one new frame per vblank
<lynxeye>
Mesa blocks before the swap by waiting for the frame callback, which is bad for latency but allows more parallelism between app and gpu. I don't think EGL mandates any specific behavior.
<Vanfanel>
lynxeye: is there a way to modify that to obtain the lowest possible latency while sacrifying parallelism?
<Vanfanel>
lynxeye: that would be great for low latency scenarios like RetroArch
ella-0 has joined #dri-devel
<lynxeye>
Not as far as I know, someone would need to write an EGL extension for that.
<karolherbst>
airlied: ehh no, I totally forgot :(
<emersion>
Vanfanel: if an EGL client wants to have control, they can set eglSwapInterval(0) and then manually wait for wl_surface.frame when they want to
<Vanfanel>
emersion: aahhh!! Yes, just what I was trying to find! So, wl_surface.frame arrives exactly at the moment the swap is actually done, right?
ella-0_ has quit [Read error: Connection reset by peer]
<emersion>
not exactly
<emersion>
wl_surface.frame indicates a "good time for the client to draw and submit a new frame"
<emersion>
it's also possible for a client to get presentation events
<emersion>
via the presentation-time protocol
<emersion>
to reduce latency, a client would have a time budget to render
<Vanfanel>
emersion: what would ensure lower latency with less jittering?
<emersion>
and it would start drawing at next_vblank_time - time_budget
<emersion>
the goal being to draw as late as possible, but without missing vblank
<emersion>
disclaimer, the time budget above includes more than just the time taken to render
<emersion>
the time budget also needs to include the time taken for the compositor to render, the time taken for the compositor to submit an atomic commit to KMS, and the time taken for KMS to program the hardware
<Vanfanel>
emersion: what I want to archieve is way simpler: issue a buffer swap (eglSwapInterval(0) and then eglSwapBuffers(), I guess) and block/wait until the new buffer is onscreen. No matter how much time to wait.
<emersion>
then you can just set eglSwapInterval(0) and wait for wl_surface.frame after swapping buffers
<kts>
What can I add to original report to make it better with additional info?
<Vanfanel>
emersion: in the example here--> https://emersion.fr/blog/2018/wayland-rendering-loop/ ...you seem to wait *before* eglSwapBuffers(), so... the idea would be doing the same but *after* eglSwapBuffers(), right?
nchery has quit [Remote host closed the connection]
Flynn has joined #dri-devel
Flynn has left #dri-devel [#dri-devel]
fab has quit [Quit: fab]
fab has joined #dri-devel
Flynn has joined #dri-devel
flynn1 has joined #dri-devel
Flynn has left #dri-devel [#dri-devel]
danilo has joined #dri-devel
fahien has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
sdutt has quit [Remote host closed the connection]
sdutt has joined #dri-devel
DavidHeidelberg[m] has quit []
DavidHeidelberg[m] has joined #dri-devel
flynn1 has quit []
h0tc0d3 has quit [Remote host closed the connection]
h0tc0d3 has joined #dri-devel
<DavidHeidelberg[m]>
test
JohnnyonFlame has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
<tomeu>
DavidHeidelberg[m]: it worked!
<DavidHeidelberg[m]>
can I assign more than 2048 MiB to lavapipe?
<zamundaaa[m]>
emersion: as you've been looking into the driver stuff and clearly understand more about it than me, do you think that updating only single planes asynchronously would be feasible?
heat has joined #dri-devel
<zamundaaa[m]>
The use case would be that if you have an ultrawide, there's only one display - but enough space for having for example a game and a video on the same monitor
<zamundaaa[m]>
Ideally in that case, only the game should be tearing and the video shouldn't
<emersion>
zamundaaa[m]: hm, i don't know if the hardware supports it
bmodem has joined #dri-devel
<emersion>
but in general you can't reliably expect this to work
<emersion>
if you're going to use 2 planes, then you need a fallback for the 1 plane case
<zamundaaa[m]>
A fallback for such a thing would certainly be necessary and not hard, just blit from the old framebuffer. It would be quite inefficient though
<zamundaaa[m]>
That is assuming the compositor can schedule async frames accurately enough ofc, which isn't currently the case
flynnjiang has joined #dri-devel
srslypascal is now known as Guest236
srslypascal has joined #dri-devel
<alyssa>
airlied: understandabe.
<airlied>
DavidHeidelberg[m]: I think there are some 32-bit limits it hits, and some of those might be signed
<alyssa>
airlied: I don't understand the Zink path
<alyssa>
Zink seems to support some weird mishmash format
<gawin>
(wasn't able to get it running) I think it's missing something
<Vanfanel>
emersion: looking at the wl_display_roundtrip() implementation, I am thinking... Can't I simply call wl_display_roundtrip() after eglSwapBuffers()? Wouldn't that be a simple way to block as I wanted?
<emersion>
nope
<emersion>
wl_display_roundtrip is a ping-pong with the compositor
<Vanfanel>
ah, it was too good to be true :P
<emersion>
the compositor will send the reply event immediately
<emersion>
if you do it in a loop, you're spamming the compositor
<Vanfanel>
ok, I see
kts has quit [Ping timeout: 480 seconds]
<Vanfanel>
emersion: I see a wl_event_queue is used. Should I create one ad-hoc? I mean, RetroArch doesn't seem to have one declared in the wayland stuff.
frankbinns1 has quit []
frankbinns has joined #dri-devel
<emersion>
you shouldn't need one
<emersion>
wl_event_queue is for multi-threaded clients
<emersion>
hm, i realize that the wl_display_roundtrip() impl is more complicated than you'd need
<emersion>
what you'd need is something like
<emersion>
bool frame_done = false;
<emersion>
callback = wl_surface_frame(surface);
<emersion>
wl_callback_add_listener(callback, &frame_listener, &frame_done); // sets frame_done to true when receiving event
<emersion>
while (!frame_done && wl_display_roundtrip(display) == 0) {}
<emersion>
something like this
<emersion>
err
<emersion>
while (!frame_done && wl_display_dispatch(display) == 0) {}
<emersion>
^ better
<emersion>
make sure you commit the surface after wl_surface_frame()
<emersion>
eglSwapBuffers() will commit the surface
<Vanfanel>
emersion: that was very kind of you to give me so much help! :D
<emersion>
the `frame_listener` above is very similar to libwayland's `sync_listener`
<emersion>
just sets the flag basically
<emersion>
yeah, np
<Vanfanel>
emersion: I suspect some love for low-latency RetroArch, huh? :D
<emersion>
ah, no, i don't use it, sorry!
Haaninjo has joined #dri-devel
<Vanfanel>
ah ok, ok! I though you may use it, because of the pacman references in your examples
pjakobsson has quit [Remote host closed the connection]
bbrezill1 has quit []
bbrezillon has joined #dri-devel
kts has joined #dri-devel
fab has joined #dri-devel
<DavidHeidelberg[m]>
airlied: I'll test.
<DavidHeidelberg[m]>
gawin: I think this is the most complete version (95% sure)
jewins has joined #dri-devel
nchery has joined #dri-devel
nchery has quit []
<Vanfanel>
emersion: got it to work! But framerate isn't smooth as it is with eglSwapBuffers() only.
nchery has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
Duke`` has joined #dri-devel
<MrCooper>
Vanfanel: there's a fundamental trade-off between low latency & high risk of frame drops and high latency & low risk of frame drops
<MrCooper>
also, there's no explicit mechanism yet by which the client can know the deadline for attaching the next buffer to the surface; the best guess is around one refresh cycle after the frame event
nchery has quit [Remote host closed the connection]
<Vanfanel>
MrCooper: and framerate smoothness wasn't affected
iive has joined #dri-devel
<Vanfanel>
MrCooper: I mean: maybe it is because it uses threads instead of waiting in a while() loop?
<MrCooper>
maybe; which Wayland compositor are you testing on?
flynnjiang has joined #dri-devel
<Vanfanel>
MrCooper: Weston
<DavidHeidelberg[m]>
airlied: bumped to 3G, checksum still matches the broken version. Is that comment above #define about 32-bit operations still valid these days?
nchery has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<airlied>
DavidHeidelberg[m]: I expect so, as I said I think there are some signed 32-bit limits in places around llvm operations
devilhorns has quit []
apinheiro has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
mwalle has quit [Quit: WeeChat 3.0]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
tursulin has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
jkrzyszt has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
bluepenquin has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
tzimmermann has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
<Vanfanel>
emersion: I found out that having eglSwapInterval(0) gives the expected framerate smoothness. Does it make sense to wait for the event in that case? I can sense less input lag.
nchery_ has joined #dri-devel
<Vanfanel>
emersion: I mean: with eglSwapInterval(1), eglSwapBuffers() is blocking. BUT seems to me that, even so, waiting for the event gives better latency.
<Vanfanel>
emersion: I mean: with eglSwapInterval(0), eglSwapBuffers() is blocking. BUT seems to me that, even so, waiting for the event gives better latency.
nchery is now known as Guest260
nchery_ is now known as nchery
<emersion>
it would blocking when running out of buffers I think, which should give you the worse latency
<emersion>
or it would render as fast as possible, wasting GPU power
Guest260 has quit [Ping timeout: 480 seconds]
<Vanfanel>
emersion: so, waiting for the event only makes sense with swap interval 0, right?
<Vanfanel>
emersion: so, waiting for the event only makes sense with swap interval 1, right?
<Vanfanel>
(I ALWAYS get it wrong! sorry!)
MatrixTravelerbot[m]1 has quit []
colemickens has quit []
LaughingMan[m] has quit []
cleverca22[m] has quit []
arisu has quit []
Guest179 has quit []
chema has quit []
dcbaker has quit []
bylaws has quit []
neobrain[m] has quit []
kallisti5[m] has quit []
mripard has quit []
cmeissl[m] has quit []
ybogdano has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
Guest192 has quit []
heftig has quit [Quit: Client limit exceeded: 20000]
tomba has quit [Quit: Client limit exceeded: 20000]
mwalle has joined #dri-devel
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
<macromorgan>
is there a way/is it "something done" to have a crtc feed to multiple outputs (in this case looking at either an HDMI or DSI output)?
<emersion>
yes
<emersion>
some drivers support this
<MrCooper>
Vanfanel: there's no such hard rule
<macromorgan>
okay... I'm messing around again on that Rockchip driver, so far I found out the hard way that you need unique primary planes per CRTCs...
mripard has joined #dri-devel
<MrCooper>
Vanfanel: waiting for the frame event after SwapBuffers means there's no real difference between swap interval 0 or 1
<Plagman>
pq: airlied: re-reading the conversation on https://lore.kernel.org/dri-devel/20220308180403.75566-1-contactshashanksharma@gmail.com/, seems like people eventually understood that the proposed interface isn't equivalent to devcoredump and has valid uses for a session manager daemon - was there any feedback necessitating a resend or could this be merged as-is?
<Plagman>
discussion veered towards unrelated discussion on devcoredump internals - note: there has since also been a series about amdgpu devcoredump, which has other uses
gallo2 has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
sdutt__ has joined #dri-devel
sdutt_ has quit [Read error: Connection reset by peer]
ybogdano has quit [Read error: Connection reset by peer]
shankaru has quit [Read error: Connection reset by peer]
aswar002 has quit [Write error: connection closed]
mdnavare has quit [Read error: Connection reset by peer]
dolphin has quit [Write error: connection closed]
rsripada has quit [Write error: connection closed]
aswar002 has joined #dri-devel
ybogdano has joined #dri-devel
mdnavare has joined #dri-devel
dolphin has joined #dri-devel
rsripada has joined #dri-devel
shankaru has joined #dri-devel
lstrano has quit [Read error: Connection reset by peer]
lstrano has joined #dri-devel
Company has joined #dri-devel
lkw has joined #dri-devel
bluepenquin has left #dri-devel [#dri-devel]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
lplc has joined #dri-devel
dakr has joined #dri-devel
danilo has quit []
dakr has quit []
dakr has joined #dri-devel
ybogdano has joined #dri-devel
thaytan has quit [Ping timeout: 480 seconds]
lkw has quit [Quit: leaving]
Vanfanel has quit [Quit: leaving]
ngcortes has quit [Read error: Connection reset by peer]
ngcortes_ has joined #dri-devel
unerlige1 has quit [Read error: Connection reset by peer]
unerlige1 has joined #dri-devel
lstrano has quit [Read error: Connection reset by peer]
Ryback_ has quit [Write error: connection closed]
lstrano has joined #dri-devel
Ryback_ has joined #dri-devel
pzanoni` has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
mvlad has quit [Remote host closed the connection]
pzanoni` has left #dri-devel [#dri-devel]
pzanoni has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
ngcortes_ has quit [Ping timeout: 480 seconds]
unerlige1 has quit [Read error: Connection reset by peer]
unerlige1 has joined #dri-devel
lstrano has quit [Read error: Connection reset by peer]
Ryback_ has quit [Read error: Connection reset by peer]
mattrope_ has quit [Read error: Connection reset by peer]
lstrano has joined #dri-devel
mattrope_ has joined #dri-devel
pzanoni` has joined #dri-devel
mbrost_ has joined #dri-devel
pzanoni has quit [Read error: Connection reset by peer]
jewins has quit [Read error: Connection reset by peer]
mbrost has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
Ryback_ has joined #dri-devel
jewins has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
gio has quit [Ping timeout: 480 seconds]
jewins has quit [Quit: jewins]
apinheiro has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
ngcortes has joined #dri-devel
alanc has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
iive has quit [Quit: They came for me...]
apinheiro has quit [Quit: Leaving]
ppascher has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
<karolherbst>
who works on virgl these days? I am thinking about moving pipe_compute_state.req_local_mem into pipe_grid_info and virgl seems to be the only non trivial user of this
<karolherbst>
other drivers are just storing it for later use
<karolherbst>
and for CL I'll need to set this value at launch_grid time and not before (in order to reduce kernel launching overhead)
pzanoni` has left #dri-devel [#dri-devel]
off^ has joined #dri-devel
<anholt>
karolherbst: I think for the encode shader you should be able to just use the shader_info value.
<karolherbst>
yeah, that's my plan, but drivers can't rely on that value really :/
<karolherbst>
so I want the frontend and st/mesa to pass in the full size on launch_grid time and drivers only looking at that value
<anholt>
ok, but if you want rusticl+virgl then you are going to need new virgl protocol for the launch_grid size anyway.
<karolherbst>
not wanting to do rusticl+virgl. The current interface is just not working
<karolherbst>
(and is broken for CL)
<anholt>
right. so smash in the shader_info value and call it a day, right?
<karolherbst>
well.. for GL yes, for CL no
<anholt>
and we've agreed that we don't need CL+virgl, so that's fine.
<karolherbst>
CL allos you to alocate shared mem inside the kernel and dynamically through kernel arguments
<karolherbst>
ahh.. right..
<karolherbst>
yeah I guess for virgl I could actually do that
<karolherbst>
but how would one actually change those interfaces if one really has to?
<anholt>
I would check out virglrenderer and go looking for the last protocol caps update and see how they change protocol
<zmike>
karolherbst: I thought you were putting it through set_constant_buffer? if you do that you should be able to just pass null for the grid info input pointer
pcercuei has quit [Quit: dodo]
<karolherbst>
zmike: shared memory
<karolherbst>
not the kernel input memory
<zmike>
oof
<karolherbst>
yeah.. that's a bit more hairy to touch sadly
<karolherbst>
but moving that value to launch_grid time drops a quite a bit of code
<karolherbst>
turns out every driver stored it to use it in launch_grid :D
<zmike>
not sure how I'm gonna do anything with that
<karolherbst>
yeah... vulkan is doing it the GL style where all shared mem is declared inside the shader, no?
<zmike>
yep
<karolherbst>
mind need to extend the CmdDispatch thing
<karolherbst>
*might
<zmike>
:/
<karolherbst>
so what CL allows is that you declare a "long *local some_storage" pointer as a kernel input parameter
<karolherbst>
and the size of it is defined when the application binds the kernel parameter
<karolherbst>
and the frontend collects all those together and passes it currently into the cso, but I'd like to move it into launch_grid so I can create the CSO way before that
<karolherbst>
so yeah.. guess that needs to be part of the new CL VK extension then
<karolherbst>
the hairy bit is just: alignment
<karolherbst>
so CL requires pointers to be aligned to their "base type" size.. where base can also be a double16 thing with an alignment of 0x80 :)
<karolherbst>
the CTS even tests this
<zmike>
I think at that level we can just use direct nir passthrough for now?
krushia has quit [Quit: Konversation terminated!]
<zmike>
then changing shared size is easier
<karolherbst>
so if you mix and match, and the shader declares 4 bytes but the input is a double16 thing you can't just do 4 + n * 0x80, but you also have to fill in the gap of 0x7c bytes
<karolherbst>
and the runtime passes in the offset via the kernel input buffer
<karolherbst>
so the local mem parameter actually would have to return "0x80" in this example as the offset
Namarrgon has joined #dri-devel
<karolherbst>
zmike: well.. for now we could probably really just pass through the serialized nir
<karolherbst>
it's just not a great long term solution.. anyway.. let me work on moving the CSO creation time a tad earlier, because that actually helps applications and I wanted to do that anyway
<zmike>
no harm having a mesa passthrough for now
<zmike>
can do easy shared size changes that way
<zmike>
I guess maybe with spirv passthrough we could ensure vk shaders have transparent caching for matching shaders with different sizes
<karolherbst>
it doesn't even matter
<karolherbst>
no driver actually cares about the value until dispatch time