ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
reductum has quit [Quit: WeeChat 2.8]
reductum has joined #dri-devel
rpigott has quit [Remote host closed the connection]
kem has joined #dri-devel
V has quit [Remote host closed the connection]
V has joined #dri-devel
rpigott has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
camus has quit []
mbrost has joined #dri-devel
camus has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
camus has quit []
mbrost has quit [Ping timeout: 480 seconds]
JTL has quit [Quit: WeeChat 2.9]
JTL has joined #dri-devel
Duke`` has joined #dri-devel
cef has quit [Quit: Zoom!]
cef has joined #dri-devel
Daaanct12 has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
Daaanct12 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
slattann has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
slattann has quit []
xexaxo has joined #dri-devel
slattann has joined #dri-devel
Lucretia has joined #dri-devel
xexaxo has quit [Ping timeout: 480 seconds]
xexaxo has joined #dri-devel
slattann has quit []
slattann has joined #dri-devel
<pq>
haasn, OpenGL tends to define all 8 bits per channel formats differently from all the non-8 bits perf channels formats.
<pq>
haasn, mind that with OpenGL you need *two* enum at least, to define one format: the one with channels, e.g. GL_RGB, and one with the packing, e.g. GL_UNSIGNED_BYTE.
<pq>
haasn, so the difference is "array of bytes" vs. "bits in a word". OpenGL uses both arbitrarily which confuses everything, DRM formats use only the latter.
<pq>
haasn, on little-endian, "array of bytes" is the opposite order from "bits in a word" when you have 8 bits per channel. Only with 8 bits per channel formats you can arbitrarily pick which convention to use. And of course OpenGL went with the most confusing choice.
go4godvin is now known as Guest4408
jkrzyszt has joined #dri-devel
gouchi has joined #dri-devel
<pq>
haasn, if you only ever use 8 bits per channel formats, then it's really tempting to use "array of bytes" convention, but it simply doesn't work for anything non-8-bit. "bits in a word" OTOH works for both 8-bit and non-8-bit.
slattann has quit []
slattann has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
danvet has joined #dri-devel
camus has joined #dri-devel
Lucretia has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
i-garrison has quit []
Daaanct12 has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
slattann has quit []
jkrzyszt has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
<daniels>
alyssa: regmap may or may not be what you're after
<haasn>
pq: ironically the abstraction I'm dealing with on the other end (libplacebo pl_fmt) uses the _exact opposite_ convention
<haasn>
i.e. it's literally the same as DRM but reversed
<haasn>
this makes it consistent with memory order for 8-bit stuff
co1umbarius has joined #dri-devel
<emersion>
well good luck with non-8bpc formats :P
<co1umbarius>
about multiplane dmabufs: what is the relationship between the modifiers and the planes? On one hand, gbm and vulcan have both apis to return a planecount for a given format/modifier pair, on the other hand eglCreateImage can take a modifier for each plane and i heard that a different modifier per plane would/could be a valid case, which gbm and others lack
gouchi has quit [Remote host closed the connection]
<emersion>
co1umbarius: in the past, there was one modifier per plane. but this decision was rolled back, and now there is one modifier for all planes
<emersion>
there are still old APIs which assume 1 modifier per plane, but drivers will (or should) reject the import if the modifiers are not equal
<emersion>
e.g. KMS will do that
<emersion>
not sure about EGL
<emersion>
newer APIs accept a single modifier for all planes
<quantum5>
however, OES_EGL_image_external_essl3 says "An INVALID_OPERATION error is generated if <texture> is neither the name of an immutable texture object, nor the name of an external texture object."
<quantum5>
my understanding of this is that external texture objects bound to GL_TEXTURE_2D with glEGLImageTargetTexture2DOES should also be allowed
<quantum5>
while the wording could be understood as only allowing GL_TEXTURE_EXTERNAL_OES, I think "external" is an adjective that refers to all textures bound with glEGLImageTargetTexture2DOS, just like how it uses "immutable texture object" despite there being no texture type called "GL_TEXTURE_IMMUTABLE"
gouchi has quit [Remote host closed the connection]
<quantum5>
in any case, it is currently impossible to make such textures immutable and thus impossible to pass them to compute shaders
<imirkin_>
quantum5: likely that bit got missed
<imirkin_>
hm, ed43dd62acc045e71d73dc28b74b6a9a9d52286f claims to allow this
gouchi has joined #dri-devel
<imirkin_>
quantum5: oh i see. you're saying an "external" image like one from EGL. (reading is not my forte apparently)
<quantum5>
yes, ones created with glEGLImageTargetTexture2DOES(GL_TEXTURE_2D)
<imirkin_>
so the reason for saying immutable there is generally to avoid the possibility of an image being re-laid-out
<imirkin_>
(which can happen with glTexImage)
<imirkin_>
can you call glTexImage on such an EGL image target thing?
<imirkin_>
and e.g. change the number of levels
<quantum5>
not sure, I think glEGLImageTargetTexture2DOES overrides the underlying storage
<imirkin_>
yeah, i would think so too
jewins has joined #dri-devel
<quantum5>
I also tried using glTexStorage2D and it broke the texture
<imirkin_>
do you know offhand what adds glEGLImageTargetTexture2DOES ?
<quantum5>
you mean the commit? no sorry
<imirkin_>
looks like GL_OES_EGL_image
<imirkin_>
and that was released well before ES 3.1, so doesn't have interactions
<quantum5>
so it doesn't seem to be a technical limitation
<imirkin_>
yeah, in dekstop GL, you can use it with "mutable" textures
<imirkin_>
quantum5: yeah, i tend to agree with your interpretation
<imirkin_>
that "external texture object" != "GL_TEXTURE_EXTENRAL"
<imirkin_>
quantum5: do you have any idea what other implementations do?
<imirkin_>
quantum5: separately, using glTexStorage2D should never break a texture ... probably a missing error somewhere?
<quantum5>
as for other implementations, unfortunately no
Daanct12 has joined #dri-devel
<quantum5>
as for glTexStorage2D, glEGLImageTargetTexture2DOES did not apply when I tried it
dviola has joined #dri-devel
<quantum5>
I also did not get any debug messages for it
xexaxo has quit [Ping timeout: 480 seconds]
<quantum5>
so the texture content becomes garbage after glTexStorage2D followed by glEGLImageTargetTexture2DOES
xexaxo has joined #dri-devel
<imirkin_>
interesting
Daaanct12 has quit [Ping timeout: 480 seconds]
<imirkin_>
so EGLImageTargetTexture2DOES says that the impl is supposed to allocate on the side any storage for extra mip levels/etc
<imirkin_>
"if an application later respecifies any image array in the texture object, implementations should allocate ... "
<quantum5>
yea, that would make sense since it says when the function is called, "Any existing image arrays associated with any mipmap levels in the texture object are freed (as if TexImage was called for each, with an image of zero size)."
<quantum5>
I think this puts it in direct conflict with glTexStorage2D and its notion of immutability
<imirkin_>
yeah
<imirkin_>
i think that EGLImageTargetTexture2DOES should error if called on an immutable texture object
<quantum5>
"The commands eglBindTexImage, wglBindTexImageARB, glXBindTexImageEXT or EGLImageTargetTexture2DOES are not permitted on an immutable-format texture."
<quantum5>
should be INVALID_OPERATION
<imirkin_>
makes sense
<imirkin_>
are you able/willing to submit patches?
<imirkin_>
seems like you have more than enough know-how to fix up the code
<quantum5>
I have never contributed to mesa before
<quantum5>
is it difficult to run a custom build of mesa side by side with the system version?
<imirkin_>
no
<imirkin_>
i think there are some beginner instructions somewhere
<quantum5>
as for the issue with glTexStorage2D and glEGLImageTargetTexture2DOES, that was correctly reported as an error in the latest mesa (the version in my distro is just too old)
danvet has quit [Ping timeout: 480 seconds]
<karolherbst>
ahh, seems to be fine on main.. let's see
<imirkin_>
quantum5: cool. i'm probably not the best person to review, but someone should look at it in the next day or two
<imirkin_>
quantum5: if that doesn't happen, ping in here
<quantum5>
noted, thanks
pochu has joined #dri-devel
pcercuei has quit [Quit: dodo]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
pochu has quit [Remote host closed the connection]