<airlied>
btw you don't need all of u_* in virglrender, things like u_printf are no use there at all
naveenk2 has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
naveenk2 has quit []
shankaru has joined #dri-devel
rbrune has joined #dri-devel
naveenk2 has joined #dri-devel
sneil has quit [Remote host closed the connection]
sneil has joined #dri-devel
heat_ has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
danvet has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
jewins1 has joined #dri-devel
mszyprow has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
zackr has quit [Ping timeout: 480 seconds]
<lygstate>
u_printf is not relate to virgl, just improve it so that not depends on C++ std::string
mvlad has joined #dri-devel
lygstate has quit [Read error: Connection reset by peer]
mrcivvy has joined #dri-devel
mrcivvy has quit []
mrcivvy has joined #dri-devel
mrcivvy has quit []
linearcannon has quit [Ping timeout: 480 seconds]
Ziemas has quit [Server closed connection]
Ziemas has joined #dri-devel
jkrzyszt_ has joined #dri-devel
Major_Biscuit has joined #dri-devel
Major_Biscuit has quit []
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
MajorBiscuit has joined #dri-devel
JoshuaAshton has quit [Server closed connection]
JoshuaAshton has joined #dri-devel
rellla has quit [Server closed connection]
calebccff has quit [Server closed connection]
calebccff has joined #dri-devel
rellla has joined #dri-devel
tursulin has joined #dri-devel
kts has joined #dri-devel
marex has quit [Server closed connection]
marex has joined #dri-devel
xantoz has quit [Server closed connection]
xantoz has joined #dri-devel
elongbug has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
kts has quit []
lynxeye has joined #dri-devel
kts has joined #dri-devel
zackr has joined #dri-devel
zamundaaa has quit [Server closed connection]
<elongbug>
hi
<elongbug>
While reading the drm document (https://www.kernel.org/doc/html/latest/gpu/introduction.html) I found a typo or a structure name that needs to be updated, so I sent a patch to fix this. It's a simple fix, so if anyone has the time, could you please review it?
<javierm>
MrCooper: what DDX is using in that case ?
flacks has quit [Quit: Quitter]
<MrCooper>
javierm: the Xorg vesa driver, which more or less directly calls into the VESA APIs in the VBIOS
<javierm>
MrCooper: ah, I see. I wrongly assumed the vesa DDX worked with the vesafb, but now thinking about it doesn't make sense since that would just use the fbdev DDX
<MrCooper>
yeah, the Xorg vesa driver can't work if any graphics driver is active in the kernel
flacks has joined #dri-devel
<javierm>
MrCooper: "vesa: Ignoring device with a bound kernel driver" so then I wonder why Xorg says that if there's no graphics driver probed...
<javierm>
neither fbdev nor drm
<Lynne>
airlied: khronos lost it again and seems to have completely chaned the video spec
<Lynne>
a changelog wouldn't be amiss, because VkVideoDecodeH264SessionCreateInfoEXT is completely gone
<Lynne>
come on, the commit in Vulkan-Headers that did that has style changes in random places everywhere, this wouldn't fly in most open source projects
<javierm>
MrCooper: Ok, so xf86-video-vesa just calls to pci_device_has_kernel_driver() which is provided by libpciaccess
<javierm>
MrCooper: that haven't changed in a while and it gets the data from the sysfs entries, so the issue should be in the kernel
shashanks has joined #dri-devel
rgallaispou has joined #dri-devel
shashank_sharma has quit [Ping timeout: 480 seconds]
pH5 has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
<Lynne>
airlied: I've updated my repo to the latest version of the spec, could you update the drivers too to use the newest spec version?
Guest735 is now known as degasus
<Lynne>
a lot of fields were moved around, but there were only 2 changes, the is_long_term field and the removal of the h264 sessioncreateinfo
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
pH5 has joined #dri-devel
cef has quit [Quit: Zoom!]
cef has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.4]
MajorBiscuit has joined #dri-devel
elongbug_ has quit []
vup has quit []
vup has joined #dri-devel
rkanwal has joined #dri-devel
itoral has quit [Remote host closed the connection]
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
devilhorns has quit []
devilhorns has joined #dri-devel
devilhorns has quit []
ppascher has quit [Quit: Gateway shutdown]
<zmike>
pepp: are you able to see the same issue with ssbo writemask on the test I linked in the spirv issue?
<pepp>
zmike: I'd need to test with zink. The commit fixed this test for radeonsi so I'm not sure what's wrong here
<zmike>
pepp: I think you should still be able to see it in radeonsi since the writemask is wrong
<pepp>
zmike: are you running in SPIR-V mode? if yes, does it fail too in GL mode?
<zmike>
pepp: how do I test this?
<pepp>
zmike: there's probably a smart way to do it... instead I'm simply deleting the "SPIRV YES" line in the test file (the test shouldn't print "Running on SPIR-V mode")
<zmike>
I have never claimed to be smart
<zmike>
hm it still fails
<zmike>
🤔
lanodan has quit [Ping timeout: 480 seconds]
<pepp>
zmike: the test result seems flaky: I get both "fail" and "pass" with zink
<zmike>
hmmm
<zmike>
oh true
<zmike>
I had to run it a lot of times
<zmike>
in GL mode I still get write access set on the buffer
<zmike>
which is wrong
<zmike>
but probably this is an aco bug as well?
<zmike>
cc dschuermann
<zmike>
or maybe will take to another channel
<pepp>
the buffer isn't tagged readonly so it's expected that write access is set, isn't it?
<zmike>
hm
<pepp>
anyway in GL mode, the test result is flaky in GL mode with zink (without the commits). The changes only made the result identical in GL and SPIR-V mode
<zmike>
yeah true
<zmike>
okay, will reassign!
<zmike>
thanks for the analysis
elongbug has joined #dri-devel
pnowack has quit [Quit: pnowack]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
sdutt has joined #dri-devel
MrR[m] has quit [Server closed connection]
MrR[m] has joined #dri-devel
lanodan has joined #dri-devel
ralf1307[theythem][m] has quit [Server closed connection]
<jfalempe>
I had to install xfce, and 16 bits vnc server (gnome crashed in 16bits on my VM).
<jfalempe>
so it's a bit slower, but barely measurable.
devilhorns has joined #dri-devel
PiGLDN[m] has quit [Server closed connection]
PiGLDN[m] has joined #dri-devel
gawin has joined #dri-devel
<jekstrand>
Wow... It took GitLab 2 months to send me a notification e-mail...
<zmike>
I got one of those today too
lplc has joined #dri-devel
<karolherbst>
jekstrand: ohh, please don't benchmark with glxgears :) Also I think the blend stuff happens more often in like actual games and stuff. But anyway, I am sure somebody will review it and might point towards something more meaningful to test, or maybe they consider it to be fine :) we'll see
<daniels>
jekstrand, zmike: yeah, they got parked in a dead-task queue after a bunch of network issues, and I flushed that same queue earlier today after fixing some unrelated stuff
<daniels>
so now you get to remember what it is you did in January
<jekstrand>
karolherbst: If someone's trying to store_deref() to a NULL, I'm afraid I can't help them. :D
<zmike>
how nice
<karolherbst>
jekstrand: well
<karolherbst>
nope
<karolherbst>
that _can_ be valid
<jekstrand>
daniels: The MR I got an e-mail from was merged 2 months ago, too. :)
<karolherbst>
NULL pointer isn't invalid memory in generic
<karolherbst>
local mem e.g.
gawin has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: #define NULL (void *)0
ella-0 has joined #dri-devel
<jekstrand>
It's in the C standard
<karolherbst>
mhh, sure
<karolherbst>
I might try to figure out where that's coming from, but we have to do something there :/
kts has joined #dri-devel
<jekstrand>
Yes, it can be a valid shared/local pointer but you've got a constant there.
<karolherbst>
I will try to read the code and see where this might come from
<karolherbst>
this is a luxmark kernel though
<jekstrand>
have fun?
<karolherbst>
I suppose?
<jekstrand>
karolherbst: What nir_variable_mode are you using for lowering?
ella-0_ has quit [Remote host closed the connection]
<jekstrand>
karolherbst: You can't just not lower generic.
<ajax>
i literally do not touch the vulkan code in this series
<ajax>
is the debian builder possessed by a demon or something
<zmike>
hahahah
<karolherbst>
jekstrand: yeah.. I just followed what src/microsoft/clc/clc_compiler.c did for now
<jekstrand>
karolherbst: That doesn't support generic. :P
<karolherbst>
I am aware :)
<karolherbst>
I hoped I could ignore generic for longer, but seems like I can't anymore
<jekstrand>
karolherbst: Do nir_lower_explicit_io on shared, function_temp, shader_temp, and global all at the same time and use nir_address_format_62bit_generic.
<karolherbst>
jekstrand: after the normal lowering?
<karolherbst>
or instead of
<jekstrand>
No. It replaces whatever you have for those four.
<jekstrand>
For hardware like NV that can do a unified address space, we can add support for that later as an optimization. For now, using 62bit_generic will ensure you get something that works and isn't entirely unreasonable everywhere.
<jekstrand>
ajax: It's those new quantum compilers we installed. No longer deterministic.
<karolherbst>
what to do about nir_lower_vars_to_explicit_types? the same?
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
<karolherbst>
atm I am hitting an assert there
<karolherbst>
on the deref_cast I showed above
<jekstrand>
Those you don't have to run at the same time.
<jekstrand>
karolherbst: Oh, right. Yeah, you do have to do explicit types on all four at the same time. Sorry.
<jekstrand>
I forgot
<karolherbst>
ahh
apinheiro has joined #dri-devel
<jekstrand>
Because if you used a different size_align_func for two of the modes, generic wouldn't work.
<karolherbst>
right
fxkamd has joined #dri-devel
<karolherbst>
"#define NULL 0" :(
<karolherbst>
but I don't actually see it used
<karolherbst>
ehh now I have memcpies :)
<karolherbst>
but I do actually want to know where this is coming from, because I don't see luxmark using null pointers anywhere
<jekstrand>
karolherbst: Hard to tell
<karolherbst>
jekstrand: our variable names are what we got from the spirv, no?
<ajax>
hm, we silently started requiring dladdr()
pjakobsson has joined #dri-devel
<karolherbst>
:(
<karolherbst>
oh no
<ajax>
not that we care, really, even netbsd has it
<ajax>
but if you remove the -DHAVE_DLADDR from the world suddenly vulkan code stops building (builder's not cursed it turns out)
<jekstrand>
ajax: I don't see why. I only see it used for the disk cache stuff but that should affect GL too
<karolherbst>
jekstrand: soo uhm... if I have a variable name, but I don't find the source, what do I do?
<jekstrand>
What do you mean?
<ajax>
disk_cache_get_function_timestamp doesn't get defined if you don't -DHAVE_DLADDR
<karolherbst>
like I have this nir variable: "decl_var INTERP_MODE_NONE float pdf0"
<karolherbst>
I assume that name doesn't come out of nowhere, does it?
<ajax>
it is called unconditionally by at least tu and panvk, and the build dies before getting to the gl part of the world
<jekstrand>
karolherbst: Yeah, that's probably a variable named "pdf0" or "pdf"
<karolherbst>
so neither the spirv generated by clc nor libclc do contain any reference to that name
<jekstrand>
ajax: Hrm...
<ajax>
jekstrand: just needs another stub in the #else i think
<ajax>
or, we just assume a marginally competent libdl
<jekstrand>
ajax: Oh, yeah, we use that for getting build timestamps for cache UUIDs
<jekstrand>
karolherbst: Weird...
<karolherbst>
yeah...
<apinheiro>
jekstrand, hi, so finally relying on a vanilla IRC client
pjakobsson_ has quit [Ping timeout: 480 seconds]
<apinheiro>
sorry for the delay, I was using a matrix bridge,
<jekstrand>
apinheiro: No worries. :)
<apinheiro>
and needed someone else to confirm that dri-devel was not receiving my messages
<karolherbst>
let me print the nir before inlining at least..
<apinheiro>
jekstrand, well, I already mentioned it on the email, but as Iago can join, and I have not problem to join this Friday at 16:30 (local time) - 9:30 (your time)
<apinheiro>
perhaps it is easier to just to have that videochat
<apinheiro>
meanwhile I keep trying myself the common framework
<apinheiro>
unless you have questions that you would like to solve right now
<karolherbst>
jekstrand: ahh no... I think I messed up
<karolherbst>
but still.. why don't I see it in the source code..
<karolherbst>
so it does come from luxmark, just not sure from where
<jekstrand>
karolherbst: idk either. We don't tend to get variable names from nowhere.
<karolherbst>
yeah..
<karolherbst>
I might messed up printing stuff :)
<karolherbst>
but now I found the code where the null pointer comes from
<jekstrand>
apinheiro: Right. So where I'm at right now is that I got the common submit changes working (!15566), tested ANV with it and some hacks to force submit threads all the time (that worked), then converted lavapipe to convince myself even more that it's working as intended. So far, everything's good.
<karolherbst>
jekstrand: so uhm... something is weird
<jekstrand>
apinheiro: Then, yesterday, I started deleting code from v3dv to see where that would take me and I started to get confused when I looked at the thread pool stuff you're doing there.
<apinheiro>
jekstrand, yes I saw all those MR
<karolherbst>
jekstrand: I think my console failed me
<apinheiro>
in fact I was using the one that allowed force threaded as reference
<apinheiro>
(although I think that now it is already merge)
<jekstrand>
apinheiro: In particular, a bunch of the CPU jobs call v3dv_QueueWaitIdle() and I don't know how that works at all. How can you wait for idle from a job that's running on a thread?
<jekstrand>
apinheiro: Yeah, I just assigned marge a minute ago.
<karolherbst>
jekstrand: so yeah.. they pass in a NULL pointer but NULL check it before
<jekstrand>
karolherbst: Ok, then that should be fine.
<karolherbst>
nir should have optimized it away :)
<jekstrand>
karolherbst: Well, yeah. Not sure why it didn't.
<karolherbst>
probably not enough passes
<jekstrand>
probably
<apinheiro>
> How can you wait for idle from a job that's running on a thread?
<apinheiro>
well, thanks checked on the implementation of that function
<apinheiro>
/* Check that we don't have any wait threads running in the CPU first,
<karolherbst>
maybe that if (off) gets translated to something weird
<jekstrand>
karolherbst: You probably need to run nir_dead_cf, nir_opt_if, and maybe some other stuff.
<karolherbst>
I do that
<jekstrand>
NIR can eat all that up if you run enough passes
<jekstrand>
apinheiro: Yeah, I saw that, but how does that not wait on the thread that's calling it?
<jekstrand>
vkQueueWaitIdle should wait for absolutely everything that's been submitted via vkQueueSubmit() prior to calling the entrypoint. If a CPU job is running it, by definition, was submitted via vkQueueSubmit().
<jekstrand>
apinheiro: The other big question I have is why do you have a whole thread pool and not just one thread? Are you trying to spread CPU image copies over multiple threads? How much perf boost do you get from doing so?
<karolherbst>
maybe something can't look behind the deref_cast?
<apinheiro>
> Are you trying to spread CPU image copies over multiple threads
<apinheiro>
jekstrand, no that is not the use case
<karolherbst>
maybe we need to teach opt_deref about ptr comparisons?
<apinheiro>
the reason to have several threads, is for any cmdbuffer that could include a wait
jkrzyszt_ has quit [Remote host closed the connection]
<apinheiro>
as we use the thread for doing the polling to implement the wait on the CPU
<apinheiro>
and that is also the reason we have a "master thread", as that handles that all the threads finished
<apinheiro>
I guess that you are suggesting that that could be done with just one thread?
gawin has joined #dri-devel
<jekstrand>
karolherbst: Yeah, we should probably have an alu-of-cast opt somewhere.
<jekstrand>
karolherbst: As long as casts do nothing to the bits (that's the current NIR assumption), with alu-of-cast, we can always drop the cast.
<karolherbst>
yeah..
<jekstrand>
karolherbst: Sounds like a job for opt_deref
<karolherbst>
that was the idea I just came up with as well
<karolherbst>
just have a "alu copy" version of the chain or something
<jekstrand>
apinheiro: Yeah, so if it's just about waiting on things, that should all be handled with the new framework, mostly. There will have to be a syncobj on the queue that everything signals so we can do the CPU wait on that at any time.
<karolherbst>
jekstrand: but what is weird is the inner block of the if
ybogdano has joined #dri-devel
<apinheiro>
jekstrand, so I guess that if right now we have like 10 threads for each wait, we would need 10 syncobjs now?
<karolherbst>
so it assigs the null pointer to some new value and store_deref on that one
<karolherbst>
I think there might even be a bug with some nir pass
<karolherbst>
ehh wait
<karolherbst>
no, that's fine
<karolherbst>
I am stupid :)
<karolherbst>
I forgot it's all inlined and here we just have the version with a passed in NULL pointer
<apinheiro>
in any case, that was basically one of the questions I have in my mind while trying to move things
jkrzyszt_ has joined #dri-devel
<apinheiro>
how much of the custom threading/idling would be handled by the common framework own-thread support
<apinheiro>
I guess that in your opinion is "all"
<jekstrand>
apinheiro: If you're not concerned about trying to spread CPU operations across threads, I think the answer is "all"
<jekstrand>
apinheiro: The driver_submit() hook can just block on the syncobj to wait for previous stuff (instead of the current QueueWaitIdle() call), do the CPU thing, then submit more GPU work as needed.
<apinheiro>
ok, thats good. Right now we are not thinking on that, and even if we were, we can plan about that later
<jekstrand>
apinheiro: If the last thing in the batch is a CPU job, you'll have to manually call vk_sync_signal() on all submit->signals[i].sync to trigger them.
Duke`` has joined #dri-devel
<apinheiro>
jekstrand, ok, thanks
<apinheiro>
then I guess that the only doubt here is your question about v3dv_QueueWaitIdle, specifically about how we use it internally, right?
<jekstrand>
Yeah, but I think if we do what I said above, it'll be gone and then I'll stop worrying about it. :D
<jekstrand>
It was mostly a "How is anything working?!?" moment.
<jekstrand>
I'm sure it's working somehow. You're conformant. I just couldn't figure out how.
<karolherbst>
jekstrand: do we have a helper function which just goes up the deref_cast chain without anything else? Or something which gives us the base + offset?
<karolherbst>
jekstrand: so my idea is to replace all deref_cast sources of alu instructions with their base + offset
<karolherbst>
and let opt_algebraic figure it out
<karolherbst>
ehh and constant_folding
<jekstrand>
karolherbst: You don't need to do any base+offset stuff.
<apinheiro>
jekstrand, well, fwiw, when I was re-reading the common code I basically made sense to use it to wait to idle, but it is true that what you mentioned it before is concerning
<apinheiro>
will take a look and mention to Iago tomorrow at the office
<karolherbst>
jekstrand: what do you mean?
iive has joined #dri-devel
<apinheiro>
jekstrand, btw, not sure if this covers all what you wanted to mention on the video chat, or if you still find valuable if we have a little chat all three this Friday
<jekstrand>
apinheiro: I think we pretty well covered it.
<apinheiro>
jekstrand, ok, thanks for the chat
<apinheiro>
although probably I would send some questions as I keep advancing on trying to use the common framework
<apinheiro>
and btw, sorry if I used the wrong oftc channel for this chat
<jekstrand>
apinheiro: No, you're fine. Anything can be talked about in #dri-devel.
<karolherbst>
jekstrand: I was also thinking about dealing with offset_of/container_of/etc... cases
<jekstrand>
karolherbst: Those are a lot harder to get right if we want a "real" pointer out the other end.
<jekstrand>
apinheiro: If you're making good progress, I'll probably put my branch down for now. I was mostly using this as an excuse to crawl around in v3dv and see how it works a bit more.
<karolherbst>
sure, but hence using nir_build_deref_offset, add it to the original base and do the compare on that
<apinheiro>
not in a hurry as this only affects a CTS test for something that means a corner case
<jekstrand>
karolherbst: I don't want to tie nir_lower_explicit_io into optimization any more than we absolutely have to. opt_memcpy already does a bit but ugh.
adjtm has quit [Quit: Leaving]
<apinheiro>
jekstrand, "If you're making good progress"
<apinheiro>
well, based on your description
<apinheiro>
I think that we are on a similar state
<karolherbst>
jekstrand: ahhh
<apinheiro>
started to move to the types defined on the common framework
<apinheiro>
(vk semaphore/fence etc)
<jekstrand>
apinheiro: I may keep poking a bit for my own education. We'll see.
<apinheiro>
and start to remove code that should be handled
<apinheiro>
by thecommon framework
<apinheiro>
and got somehow stuck when started to write the driver hook based on previous
<apinheiro>
submission code
<apinheiro>
so I don't think that I advanced a lot more that you
<karolherbst>
jekstrand: okay cool, so that gets me further without having to support generic pointers :)
<karolherbst>
now I need memcpy regardless
<apinheiro>
> jekstrand> apinheiro: I may keep poking a bit for my own education. We'll see.
<apinheiro>
ok as you prefer, but as mentioned, I will keep working on it, and likely send some questions around
<apinheiro>
need to disconnect now, again thanks for all your help
<ajax>
anholt: updated !15649, seems like it actually works now
kts has quit [Quit: Konversation terminated!]
mbrost has joined #dri-devel
<karolherbst>
nooo.. it crashes inside a shader :(
<jekstrand>
karolherbst: What crashes? My new opt? Impossible!
<jekstrand>
I thoroughly tested it with GCC.
<karolherbst>
jekstrand: nah, I don't think it's your change
<karolherbst>
luxmark compiles successfully now, but one of the shader access invalid memory :)
<karolherbst>
I see that with some of the math_bruteforce tests as well
<karolherbst>
but at least it compiles now :)
<jekstrand>
\o/
<karolherbst>
the other scene make my machine running out of memory though :D
<karolherbst>
we really need to tackle calling functions :/
<jekstrand>
Yeah... That's gonna be a tricky one.
<karolherbst>
well.. first I want the smaller one to run anyway :)
DanaG has quit [Remote host closed the connection]
<dcbaker>
ajax: what's the status of the amber branch? If there's still work to do, how can I help?
aravind has quit [Ping timeout: 480 seconds]
DanaG has joined #dri-devel
<linkmauve>
jfalempe, do you want me to test your MR on PowerPC? I’m not sure llvmpipe works currently though, I think it’s using softpipe instead, but I could have a look at whether I can force enable it.
<linkmauve>
I have a Wii U and a Wii readily available for testing.
tzimmermann_ has quit [Remote host closed the connection]
tzimmermann__ has joined #dri-devel
<gawin>
wii has hardware 3d acceleration?
khfeng has joined #dri-devel
<jekstrand>
Yeah. It's an oldish radeon
mbrost has quit [Ping timeout: 480 seconds]
<jekstrand>
daniels: The windows-vs2019 jobs are taking forever. Is the builder slogged or down?
<linkmauve>
gawin, Wii has some early register-combinator hardware, Wii U has a Radeon R7xx-like, but neither of them are supported by the kernel.
<linkmauve>
Nevertheless, this MR is about llvmpipe, so it doesn’t require any kernel cooperation.
<karolherbst>
jekstrand: ehh.. it regresses some weird tests I don't know why
<gawin>
I remember that wii is basically gamecube with extra arm core, but not sure what's with gpu (if they did upgrade to r300)
<linkmauve>
gawin, it has the exact same GPU as the GameCube, running at a slightly higher frequency.
<jekstrand>
karolherbst: :(
<linkmauve>
And the Wii U has both the R7xx-like and the exact same GPU as the Wii, with the same limitations.
<karolherbst>
I have the kernel in a moment, but it's some &struct.field - &struct being not 0 vs 0
<karolherbst>
and field is like the first field
<karolherbst>
I have no idea
<daniels>
jekstrand: slogged
<daniels>
jekstrand: we've been trying to provision another one, but that's got stuck in Kafkaesque bureaucracy
<daniels>
(I mean visualstudio.com is rather Kafkaesque in and of itself, but also the person who arranged it all for me has since moved to a new job which doesn't help)
<karolherbst>
no matter how I look at it, the result really looks like 0
<karolherbst>
but maybe we forgot about pointer math?
<karolherbst>
mhh I think the printed source is the wrong one :)
alyssa has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.4]
rkanwal has joined #dri-devel
gouchi has joined #dri-devel
pnowack has joined #dri-devel
devilhorns has quit []
ukleinek has joined #dri-devel
alatiera9 has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
HankB_ has joined #dri-devel
nchery has joined #dri-devel
rbrune has joined #dri-devel
<karolherbst>
ohh wait.. there is a hidden char I didn't see
mbrost has quit [Read error: Connection reset by peer]
SallyAhaj has joined #dri-devel
SallyAhaj has left #dri-devel [Leaving]
gouchi has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
<airlied>
Lynne: the video spec is highly provisional, the ABI is in no way set in stone until it's removed from the beta file
agd5f_ has joined #dri-devel
lcn has quit [Server closed connection]
lcn has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
nchery has quit [Read error: Connection reset by peer]
aura[m] has quit [Server closed connection]
aura[m] has joined #dri-devel
nchery has joined #dri-devel
<alyssa>
Is there a pipe_image_view -> pipe_sampler_view helper?
<alyssa>
(For hw that only has 1 kind of texture descriptor and wants to reuse the code path.)
* alyssa
writes one
<karolherbst>
jekstrand: .... I'll comment on the MR :D
<karolherbst>
you put a 0 instead of i
<jekstrand>
karolherbst: updated
* karolherbst
is doing another test run
<karolherbst>
luxmark doesn't crash anymore :O
<karolherbst>
it renders _something- :O
<karolherbst>
:O
<karolherbst>
:O
<karolherbst>
it looks correct :O
<alyssa>
luxmark?
<karolherbst>
yes
<jekstrand>
!
<karolherbst>
obligatory pic post on twitter
<alyssa>
path tracer?
jkrzyszt_ has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: yes
<alyssa>
nice :o
<karolherbst>
jekstrand: image validation fails though
<karolherbst>
64.03% pixels are different :D
<karolherbst>
I should get those tests fixed where we fail precision stuff
<karolherbst>
so my inline samplers are also working :D
apinheiro has quit [Ping timeout: 480 seconds]
<karolherbst>
ehh luxmark 4 needs clRetainDevice
* karolherbst
goes on hacking
<alyssa>
:-D
<alyssa>
Does luxmark work on clover?
<alyssa>
ooi
<karolherbst>
mhh
<karolherbst>
no
<karolherbst>
at least not with llvmpipe
<alyssa>
Woo
<airlied>
luxmark 4 needs functions
<karolherbst>
I got it to show something with nouveau though
<airlied>
with clover? I thought clover couldn't run luxmark?
<karolherbst>
it needs inline samplers though, so maybe it works with that MR merged?
<airlied>
ah
<karolherbst>
let me try
<karolherbst>
airlied: I guess I have to check why ADDRESS_REPEAT doesn't produce the correct result as this could affect luxmark.. but I don't know, it's just a random guess :P
<karolherbst>
yeah no idea
<karolherbst>
something is up with clover
<karolherbst>
the scene remains black even with inline samplers
adjtm has joined #dri-devel
<karolherbst>
jenatali: btw, you should be able to run luxmark without support for generic pointers :)
jagan_ has joined #dri-devel
<karolherbst>
we fixed one of the problems with it today, so all generic pointers should get optimized away now
<jenatali>
karolherbst: yeah I was able to run it, I just have to specify the language as CL1.2 instead of 3 to turn off generics
<karolherbst>
jenatali: I run with 3.0
<karolherbst>
and don't support generic
<jenatali>
Ah cool
<karolherbst>
they passed in a NULL pointer
<karolherbst>
but we optimized a ptr == 0 path, so it vanishes now
<karolherbst>
jenatali: how close did you get with image validation?
<karolherbst>
for me it says ~63% wrong
<jenatali>
It works
<karolherbst>
well, it works for me as well, it just complains the image doesn't validate
<karolherbst>
or does it for you?
mbrost has quit [Ping timeout: 480 seconds]
<jenatali>
Pretty sure it dif
<jenatali>
Did*
<karolherbst>
mhh okay
<karolherbst>
weird
<jenatali>
Been a while and I'm not in front of a PC to try it now
<karolherbst>
but I suspect you also passed the CTS no?
<karolherbst>
yeah no worry about trying, I just need to think about a starting point to debug this
<jenatali>
Yeah pretty much. I think some drivers failed some of the tests, but across the ecosystem we pass it all
<karolherbst>
okay
<karolherbst>
I don't pass all image tests :D
<karolherbst>
CL_ADDRESS_REPEAT produces the wrong result.. have to figure out why
<karolherbst>
that reminds me, subbuffers are also not working correctly, so I hope luxmark doesn't use that
<alyssa>
REPEAT is broken with ... llvmpipe?
<karolherbst>
apparently
<karolherbst>
everything else seems to work
<karolherbst>
alyssa: it looks like it mirrors_repeat instead
mbrost has joined #dri-devel
<alyssa>
delight
<karolherbst>
maybe it's doing something totally different
<karolherbst>
1D it looks like mirror_repeat, but with 2D it's just completely off
<karolherbst>
well
<karolherbst>
for ints
<karolherbst>
for floats it's all good
<karolherbst>
Integer coords resolve to 10,0,2 with img size 46,48,32
<karolherbst>
Value really found in image at 10,47,2 (unique)
<karolherbst>
that's for 3d
<karolherbst>
mhh seems like for 2d and 3d only the y coord is wrong
<karolherbst>
for 1d it's x
<karolherbst>
same for 1darray
<karolherbst>
and y for 2darray
<karolherbst>
normalized float coords, float results with CL_FILTER_NEAREST is the only combination which seems to not suffer from that bug
<alyssa>
karolherbst: REPEAT without normalized is undefined
<karolherbst>
alyssa: sure, but I meant float coords + float result is fine
<karolherbst>
where if you get int coords or int result it breaks
Surkow has quit [Remote host closed the connection]
<karolherbst>
but CL allows CL_FILTER_LINEAR on REPEAT
italove has joined #dri-devel
<karolherbst>
I just don't think they require a perfect match
<alyssa>
Test case 'dEQP-GLES31.functional.image_load_store.2d.store.rgba32f'.. Pass (Pass)
<alyssa>
woo!
<karolherbst>
nice
<alyssa>
Better do image loads next
<airlied>
karolherbst: int coords are unnormalised aren't they?
<karolherbst>
I should add support for more formats once I get the minimum amount working :D
<karolherbst>
I kind of suspect the test prints what it does in a weird way
<karolherbst>
dunno
<karolherbst>
airlied: anyway.. it seems to be broken for int formats
<alyssa>
Valhall has both LD_TEX and TEX_FETCH instructions. They both operate on texture descriptors (the cmdstream side is the same).
<alyssa>
Anyone want to guess why there are two ops? :')
<karolherbst>
alyssa: one is txl and the other txf?
<karolherbst>
nvidia also has both ops
<alyssa>
karolherbst: no, they are both txf
<karolherbst>
wait...
<karolherbst>
really?
<alyssa>
yes
<karolherbst>
mhh tex is txl for us
<airlied>
it's LD not LOD I assume
<airlied>
alyssa: different cache paths?
Surkow|laptop has joined #dri-devel
<Lynne>
airlied: I know, but we have to keep up with them
<alyssa>
airlied: Ding ding
<alyssa>
I mean
<alyssa>
I assume
<karolherbst>
ohhh wait
Haaninjo has joined #dri-devel
<karolherbst>
mhh
<alyssa>
OpenGL images vs textures
<alyssa>
writable vs readonly caches
<karolherbst>
alyssa: ehh I meant TXD vs txl/txf
<karolherbst>
alyssa: mhh, do you other other tex ops?
<karolherbst>
eh well.. no matter
<karolherbst>
we also have special surface ops
Andy[m] has quit [Server closed connection]
Andy[m] has joined #dri-devel
doras has quit [Server closed connection]
doras has joined #dri-devel
<karolherbst>
alyssa: so you have proper image instructions? how nice
kusma has quit [Server closed connection]
kusma has joined #dri-devel
<alyssa>
"proper"
robertmader[m] has quit [Server closed connection]
robertmader[m] has joined #dri-devel
Strit[m] has quit [Server closed connection]
Strit[m] has joined #dri-devel
<karolherbst>
ahh I see
<karolherbst>
so manual format conversion?
Sumera[m] has quit [Server closed connection]
Sumera[m] has joined #dri-devel
T_UNIX has quit [Server closed connection]
T_UNIX has joined #dri-devel
zamundaaa[m] has quit [Server closed connection]
zamundaaa[m] has joined #dri-devel
<alyssa>
No
heat_ has joined #dri-devel
<alyssa>
image loads work, image atomics next..
<jagan_>
danvet: Thanks for your e-mail on hotplug.
* jekstrand
waits for his powervr kernel to build
<danvet>
jekstrand, great cue
<danvet>
jekstrand, am I supposed to look at that thing or are you taking care?
<danvet>
like the entire "does it use latest helpers everywhere, not reinvent wheels, reasonable locking
<jekstrand>
danvet: uAPI isn't going to be ready for quite some time.
<jekstrand>
I've not looked at any of the helpers or locking
<danvet>
jekstrand, well is the uapi so bad the implementation necessarily is unreviewable too?
<jekstrand>
I'm just trying to get it to build so I can run it on this here horrible chromebook
<jekstrand>
danvet: idk
<danvet>
I guess we'll see
<jagan_>
danvet: as you mentioned the my QT uses kms, but doesn't handle hotplugs - do we have any sample application to handle hotplug in order test my switching code.
<jekstrand>
danvet: One could probably do a "do they use helpers?" review
<danvet>
jagan_, hm, we might be bad at this
<danvet>
emersion, pq do we have a neat small sample compositor for all the kms bits?
<danvet>
jagan_ is specifically looking for hotplug handling and auto reconfigure, but I guess the entire dance would be nice to have
<danvet>
jagan_, added some compositor folks as your best bet
<danvet>
we have some testcases, but they test stuff and aren't really a great example for common case autoconfiguration I think
<jagan_>
danvet: does it mean none of the drm applications from userspace cannot handle hotplug?
<danvet>
jagan_, double negation, I'm not clear what you mean?
mbrost has quit [Ping timeout: 480 seconds]
<jagan_>
danvet: what if we fix QT application to support hotplug handling like some kind of IOCTL or any other mechanism - just a guess.
<danvet>
yeah that's what you need to do
<danvet>
writing a compositor (and if your drm master you're writing a compositor) is a lot of work
<danvet>
I think it's still the only reusable compositor toolbox around
<danvet>
ofc if your actual app is also in the compositor (sounds like that's what your qt thing is) then the wl protocol isn't needed
<danvet>
but all the other compositor bits you still need
<danvet>
next up usually is the arcane vt switch dance
<jagan_>
danvet: i think i can try to integrate this compositor on my qt app build and see for what happend.
<jagan_>
The actual app i'm running is boot2qt -
<danvet>
well maybe the compositor in that thing is just a bit too simple and needs a bunch of fixes
shankaru has quit [Quit: Leaving.]
<jagan_>
it is based on qt5. not sure if something fixed compositor level in qt6 - may be it worth a check the boot2qt on qt6?
mbrost has joined #dri-devel
<jagan_>
danvet: apart from this, if we follow switching based on atomic_best_encoder callback then we don't care of this userspace hotpluging isn't it?
Duke`` has quit [Ping timeout: 480 seconds]
<danvet>
jagan_, you still need userspace hotplug
<danvet>
but also I don't actually think for your case you need to select the right encoder
<danvet>
since that's only needed if 1 drm_connector has 2 or more drm_encoders as options
ngcortes has joined #dri-devel
<danvet>
but if you have 2 drm_connector (hdmi+lvds)
<danvet>
then the default code in atomic helpers will dtrt
<jagan_>
danvet: ohh it's overall the userspace bug.
<danvet>
you still need userspace to do the modeset
<danvet>
atomic_best_encoder is only about selecting the right encoder when that modeset happens
<jagan_>
danvet: sorry for asking again. do we have any readily available test apps to support hotplug - none right?
mvlad has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
<karolherbst>
airlied: .... I should have looked closer at the thing
<karolherbst>
the coords are subnormals
<alyssa>
OOof
<karolherbst>
at least -0x1.724288p-38 looks like subnormal :D
lygstate has joined #dri-devel
<karolherbst>
that also explains the weird clamping
mszyprow has joined #dri-devel
<alyssa>
flush-to-zero?
<karolherbst>
yeah
<karolherbst>
llvmpipe enables that
<karolherbst>
but I am surprised that coords subnormals are.. well.. a supported thing
tzimmermann__ has quit [Ping timeout: 480 seconds]
<karolherbst>
it's still a bit weird
<karolherbst>
ohh it's -
<karolherbst>
yeah okay
<karolherbst>
maybe that's the problem though
<karolherbst>
airlied: so if for a 1D texture the coord would be -0.0 what would that clamp to with TEX_WRAP_REPEAT?
<karolherbst>
0 or size?
<alyssa>
Lol
<alyssa>
karolherbst: IMO size, but...
<karolherbst>
alyssa: so size is what is happening
<karolherbst>
let me check why the CTS thinks it's supposed to be 0
<karolherbst>
btw it's not a subnormal..
<karolherbst>
I always confuse this binary vs decimal thing
bnieuwenhuizen has quit [Quit: Bye]
bnieuwenhuizen has joined #dri-devel
<karolherbst>
alyssa: ehh.. the CTS floors the number first
<karolherbst>
so it becomes -1.0
<alyssa>
Hmm
rkanwal has quit [Quit: rkanwal]
<karolherbst>
(x - floorf(x)) * size
<alyssa>
frac(x) = (x - floorf(x))
<alyssa>
I guess that's reasonable
<karolherbst>
x - floorf(x) is 1
<alyssa>
Yeah, that's a really weird edge case
<alyssa>
I wonder how hardware handles this
<karolherbst>
dunno
<alyssa>
---wait
* alyssa
checks the spec..
<karolherbst>
keep in mind I am talking about CL here
<alyssa>
nope
<alyssa>
floor(-0.0) = -0.0
<karolherbst>
sure, but it's not -0.0
<karolherbst>
it's -1.81169135e-10
<alyssa>
No, like, ffloor(-0.0) = -0.0 by definition
<karolherbst>
ahh, right, but we shouldn't end up with -0.0 is what I try to say
<karolherbst>
p notation is just odd
<karolherbst>
so I thought it's subnormal, but it isn't
<alyssa>
Right... was just saying that roundToIntegralTowardsNegative preserves signed zeroes according to section 5.9 of the IEEE 754-2019 spec
<alyssa>
ffloor(-1.81169135e-10) is of course -1.0
<alyssa>
so that fraction is 0.9999999998188309
<karolherbst>
mhh
<karolherbst>
alyssa: my CPU disagrees
<alyssa>
Then your CPU is wrong...?
<karolherbst>
alyssa: soo. what the CTS is doing is this:
<karolherbst>
anyway, I think something else is up with luxmark rendering the wrong result
alyssa has quit [Quit: leaving]
<karolherbst>
ohh it does division by zero stuff
<karolherbst>
uhhhh
<karolherbst>
apparently 4.0 fixed that
heat has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
<anholt>
heads up for anyone that tries my manual ci: I'm moving, and 945, g41, hsw, and jetson jobs will just stall for a couple of days until I get set back up.
mclasen has quit []
mclasen has joined #dri-devel
<karolherbst>
our compiler is slooooowwww :D
<karolherbst>
yay.. luxmark v4 runs as well
<karolherbst>
after it compiled for 10 minutes that is
<bnieuwenhuizen>
is that clang/LLVM, or nir+backend?