<graphitemaster>
Although Mesa is a bit of an outlier because it does a good job comparatively speaking.
anholt has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
<HdkR>
Reads like an ecosystem rant rather than anything directly related to driver problems.
<tleydxdy>
if consoles work fine it just sound like the ol "PC is an after thought" problem
pixelcluster has quit [Ping timeout: 480 seconds]
pixelcluster has joined #dri-devel
sagar_ has quit [Ping timeout: 480 seconds]
<robclark>
it would be sad if vk drivers have to repeat the heroics of working around game/engine issues that gl drivers did.. the right way to do vk is for engines to be designed with vk in mind (rather than translating legacy things incl gl to vk).. rather than making vk drivers solve engine problems
<graphitemaster>
you're expecting too much of ports
<airlied>
the irony being that one of the proposed adv of vulkan/dx12 was they were more console like
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
<Frogging101>
I have a texture from a proprietary game that's being generated badly in another frame but I don't know when. How should I capture it?
<Frogging101>
I was thinking of hacking renderdoc to start capturing every frame when I press F12 or something
<HdkR>
gfxreconstruct would likely be a good choice here since it captures multiple frames
<Frogging101>
I'll look at that
saurabhg has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
bmodem has joined #dri-devel
bmodem has quit []
<Frogging101>
Is there a tool for going through the contents of these capture files?
<HdkR>
gfxrecon-replay, I don't think there is a gui for it
<Frogging101>
hmm
<Frogging101>
I'm trying to find out when the textures in that buffer get screwed up
<HdkR>
I definitely won't say it is an ideal debugger
<Frogging101>
Maybe what I can do is go through the API calls from the trace, find interesting frames and use renderdoc to dump them
<Frogging101>
I couldn't do this when running the application live because I have no idea what frames are important and they're different every time. But the gfxreconstruct trace will always be the same
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
eukara has quit []
digetx is now known as Guest6654
digetx has joined #dri-devel
Guest6654 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
kts has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
sul has joined #dri-devel
leo60228 has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
kem has joined #dri-devel
bmodem has quit []
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
itoral has joined #dri-devel
fab has joined #dri-devel
fab is now known as Guest6656
Guest6656 has quit []
leo60228 has joined #dri-devel
tzimmermann has joined #dri-devel
lemonzest has joined #dri-devel
nchery has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
nchery is now known as Guest6658
nchery has joined #dri-devel
aravind has joined #dri-devel
Guest6658 has quit [Ping timeout: 480 seconds]
Guest6333 is now known as jani
Company has quit [Quit: Leaving]
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
eukara has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
ayaka_ has joined #dri-devel
<ayaka_>
Does the dri-devel maillist down?
<ayaka_>
All the mail I sent to it would be rejected with this error "fp.write(msgsave) IOError: [Errno 28] No space left on device"
<emersion>
yes, i'm investigating now
rgallaispou has joined #dri-devel
frieder has joined #dri-devel
lygstate has quit [Remote host closed the connection]
sdutt has quit [Ping timeout: 480 seconds]
saurabhg has quit [Read error: Connection reset by peer]
jkrzyszt has joined #dri-devel
<ayaka_>
thank you
JohnnyonFlame has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
vliaskov has joined #dri-devel
mvlad has joined #dri-devel
vliaskov has quit []
kts has joined #dri-devel
Haaninjo has joined #dri-devel
JohnnyonFlame has joined #dri-devel
rasterman has joined #dri-devel
rg3igalia_ is now known as rg3igalia
pcercuei has joined #dri-devel
fahien has joined #dri-devel
ayaka_ has quit [Remote host closed the connection]
ayaka_ has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
fahien has quit [Quit: fahien]
<ayaka_>
btw, I have a pixel formats which would be 5 planes over the max planes in drm
<ayaka_>
although the last plane would be the same buffer of the previous buffer, it is something likes meta data in AFBC
fahien has joined #dri-devel
<ayaka_>
but I still need to pass the offset and size of the fifth planes, any workaround I could do here ?
<pq>
ayaka_, the only advice I can give is do not even attempt any kind of workaround. I cannot imagine that ending well.
<pq>
if you really need more than 4 planes over UAPI, that's going to be a big project to roll out to everywhere in the kernel and userspace alike.
<pq>
Wayland protocol does not seem to need revising, but e.g. EGL needs a new EGL extension written and advertised.
<ayaka_>
pq, luckily EGL won't be a problem, the GPU doesn't support this tiled format nor its compression version
<ayaka_>
What I need could be just an extra variable for luma metadata's size
<ayaka_>
then the size for chroma could be the total size minus that variable
tursulin has joined #dri-devel
<pq>
why do you need to deliver the size of chroma data explicitly? can it not be inferred from pixel format, modifier, image dimensions and stride?
<ayaka_>
I don't think expand the kernel uAPI could be a good choice, it is a vendor special pixel formats only be supported by its video codecs and display IP
<pq>
I don't think any vendor-specific custom abuse of existing UAPI is going to fly either.
phomes has joined #dri-devel
<ayaka_>
this pixel format is a little special, its metadata's size depends on the compression radio
<ayaka_>
which luma and chroma could use a different value
<pq>
Did you already explain what kind of images you need pass around and between which components in an email to dri-devel@? I don't think this is a question that can be answered in IRC.
<ayaka_>
that is why we need to tell the decompression device the size of echo planes' metadata
<ayaka_>
pq, sorry, I didn't get the full approval to reveal it, we even don't have a vendor modifier registered
<pq>
ayaka_, if you can't explain what you want to do, then I don't anyone answer how to implement what you want to do.
<pq>
*don't think
<ayaka_>
I did explain why, but I can't reveal its real memory layout now
<pq>
*I don't think anyone can answer how to implement what you want to do to.
<pq>
yeah, so fire off an email with all the info you can expose
<pq>
this is a too big question for IRC
<ayaka_>
maybe tomorrow, the reason I chose the IRC is that not so many people are looking at it
<ayaka_>
and people can't be sure which vendor I am referring
<dolphin>
ayaka_: this channel is logged by a bot and the history can be found online
<dolphin>
see dri-logg1r
<pq>
right, IRC is not any more private than the mailing list, but IRC discussions do get lost very very quickly.
kts has quit [Ping timeout: 480 seconds]
* ccr
looks around for Phoronix spies.
kts has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
<jenatali>
karolherbst: I don't really have any opinions, any of them sound fine to me
jewins has joined #dri-devel
Jeremy_Rand_Talos_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
sdutt has joined #dri-devel
kennylevinsen_ has left #dri-devel [#dri-devel]
kennylevinsen has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
heat has quit [Read error: No route to host]
heat_ has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
kts has joined #dri-devel
<jani>
tzimmermann: so there's now a conflict in rebuilding drm-tip?
<tzimmermann>
jani, there's no merge conflict. but i think the i915-ttm branch is being merged after drm-misc-next and breaks amdgpu. at least, that's what the diff between the two branches suggests. i'm currently trying to fix this as described in drm-tip.rst
<tzimmermann>
my computer is a bit slow, so the rebuild takes time
saurabhg has joined #dri-devel
frieder has quit [Remote host closed the connection]
<karolherbst>
jenatali, jekstrand: I think we should go with "sampler literal" because that's the closest we can get to the official name... but then the OP is called OpConstantSampler :( ahhhhhhhhhh
<karolherbst>
why is that so stupid
<jani>
tzimmermann: there was a mention on #intel-gfx that drm-tip rebuild now requires a recent dim version to apply fixups that add new files
<Frogging101>
What does a barrier do when its srcAccessMask is VK_ACCESS_NONE?
<Frogging101>
Nothing?
zackr has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<bl4ckb0ne>
is it possible to use an EGLimage created from EGL_LINUX_DMABUF_EXT as a cubemap texture?
<bl4ckb0ne>
glEGLImageTargetTexture2D is not very happy with the GL_TEXTURE_CUBE_MAP target
<jekstrand>
karolherbst: I like inline, myself. Because it's inline in the shader code.
<jekstrand>
Constant is really overloaded.
<jekstrand>
Maybe not too bad but not great.
<karolherbst>
yeah.....
<karolherbst>
I also prefer inline, just wondering if coming up with a more official name is worth it
alarumbe has quit [Read error: Connection reset by peer]
sul has quit [Read error: Connection reset by peer]
pixelcluster has quit [Ping timeout: 480 seconds]
cengiz_io has quit []
<karolherbst>
will go with inline and if somebody complains in the future we can address it then :D
tursulin has quit [Ping timeout: 480 seconds]
cengiz_io has joined #dri-devel
jessica_246 is now known as jessica_24
ybogdano has joined #dri-devel
pixelcluster has joined #dri-devel
sul has joined #dri-devel
<jekstrand>
karolherbst: Works for me. I just want us to be consistent and have it documented.
<jekstrand>
karolherbst: Maybe put a big comment on the `nir_variable` field tying all the various names together?
<karolherbst>
yeah.. something like that
MajorBiscuit has quit [Ping timeout: 480 seconds]
sul has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
alarumbe has joined #dri-devel
pixelcluster has quit [Ping timeout: 480 seconds]
jstultz_ has quit []
jstultz has joined #dri-devel
pixelcluster has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
ybogdano has quit [Ping timeout: 480 seconds]
slattann has quit []
sul has joined #dri-devel
cengiz_io_ has joined #dri-devel
<ajax>
are we branched for 22.2 yet? should we hold back merging things?
saurabhg has quit [Read error: Connection reset by peer]
<karolherbst>
ehhh.. why do I always mess up my rebases :(
<karolherbst>
ahh I didn't I am just blind
<zmike>
ajax: I don't think branched yet
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: btw.. you meant that sampler struct inside nir_variable_data?
ybogdano has joined #dri-devel
<jekstrand>
karolherbst: ?
<karolherbst>
"<jekstrand> karolherbst: Maybe put a big comment on the `nir_variable` field tying all the various names together?"
<karolherbst>
just wondering what field you meant here
<jekstrand>
karolherbst: Yes, the one inside nir_variable_data.
fahien has quit [Quit: fahien]
Lucretia has quit []
<tzimmermann>
jani, imre, tursulin, i have recreated drm-tip with a fix for the build problem, again
<tzimmermann>
<insert Groundhog Day meme here>
<tzimmermann>
there's now a fixup for merging the i915-ttm branch into drm-tip. this tree appeared to be the source of the problem
ngcortes has joined #dri-devel
Lucretia has joined #dri-devel
iive has joined #dri-devel
<jani>
tzimmermann: thanks, appreciated!
mbrost has joined #dri-devel
<tzimmermann>
fingers crossed that it doesn't break again. if it does, the problem is probably in another tree than i915-ttm
<Lyude>
emersion: yes I would be, thanks for letting me know! I'll try to take a look at it at some point today
<emersion>
nice :)
<emersion>
i'm still not sure how all of that connector registration works
<emersion>
especially when it's unregistered but still in use
fab has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
sravn has quit []
gouchi has joined #dri-devel
<karolherbst>
jekstrand: mhh.. your "assert(var->data.mode == nir_var_uniform);" assert is wrong inside var_is_inline_sampler :/ but don't really know a better place to put that in
<karolherbst>
could split up the return statement though
<karolherbst>
nir_dedup_inline_samplers -> var_is_inline_sampler hits any variable
<jekstrand>
karolherbst: Yeah, I thought about doing `if (var->data.mode != nir_var_uniform) return false;`
<karolherbst>
could also just move the assert to where it matters
<karolherbst>
although I think adding that if is fine
<jekstrand>
Yeah, none of this is all that hot
<jekstrand>
HdkR: Where are these mmap discussions happening around FEX? I realized yesterday that I actually really want mmap_range to be a thing so maybe I should chime in.
<karolherbst>
ehhh.. regressions :( noooo
<karolherbst>
ohh.. not using llvm-15 atm
<jekstrand>
boo llvm versions
<karolherbst>
will works itself out with fedora 37 anyway :D
<karolherbst>
ehh.. I am still on f35
<karolherbst>
guess I have something fun todo at the end of this week
<jekstrand>
I'm on 36, it looks like.
<karolherbst>
yay...
jewins has quit [Ping timeout: 480 seconds]
<karolherbst>
but there are soo many pieces which need updates: llvm, spirv-tools...
<karolherbst>
not sure if we also need a new translator?
<karolherbst>
oh well...
Peuc has quit [Quit: Peuc]
Peuc has joined #dri-devel
jhli has joined #dri-devel
Daaanct12 is now known as Danct12
fab has quit [Quit: fab]
heat_ has quit [Read error: Connection reset by peer]
<alyssa>
(reduces this chunky shader another 40 instructions)
<idr>
What the what?
<alyssa>
which part
<idr>
That is a very strange way to do a conditional negate.
<idr>
Just when you think you've seen it all...
<alyssa>
this is a very strange shader \shrug/
* alyssa
vaguely curious what awful GLSL caused this
pixelclu- has joined #dri-devel
<alyssa>
(this is from deqp)
ezequielg_ has quit []
ezequielg has joined #dri-devel
pixelcluster has quit [Ping timeout: 480 seconds]
<HdkR>
jekstrand: Discussions were mostly just me poking random kernel devs on IRC. I'm not doing any upstream discussion because I can't handle mailing list workflows
<idr>
alyssa: Out of curiosity... where does b come from in that conditional negate? (c < 0) by chance?
<alyssa>
idr: yes
<alyssa>
idr: a < 0, in fact
<idr>
Lol
<alyssa>
this is a normal way to write abs, don't worry
<jekstrand>
Which gets it for you without any branching but woof
<alyssa>
that's what backend isel is for
<jekstrand>
Yup
<alyssa>
i'll keep my nir_op_iabs thanks
<jekstrand>
For that matter, all hw has a bcsel which doesn't do any actual branching. There's literally no point.
<jekstrand>
Maybe for an exceptionally dumb compiler that's trying to add branchs
<iive>
how about max(v,-v), in case there is direct min/max int op?
<jekstrand>
iive: You can emit that in your back-end when you see `nir_op_iabs`
<alyssa>
jekstrand: what about a RISC-V gpu?
ybogdano has joined #dri-devel
<jekstrand>
alyssa: I don't care about a RISC-V GPU
<alyssa>
I guess it should just take SPIR-V in instead, and SPIR-V has a fast bcsel. Nvm.
<jekstrand>
alyssa: Yup, that ^^
<jekstrand>
:-P
sul has quit [Ping timeout: 480 seconds]
<jekstrand>
alyssa: Anyway, that patch is RB me.
<alyssa>
thanks. it's not tested ;)
mbrost has quit [Ping timeout: 480 seconds]
<Sachiel>
testing is done by the masses after you merge it
<jekstrand>
alyssa: I'm going to build it and kick to Jenkins now
<jekstrand>
Maybe I'll even throw CL idiv tests at it
<alyssa>
speaking of, does anybody care if I steal bool_to_bitsize from common the bifrost backend?
<idr>
alyssa: That patch looks correct by me. I'm going to be out next week, so I'll give my R-b now.
<alyssa>
etnaviv is the only other user I see, but etnaviv doesn't do fp16 afaik, so I think it meant to just use bool_to_int32?
sul has joined #dri-devel
<jekstrand>
alyssa: I'll also do a shader-db run. TGL doesn't have integer divide, IIRC.
<alyssa>
:-D
<alyssa>
for context -- lower_bool_to_bitsize is almost never what you actually want
<jekstrand>
No, it's DG2 that's missing it.
<alyssa>
bifrost is just extra special
<alyssa>
Oh. Integer multiples are SFU. Right. Fine.
<alyssa>
wq
<jekstrand>
And... gotta figure out how to run shader-db again...
<jekstrand>
idr: Any idea why intel_stub_gpu doesn't work on DG2?
<idr>
jekstrand: No clue.
<idr>
"Reasons"
<jekstrand>
Probably not returning any memory info
* jekstrand
doesn't feel like fixing that today
<idr>
I keep meaning to dig into it... then decide to do something else.
<jekstrand>
jljusten: ^^
<jekstrand>
I've hacked up brw_nir.c to run lower_idiv on TGL. Good enough. :)
<idr>
I think I had some patches that fixed some problems, but they weren't enough.
<idr>
And at that point DG2 wasn't fully public, so they're probably rotting somewhere...
<alyssa>
...and I just realized I've been using the wrong email address in git all day
<alyssa>
oops
<jljusten>
jekstrand: I was having some trouble with INTEL_DEVID_OVERRIDE on dg2 recently. (At least on vk.) I think mmap was failing, which sort of makes sense.
<alyssa>
jekstrand: force pushed to your MR to fix my email
<jekstrand>
jljusten: Likely the problems are similar but intel_stub_gpu is an entirely different path
<jekstrand>
jljusten: We should probably torch INTEL_DEVID_OVERRIDE, TBH.
<jljusten>
jekstrand: We sort of go down the no_hw paths, and then avoid reading region info and then try to use the old buffer paths.
ds` has joined #dri-devel
HdkR has joined #dri-devel
HdkR has quit [reticulum.oftc.net coulomb.oftc.net]
<jekstrand>
alyssa: Well, good and bad news: It affects 10 programs in shader-db.
HdkR has joined #dri-devel
HdkR has quit [reticulum.oftc.net coulomb.oftc.net]
<alyssa>
...Do I have a bigger shader-db than you?
<jekstrand>
You have a different shader-db
<alyssa>
fair
<jekstrand>
Also Intel does really dumb things with the generated code. IDK why yet
<alyssa>
right, yes
<alyssa>
100% of the affected shaders are closed android
<alyssa>
which means 100% of your affected shaders are closed linux, I guess?
<jekstrand>
yeah
<jekstrand>
And now I'm trying to figure out if any of this is correct for INT_MIN
<jekstrand>
Because iabs(INT_MIN) = INT_MIN
<alyssa>
bahh
<jekstrand>
But that's fine, I think.
<jekstrand>
INT_MIN = 1 << 31, right?
<alyssa>
umm
<alyssa>
signs point to yes
<jekstrand>
Yeah
<jekstrand>
So it's fine
HdkR has joined #dri-devel
<jekstrand>
It's just annoying because we really do need a u2f and we can't get by with an i2f
<jekstrand>
Intel back-end CSE sucks
javierm has joined #dri-devel
<jekstrand>
Or maybe we just need to run it later?
<alyssa>
Hm?
iive has quit [Quit: They came for me...]
<jekstrand>
I'm getting redundant iabs in the back-end
<jekstrand>
Which is a large part of why it's not actually helping. :-0/
<jekstrand>
:-/
sul has quit [Ping timeout: 480 seconds]
<alyssa>
Oh.
<alyssa>
meanwhile idiv_const is hurting shader-db.. wondering why
<alyssa>
ah, this shader is using the celebrity divisor of 7
sul has joined #dri-devel
<alyssa>
okay excuse me
<alyssa>
first the shader multiplies by 7
<alyssa>
then it divides the product by 7
* alyssa
smacks head
tales-aparecida7 is now known as tales-aparecida
<jekstrand>
woo
<alyssa>
if only i had nsw set on the multiply we'd be in business
<alyssa>
unfortunately this is GL land
<alyssa>
and according to the GL spec..sigh
* jekstrand
is very confused as to why the back-end can't CSE this
rasterman has quit [Quit: Gettin' stinky!]
<jekstrand>
Because the back-end aparently can't CSE MOVs....
<jekstrand>
Wow
<jekstrand>
How'd we miss that one?!?
jewins has joined #dri-devel
<jekstrand>
Hrm... right... CSE inserts MOVs and we don't want it to fight with itself.