<alyssa>
imaginapple, mali, and videocore are the 'true' tilers (-:
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
macslayer has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
flynnjiang has joined #dri-devel
Leopold has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
rcf has joined #dri-devel
co1umbarius has joined #dri-devel
ngcortes_ has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
ngcortes_ has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
yyds has joined #dri-devel
digetx is now known as Guest250
digetx has joined #dri-devel
Guest250 has quit [Ping timeout: 480 seconds]
<tarceri>
Is there anyone online that would be able to run a piglit test for me on the Nvidia OpenGL bianry driver?
<tarceri>
the hdd died in the machine I normally use for testing
<tarceri>
actually nevermind
digetx is now known as Guest256
digetx has joined #dri-devel
Guest256 has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
simondnnsn has quit [Ping timeout: 480 seconds]
Leopold has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
columbarius has joined #dri-devel
kts has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
sarnex has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
simondnnsn has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
krei-se has quit [Ping timeout: 480 seconds]
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
glennk has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
bmodem has joined #dri-devel
benjaminl has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
sima has joined #dri-devel
Company has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
krei-se has joined #dri-devel
rasterman has joined #dri-devel
sima is now known as Guest293
jsa has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
tursulin has joined #dri-devel
benjaminl has quit [Remote host closed the connection]
<Company>
I have a question
benjaminl has joined #dri-devel
<Company>
because my mental model can't handle this case
<Company>
There is external code that exports a dmabuf from GL
<Company>
in this case Epiphany
<Company>
and it doesn't do any syncing
<Company>
however, when GTK imports that dmabuf with the GL renderer, everything works fine
<Company>
but when GTK imports that dmabuf with the Vulkan renderer, things break
<Company>
and I don't get why GL works
<emersion>
vulkan does explicit sync
<Company>
what do you mean?
<Company>
I'm explicitly importing the sync fd from the dmabuf if there is one
<Company>
but there isn't one
<Company>
actually, that's not even how this codepath works, now that I think about it
<Company>
this code path probably does a glReadPixels() on the imported dmabuf
<MrCooper>
the answer to "how does GL work?" is via implicit sync
<MrCooper>
demarchi: FWIW, mailman mangles Cc only if the list subscriber enabled that option in their subscription
<Company>
how does "implicit sync" work here?
<Company>
does that just mean that if 2 apps use GL it'll just always work and if one app wants to use Vulkan, things will always break?
<Company>
that can't be, then all compositors using Vulkan would be broken
<MrCooper>
implicit sync works via the dma-buf's synchronization object
<MrCooper>
the Vulkan implementation can make that work as well
<Company>
right, the one that you'd need to import on Vulkan
<Company>
and the one that I'm pretty sure Ephy doesn't use
<MrCooper>
Ephy draws using GL?
<emersion>
do they glFlush()?
<emersion>
without glFlush() then the implicit fence is not populated
<MrCooper>
then it would break with GL in the importer as well
<Company>
Ephy has 2 processes
<Company>
the UI process and the webpage process
<Company>
and they communicate via dmabuf
<Company>
the UI process runs GTK
<Company>
and the web process runs whatever webkit does
<Company>
if you have a recent GTK at hand, you can just reproduce it with GSK_RENDERER=vulkan epiphany
<MrCooper>
presumably webkit uses GL, so the GL driver should populate the dma-buf synchronization object on glFlush(); which driver is this?
<Company>
happens on Intel and AMD
<MrCooper>
does mesa_glthread=false avoid it by any chance?
<dj-death>
Company: we should be doing implicit sync in Anv with imported BOs
<dj-death>
Company: maybe you're just getting lucking that the work submission between the importer/exported is happening in the right order with the GL renderer
<dj-death>
s/lucking/lucky/
<dj-death>
implicit sync will not be available with the new kernel driver
<Company>
yeah, that's what I'm wondering
<Company>
if ephy is just getting lucky
<Company>
but it seems a rather big guess, because it's been doing that for a year now in a released version
jfalempe has joined #dri-devel
<MrCooper>
dj-death: you still need to make it work in user space though, by extracting fences from the implicit synchronization object?
<dj-death>
MrCooper: for wsi that's happening yeah
<dj-death>
MrCooper: not for buffers imported
<Company>
they use gbm to allocate, then send the fd over to the GTK process and then eglCreateImage() in both processes
<MrCooper>
I see, so it's up to the application in this case?
<dj-death>
yeah
<MrCooper>
anyway, sounds like GTK is trying to do it, there are no fences though for some reason
<MrCooper>
Company: if there are no fences in the dma-buf after glFlush returns, that's a bug
simondnnsn has quit [Ping timeout: 480 seconds]
<dj-death>
there should be one inserted by the kernel I think
<dj-death>
at least on i915
<dj-death>
xe is different
<MrCooper>
with xe it has to be done by iris
simondnnsn has joined #dri-devel
<Company>
they do a glFlush() and then send a frame event to the GTK process
<Company>
so I suppose as long as both processes use the same GPU queue, they will commit their commands in order and everything works out smoothly?
vliaskov has joined #dri-devel
<Company>
and with the Cairo renderer (and I think Vulkan, too) this code doesn't work, because the GTK process does glReadPixels() (or glGetTexImage()) which doesn't use the GPU queue
<Company>
and if Vulkan actually straight used the dmabuf, it would probably work by the same accident
<MrCooper>
glReadPixels & glGetTexImage is GL, so should work the same as with GL otherwise
<MrCooper>
there's no accident, it's supposed to work
<Company>
if you glReadPixels() in a different process?
<MrCooper>
there seems to be a bug so that the dma-buf doesn't have fences after glFlush
<dj-death>
Company: the queues are independent
<dj-death>
Company: but the fences attached to the buffers should be taken into account for the work ordering dependency
<MrCooper>
or maybe GTK doesn't retrieve the fences correctly
<MrCooper>
that actually seems more likely :)
<Company>
GTK doesn't do anything - other than creating an EGL image and call glReadPixels() on it whenever it gets a message
<MrCooper>
and that seems to work fine?
<Company>
no
<Company>
that's the thing that doesn't work
<MrCooper>
I mean the other GL usage
<Company>
the other usage seems to work, yes
<Company>
it's what you get when you run epiphany today
kts has joined #dri-devel
<MrCooper>
glReadPixels not working might be a separate Mesa bug then
<Company>
where it creates an EGL image and when it gets a message, uses that as a source in a shader
<Company>
afaiu the glReadPixels path has never worked for Ephy
<Company>
because they disable that path when GTK uses the Cairo renderer
<Company>
and the Cairo renderer does support reading from GL textures
<MrCooper>
GL is GL, there's no distinction between different GL APIs for this
<pq>
There are no requirements like you have to re-do glEGLImageTargetTexture2DOES to make new implicit fences effective, are there?
<Company>
I'm saying that if there's a bug with glReadPixels, it's an old bug
mripard_ has joined #dri-devel
<MrCooper>
right
lynxeye has joined #dri-devel
<MrCooper>
pq: I've heard almost any possible opinion on whether or not that's necessary per the spec :/ shouldn't be necessary in practice with those Mesa drivers though
<pq>
alright
<Company>
I'm just wondering if Ephy should send some explicit sync object in their frame event
<Company>
or if glFlush() should be enough
<MrCooper>
Company: the former is needed for nvidia, the latter suffices with Mesa
<Company>
is there example code for how to do that?
<Company>
it'll be similar to how it works in Vulkan I guess, but I'd like to avoid googling how to turn a GLsync into an fd and ending up with a wrong guide
<pq>
FWIW, Weston seems to be calling glEGLImageTargetTexture2DOES on every update, but also Weston has/is been used on all kinds of drivers.
<MrCooper>
pq: mutter & Xwayland only ever call it once
<Company>
GTK requires you to recreate the GdkTexture, too - but nothing stops you from calling it only once and reusing the GL texture id
<Company>
which seems to be what ephy is doing
<MrCooper>
Company: EGL_ANDROID_native_fence_sync allows retrieving a sync_file from a GLsync
<Company>
and then you explicitly attach that to the dmabuf
<Company>
then you send the message to the GTK process, and make the GTK process reimport the dmabuf
apinheiro has joined #dri-devel
<MrCooper>
explicit sync would be sending the sync_file directly, no messing with the dma-buf synchronization object
pcercuei has joined #dri-devel
<MrCooper>
the latter can be used as a side channel though, yeah
<Company>
hrm
<Company>
that would need some way to import sync files in GTK
<Company>
seems that indeed ephy is randomly broken on nvidia
simondnnsn has joined #dri-devel
<pq>
gdk_dmabuf_texture_builder_set_sync_fd sounds off, shouldn't the fd be sent with every update rather than once on initial import?
<Company>
GTK's textures are immutable
<Company>
so you must reimport them anyway
<pq>
so no-one re-uses them? Didn't you just say some programs fish out the texture id and re-use anyway?
<Company>
you can reuse the dmabuf
<Company>
but not the GTK object
<pq>
okay
<Company>
the gtk object tracks a frozen state for some pixel
<Company>
*pixels
<Company>
"texture" is a misnomer really, but I didn't have a better name, and terms like "image" etc were all taken by X or Wayland APIs
glennk has joined #dri-devel
<pq>
a name for pixel buffer contents frozen at an instant in time... good question
<pq>
"frame"
kts has quit [Ping timeout: 480 seconds]
<Company>
that term is used for the concept of "rendering a frame"
simondnnsn has quit [Ping timeout: 480 seconds]
<pq>
yes, seems fitting to me
<Company>
what you really want is the ability to constify pixels and then later unconstify them, but using 2 different types
simondnnsn has joined #dri-devel
<Company>
wl_buffer and cairo_surface_t suffer from that, too - you never know if you're allowed to write to it currently
<Company>
from just looking at it
frieder has joined #dri-devel
<pq>
yeah, not by the type indeed. That's an interesting idea to implement in Wayland IPC context.
<Company>
Wayland has it a bit easier because there's just 2 potential consumers of a buffer
<pq>
something like attaching a wl_buffer will destroy the wl_buffer but give you back a new wl_locked_buffer object referring to the same underlying buffer. You just cannot do anything with a wl_locked_buffer until it delivers an event that destroys it and gives you a new wl_buffer.
<Company>
yeah, something like that
<Company>
except that doesn't quite work
<Company>
if you want to use the same wl_buffer for 2 surfaces
<pq>
Too bad the Wayland IPC story around server-side created objects is full of pitfalls.
<Company>
so you need to make the lock/unlock explicit I think
<pq>
yeah, I just wonder what happens with the unlock if you attach the same locked buffer to multiple surfaces...
<Company>
the unlock fails
<pq>
protocol messages cannot fail.
<pq>
oh but that's not a problem like the wl_buffer.release event is a problem
<Company>
well, the unlock would not give you a buffer
<pq>
actually, there is a race
<pq>
client cannot initiate unlock, it would need to be the server
<MrCooper>
Company: the contents of a GTK texture backed by a dma-buf can't really be "immutable", it would need to copy to a separate non-shared buffer for that
<Company>
but I don't think this works on a protocol level
<pq>
but while the server is sending unlock event, the client could be using the locked object even more, leading to protocol error
<Company>
MrCooper: "immutable" means everybody promises to not touch it
<Company>
MrCooper: same as the contents of a wl_buffer
tarceri has quit [Read error: No route to host]
tarceri has joined #dri-devel
<pq>
so we'd need something like server sending event "you should be able to unlock now", client sending unlock request, and then we also need a server reply if the unlock actually worked. Ugh.
<Company>
MrCooper: the important part is that the texture has to stay immutable until all references to it are released (at which point the destructor will call a callback provided upon creation)
kxkamil has quit []
<Company>
MrCooper: and it's up to the creator of the texture to ensure that happens
<pq>
while modern development is going in the direction of passing fences around that may trigger later, which is a totally different direction.
<pq>
so I think the locked/unlocked API must be invented purely client-side, it's not a good match for IPC
<Company>
pq: I agree on that very much
<pq>
yay :-)
<Company>
also because IPC cannot guarantee stuff stays untouched
<Company>
mutter can't stop the client from writing to a dmabuf, even if it's put in a locked_buffer
<Company>
so the benefit is client-only, as in its main use is to catch bugs in your code
flynnjiang has quit [Quit: flynnjiang]
<Company>
so something like Rust's borrow checker
Leopold_ has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
ZeZu has quit [Quit: off to see the wizard]
ZeZu has joined #dri-devel
<MrCooper>
Company: which epiphany process calls gsk_vulkan_image_new_for_dmabuf ?
<Company>
MrCooper: none
<Company>
I realized that Ephy uses GL textures not dmabuf textures, so it goes via glReadPixels()
simondnnsn has joined #dri-devel
heat has joined #dri-devel
<MrCooper>
then there seems to be a Mesa bug there
<Company>
so all in all, pretty much like you'd do wl_buffer, too
frankbinns2 has joined #dri-devel
<Company>
only that GdkTexture is what pq refered to as wl_locked_buffer
<pq>
this discussion makes me want to go write stuff in Rust :-)
<Company>
I don't think Rust makes this any more obvious
<Company>
but I don't write Rust, so I might be very wrong
simondnnsn has quit [Ping timeout: 480 seconds]
<Company>
but I don't see where it gets you the lock/unlock step unless you put it there yourself
<pq>
much of the Rust patterns applicable here would also be doable in C, like different types for locked and unlocked buffers.
<Company>
yeah
<pq>
"destroy" the old type object, don't leave it lingering, and offer no other way
simondnnsn has joined #dri-devel
frankbinns1 has quit [Ping timeout: 480 seconds]
<Company>
and the only way to get the old object back is via the last unlock - though you need a callback for that because you don't know who's unlocking it last
<pq>
is there a reason to allow multiple readers though?
<Company>
yes, absolutely
<Company>
i mean, there's simple things like icons
<Company>
that get used in multiple places
<pq>
okay, but will those ever get re-written too?
<Company>
no, probably not
<Company>
but it's the same kind of object: a bunch of pixels used as a source
Leopold_ has quit [Remote host closed the connection]
<Company>
we use GdkTexture for everything, from icon to 4k video
<pq>
another type: permanently locked, which allows making more permanently locked objects referring to the same storage.
<Company>
we don't do that, but you could
itoral_ has joined #dri-devel
<Company>
we have a different layer for using parts of storage - that's a rendering/clipping task
<pq>
then you also need strong hygiene to never store a pointer to the same object in two places - Rust's borrow checker enforeces that, but in C it's manual.
<Company>
that's the typical refcounting game you have everywhere in Gnome
<Company>
if you store the pointer, take a reference
<pq>
no ref counting
<pq>
you just don't hold it in more than one place.
<pq>
or maybe you assert that the ref count never exceds 1
<Company>
that can work, but might not
<Company>
I mean, you can always wrap it in a shared_ptr
<pq>
yeah, that's the weak point, keeping the hygiene
<pq>
no, that would be bad
<pq>
that's the thing one must not do, for the type system to work
<pq>
in C
<pq>
or did you mean for enforcing the ref count never exceeds 1?
<Company>
I meant for allowing more than 1 place to refer to it
<pq>
ok, that would be bad.
itoral has quit [Ping timeout: 480 seconds]
<pq>
if multiple places needed a locked buffer, each place would need to own its own locked buffer object, and those can refer to the same storage only if they are permanently locked buffers, because any other kind of buffer reference/object has no way to make a duplicate.
<pq>
That's the kind of pattern that playing with Rust has given me.
emersion has quit [Remote host closed the connection]
Nefsen402 has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
emersion has joined #dri-devel
Nefsen402 has joined #dri-devel
simondnnsn has quit [Read error: No route to host]
simondnnsn has joined #dri-devel
<Company>
you can make the locking its own object, I see no reason to not design it that way
FireBurn has joined #dri-devel
<pq>
hm?
<Company>
but when all the locks are unlocked again, you want the storage to be reusable
<pq>
that complicates the design, I'm assuming that's not needed
<Company>
if it's not needed then the thing is always locked anyway
<Company>
and there's not even a way to modify it
<Company>
so there's no need to lock it
<pq>
needs a callback of sorts, like you said, and that's not quite a type system anymore
<pq>
the point of locking is to be able to unlock; the point of locking permanently is to be able to allow multiple readers
Bulgarin has joined #dri-devel
Bulgarin has left #dri-devel [#dri-devel]
simondnnsn has quit [Ping timeout: 480 seconds]
mclasen has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
Nefsen402 has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
Nefsen402 has joined #dri-devel
emersion has joined #dri-devel
simondnnsn has joined #dri-devel
mvlad has joined #dri-devel
Nefsen402 has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
emersion has joined #dri-devel
Nefsen402 has joined #dri-devel
egbert is now known as Guest321
egbert has joined #dri-devel
Guest321 has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
mclasen has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
Leopold_ has joined #dri-devel
<dj-death>
sima: yeah it does
<dj-death>
sima: I was talking about other buffers in Anv
<dj-death>
I guess it's possible to do for all buffers in Iris
<sima>
ah yeah anv only needs to do this for winsys and not for anything else
<dj-death>
because we track all buffers
<dj-death>
referenced in a batch
jsa has quit []
<dj-death>
but the bindless nature of vulkan makes it a lot more tricky to do
jsa has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
FireBurn has quit []
Daanct12 has quit [Quit: WeeChat 4.1.2]
jsa has quit []
aravind has quit [Ping timeout: 480 seconds]
cheako has joined #dri-devel
jsa has joined #dri-devel
jsa has quit [Read error: Connection reset by peer]
vliaskov has quit [Remote host closed the connection]
jsa has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
apinheiro has quit [Quit: Leaving]
fab has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
jfalempe has quit [Remote host closed the connection]
bmodem has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
Adrinael has quit [Ping timeout: 480 seconds]
<demarchi>
MrCooper: IMO it shouldn't be a option to each user to decide if mailman will mangle the email for everybody. It doesn't help that that is the default value and few people understand the issue to go and change
<demarchi>
MrCooper: not mangling the Cc and just applying the same logic based on user selection would be acceptable though
<emersion>
yeah, mailman has too many knobs
Adrinael has joined #dri-devel
Adrinael is now known as Guest335
Guest335 is now known as Adrinael
itoral_ has quit []
simon-perretta-img has quit [Ping timeout: 480 seconds]
Adrinael has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Adrinael has joined #dri-devel
jfalempe has joined #dri-devel
yrlf2 has quit []
yrlf has joined #dri-devel
YuGiOhJCJ has quit [Read error: Connection reset by peer]
YuGiOhJCJ has joined #dri-devel
kts has joined #dri-devel
kts has quit []
sewn has quit [Remote host closed the connection]
<daniels>
the kernel.org archiver doesn't have nodupes enabled, so it shouldn't be seeing cc mangling
<daniels>
err, I think 'not metoo' might be the relevant option, but it's still not enabled
sewn has joined #dri-devel
Erisian has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
bmodem has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
kts has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
<MrCooper>
demarchi: the option affects only the subscribers which enable it, not anybody else
macslayer has joined #dri-devel
Haaninjo has joined #dri-devel
<demarchi>
MrCooper: that's not true... the header is changed so if I Cc both dri-devel and intel-linux, someone *else* subscribed to both will get 2 different emails with a different set of Cc.
fab has joined #dri-devel
<MrCooper>
only if that someone else enabled the option
<demarchi>
no... that someone could be someone external to the mailing list (like lore.kernel.org is)
<MrCooper>
not following, how would they get 2 e-mails with different Cc then?
<MrCooper>
nvm, I remembered now, it does actually drop the subscribers from Cc even in the e-mails sent to other subscribers :(
<MrCooper>
gotta be one of the worst mis-features ever
simon-perretta-img has joined #dri-devel
<MrCooper>
daniels: it is "Avoid duplicate copies of messages?", not "Receive your own posts to the list?"
<daniels>
the archiver doesn't have either enabled tho
<daniels>
well, it doesn't have 'nodupes' nor 'not metoo' enabled
<daniels>
it sounds like 'Receive your own posts to the list' is !(not metoo)
<MrCooper>
indeed it does
<MrCooper>
anyway, unfortunately it doesn't matter that the archiver doesn't enable it, mailman drops any subscriber address which enabled the option from Cc in any e-mail it sends out to any subscriber
<MrCooper>
so if that option could be globally disabled, that might eliminate one reason for the trouble with gmail
<pq>
Then there are people who get really upset if someone Cc's them while they also get the mail via a list. Then they scream at the sender.
<daniels>
email: not even once
<pq>
which setting exactly are you talking about?
<MrCooper>
pq: that would be addressed by just not sending list posts to subscribers in Cc, which is what the option description talks about; the problem is that it also mangles the posts sent to other subscribers (which isn't clearly documented)
<dj-death>
gfxstrand: since we're talking about layering on mesa-dev ;)
<gfxstrand>
hehe
<gfxstrand>
dj-death: This is an example of the layering issues we're running into. :sob:
<dj-death>
gfxstrand: yeah, I have an email written about this, but I don't think it's contributing anything to the discussion so... probably will not send it ;)
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<gfxstrand>
dj-death: I mean, feel free. I value your thoughts as much as anyone else who's chimed in.
Adrinael has quit [Ping timeout: 480 seconds]
i-garrison has quit []
Adrinael has joined #dri-devel
Adrinael is now known as Guest342
Celmor[m] has joined #dri-devel
Wallbraker has joined #dri-devel
AlaaEmad[m] has joined #dri-devel
ajhalaney[m] has joined #dri-devel
arisu has joined #dri-devel
anfanite396[m] has joined #dri-devel
Andy[m] has joined #dri-devel
aradhya7[m] has joined #dri-devel
Pierce[m] has joined #dri-devel
aura[m] has joined #dri-devel
BilalElmoussaoui[m] has joined #dri-devel
bubblethink[m] has joined #dri-devel
bylaws1 has joined #dri-devel
chema has joined #dri-devel
cleverca22[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
Coelacanthus[m]1 has joined #dri-devel
Eighth_Doctor has joined #dri-devel
QiuWenbo[m] has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dafna33[m] has joined #dri-devel
daissi has joined #dri-devel
daniliberman[m] has joined #dri-devel
dantob has joined #dri-devel
devarsht[m] has joined #dri-devel
Anson[m] has joined #dri-devel
dhirschfeld2[m] has joined #dri-devel
Guest55 has joined #dri-devel
doras has joined #dri-devel
doraskayo has joined #dri-devel
danylo1 has joined #dri-devel
EricCurtin[m] has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
Ella[m] has joined #dri-devel
eballetbo has joined #dri-devel
enunes[m] has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
exp80[m] has joined #dri-devel
fkassabri[m] has joined #dri-devel
FL4SHK[m] has joined #dri-devel
FloGrauper[m] has joined #dri-devel
gallo[m] has joined #dri-devel
gdevi has joined #dri-devel
gegoxaren[m] has joined #dri-devel
general_j[m] has joined #dri-devel
gnustomp[m] has joined #dri-devel
Guest185 has joined #dri-devel
Armote[m] has joined #dri-devel
MotiH[m] has joined #dri-devel
halfline[m] has joined #dri-devel
Harvey[m] has joined #dri-devel
Hazematman has joined #dri-devel
hch12907 has joined #dri-devel
heftig has joined #dri-devel
Guest51 has joined #dri-devel
Duke`` has joined #dri-devel
Hi-Angel has joined #dri-devel
zzoon[m] has joined #dri-devel
ids1024[m] has joined #dri-devel
isinyaaa[m] has joined #dri-devel
jasuarez has joined #dri-devel
JosExpsito[m] has joined #dri-devel
jtatz[m] has joined #dri-devel
K0bin[m] has joined #dri-devel
Adrinael_ has joined #dri-devel
kallisti5[m] has joined #dri-devel
madhavpcm has joined #dri-devel
kelbaz[m] has joined #dri-devel
koki23[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
KunalAgarwal[m][m] has joined #dri-devel
kusma has joined #dri-devel
Labnan[m] has joined #dri-devel
LaughingMan[m] has joined #dri-devel
LinuxHackerman has joined #dri-devel
m00nlit[m] has joined #dri-devel
Guest342 has quit [Ping timeout: 480 seconds]
mairacanal[m] has joined #dri-devel
MarkCollins[m] has joined #dri-devel
marmarek[m] has joined #dri-devel
martix778777[m] has joined #dri-devel
masush5[m] has joined #dri-devel
matrix638[m] has joined #dri-devel
MayeulC 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
msizanoen[m] 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
nick1343[m] has joined #dri-devel
nicofee[m] has joined #dri-devel
nielsdg has joined #dri-devel
nyorain[m] has joined #dri-devel
Adrinael_ has quit [Read error: Connection reset by peer]
ofirbitt[m] has joined #dri-devel
ohadsharabi[m] has joined #dri-devel
onox[m] has joined #dri-devel
orowith2os[m] has joined #dri-devel
pac85[m] has joined #dri-devel
pankart[m] has joined #dri-devel
pedrohlc[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
Guest291 has joined #dri-devel
pushqrdx[m] has joined #dri-devel
q4a has joined #dri-devel
Quinten[m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
ram15[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
samueldr has joined #dri-devel
dabrain34[m] has joined #dri-devel
siddh has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
SintayewGashaw[m] has joined #dri-devel
sergi has joined #dri-devel
Sumera[m] has joined #dri-devel
swick[m] has joined #dri-devel
sythemeta847[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tak2hu[m] has joined #dri-devel
talcohen[m] has joined #dri-devel
Targetball[m] has joined #dri-devel
tayloralgo1[m] has joined #dri-devel
terribletea[m] has joined #dri-devel
Adrinael_ has joined #dri-devel
tintou has joined #dri-devel
underpantsgnome[m] has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
tomeu has joined #dri-devel
Tooniis[m] has joined #dri-devel
kos_tom has joined #dri-devel
treeq[m] has joined #dri-devel
ttayar[m] has joined #dri-devel
tuxayo has joined #dri-devel
undvasistas[m] has joined #dri-devel
Soroush has joined #dri-devel
Vanfanel has joined #dri-devel
vdavid003[m] has joined #dri-devel
viciouss[m] has joined #dri-devel
vidal72[m] has joined #dri-devel
MatrixTravelerbot[m] has joined #dri-devel
Weiss-Fder[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
YHNdnzj[moz] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
zzxyb[m] has joined #dri-devel
<dj-death>
gfxstrand: for what it's worth I thought that shitting toward internal interfaces would be better
<dj-death>
gfxstrand: in that case we could have internal types of barriers
<gfxstrand>
Yup
<gfxstrand>
That's kind-of my plan
<dj-death>
gfxstrand: and also have the metadata on the attachments to better deal with those types of cases
<gfxstrand>
Just eat the duplication and add some python if it helps
<gfxstrand>
Then we can modify stuff at will
<dj-death>
did I write shitting
<dj-death>
I meant shifting
<dj-death>
obvisouly :)
<gfxstrand>
I mean, you can shit towards internal interfaces if you want. (-:
<dj-death>
heh
Adrinael_ has quit [Read error: Connection reset by peer]
Adrinael_ has joined #dri-devel
Adrinael_ has quit [Read error: Connection reset by peer]
Adrinael_ has joined #dri-devel
djbw has joined #dri-devel
i-garrison has joined #dri-devel
jsa has joined #dri-devel
anujp has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Adrinael_ is now known as Adrinael
<jenatali>
The Vulkan CTS doesn't have any shaders that do aliasing of SSBOs/UBOs :(
<gfxstrand>
Oh?
<jenatali>
> There are no limits on the number of shader variables that can have overlapping set and binding values in a shader
<jenatali>
Dozen definitely doesn't handle that
<gfxstrand>
woof
<jenatali>
Woof indeed
Adrinael_ has joined #dri-devel
Adrinael has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
Adrinael_ has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
ADS_Sr has quit [Remote host closed the connection]
ADS_Sr has joined #dri-devel
Adrinael has joined #dri-devel
<dj-death>
can you access both at the same time though?
<dj-death>
probably not?
Adrinael is now known as Guest353
<jenatali>
> If multiple shader variables are declared with the same set and binding values, and with the same underlying descriptor type, they can all be statically used within the same shader.