saurabhg has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
nchery is now known as Guest6264
nchery has joined #dri-devel
danvet has joined #dri-devel
srslypascal is now known as Guest6265
srslypascal has joined #dri-devel
Guest6264 has quit [Ping timeout: 480 seconds]
Guest6265 has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
pochu has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
toolchains has joined #dri-devel
tzimmermann has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
Solo has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
saurabhg has joined #dri-devel
Solo has quit []
lemonzest has joined #dri-devel
_uea009 has joined #dri-devel
mvlad has joined #dri-devel
fab has joined #dri-devel
_uea009 has quit []
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
<pq>
Kayden, why is enabling universal planes (but not atomic) in Xorg/modesetting not a solution?
mwalle has joined #dri-devel
<emersion>
Kayden: DRM_CLIENT_CAP_USE_BROKEN_MODIFIERS to enable the fancy stuff :D
<Kayden>
pq: I'll be honest, I haven't looked at universal planes in a long time - I'm not that familiar with display stuff. they aren't tied together?
<pq>
Kayden, no, different caps.
<pq>
atomic implies universal, but universal can be without atomic too
<Kayden>
ah
<pq>
universal is just "I undertand that the planes I see can be other than just overlays"
saurabh_1 has joined #dri-devel
<pq>
so I would think that enabling universal planes will expose the primary planes in the Resources arrays which allows you to get all the modifier info you need.
<Kayden>
seems like a reasonable idea!
<pq>
there is a bit of uncertainly about whether universal planes alone is enough to expose the KMS properties for the good modifier info, but I don't see why it wouldn't.
saurabhg has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
tursulin has joined #dri-devel
<MrCooper>
pq: only atomic can solve the "not enough display bandwidth depending on the monitor configurations" issue though?
<MrCooper>
Kayden: there is a path to fix that in mutter, it needs to use TEST_ONLY atomic commits (more)
<pq>
MrCooper, yes, but was that a question here?
<MrCooper>
I thought so :)
<pq>
I didn't.
<MrCooper>
Kayden mentioned it early on about this topic, and it's the reason why mutter doesn't enable modifiers with i915 yet
<pq>
I suppose it would become a problem if modesetting assumes a legacy flip will work and then it doesn't?
<pq>
yeah, but that's not at all what the commit talks about
<pq>
this is about flipping to client buffers, not about enabling outputs
<MrCooper>
it could be an issue if the flip changes modifiers
<pq>
surely the flip just fails and modesetting falls back?
sagar_ has quit [Remote host closed the connection]
sagar_ has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab is now known as Guest6277
vliaskov has quit []
whald has joined #dri-devel
fahien has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
<whald>
hi! i'm currently debugging stuff and notice that thread sanitizer complains about data races in Mesa, specifically the "gdrv0" thread spawned by iris_create_context does not grab the EGL "display" mutex before messing with data concurrently touched by the main thread, which does grab that mutex.
tibetiroka has joined #dri-devel
<whald>
is this "ok" and tsan just does not understand what's going on? i certainly don't understand. o_O
toolchains has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
kts has joined #dri-devel
<whald>
setting GALLIUM_THREAD=0 eliminates those warnings, btw
tibetiroka has quit []
<zmike>
I'd suggest opening a ticket with your findings along with the output of tsan
<ajax>
bah, we can override the gl and glx extension lists but not the egl list
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
luc4 has joined #dri-devel
toolchains has joined #dri-devel
<luc4>
Hello! Anyone who knows what it may mean the error "No space left on device" from drmModeSetPlane? What "space" is this? I guess it does not mean "space" in geometrical terms, but I guess it is not even in terms of GPU mem. Any idea what "space" may mean here?
<ajax>
it's probably being used in the sense of "you don't have enough video ram to fit what you asked for"
<luc4>
ajax: yes, this was my first thought, but I tried to increase it and whatever value I put in there, the same happens, precisely with the same values.
<ajax>
luc4: drm_atomic_plane_check() in the kernel has exactly one match for -ENOSPC, i bet its yours
<luc4>
ajax: I'm on a raspberry pi, so I can increase it with a simple reboot
<tonyk>
luc4: try adding some debug log with echo 0x04 | sudo tee /sys/module/drm/parameters/debug
<luc4>
tonyk: I'm trying! Thanks!
<tonyk>
and dmesg will tell you what was wrong with your drmModeSetPlane
<luc4>
ajax: I'm looking for that, assuming I can understand something, thanks
<ajax>
"git grep for the errno value you're getting" is a surprisingly effective technique
<ajax>
the nice thing about being able to read the kernel source, you see,
<ajax>
makes me feel like a superhero every time it works
<luc4>
tonyk: appearantly, no error is shown. Only some debug logs :-(
<tonyk>
maybe 0x04 (KMS messages) is not the right one then
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
<luc4>
tonyk: the page mentions echo 0x19F | sudo tee /sys/module/drm/parameters/debug
<tonyk>
yeah
<tonyk>
this enables everything
<MrCooper>
feaneron: the list boils down to: "All released AMD GPUs" :)
<MrCooper>
hmm, you asked for a general list though, not just AMD
<daniels>
luc4: at a guess, you're passing through integer source co-ordinates instead of 16.16
<luc4>
daniels: uint32_t sw = 1920u << 16;
<daniels>
damn
<luc4>
daniels: I did not mention that if I run my application with a 720p setup, everything seems to work properly
toolchains has quit [Ping timeout: 480 seconds]
<ajax>
you want bit 0x10 set to get DRM_DEBUG_ATOMIC messages
<ajax>
(which i think is what you want here, given erro)
<luc4>
ajax: I should have also mentioned this is the first time I use drm API, so it is very likely I did a mess... but can someone see something wrong in these logs? https://pastebin.com/kWYYLqke
<luc4>
I'm drawing to multiple planes concurrently, then one reporting the error is the one with id 130
<luc4>
What I see is that as long as I set the dest rect to something smaller than 1080p, everything works
<luc4>
I decreased GPU mem from 600MB to 300MB, and the limit is identical. Cannot set the plane 130 to something larger than 1828x1080
<ajax>
and beyond this point you probably maybe are dealing with the actual hardware limits?
<ajax>
i would figure out which of those two is the one you're hitting, and work backwards from there to whether the check is actually valid or if there's a way to make the driver pass it.
<luc4>
ajax: would be weird... I'm used to render multiple 1080p videos with the rpi
aswar002 has quit [Ping timeout: 480 seconds]
<ajax>
it does seem like a thing that should work, i agree
<ajax>
anyway that looks like where it's failing to me
<luc4>
I'm afraid this may be simply me doing things the wrong way... but it seems to really work well up to 1828x1080, so maybe you are right...
<luc4>
I may simply try to remove that check and use a patched kernel to see what happens then
ybogdano has quit [Ping timeout: 480 seconds]
<luc4>
ajax: actually there are two ENOSPC there
<luc4>
ajax: it also seems it is possible to disable that portion
alyssa has quit [Quit: leaving]
iive has joined #dri-devel
mbrost_ has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
fahien has quit [Quit: fahien]
MajorBiscuit has joined #dri-devel
linearcannon has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<feaneron>
MrCooper: thanks :) i had a brief moment of absolute panic after acquiring that card, and not checking if it was actually supported
ngcortes has joined #dri-devel
Akari has quit [Read error: Connection reset by peer]
sdutt has quit []
sdutt has joined #dri-devel
Akari has joined #dri-devel
<jekstrand>
robclark: I think I've asked this before but how to descriptors for textures, images, and texturebuffers work on arduino?
<jekstrand>
robclark: Is it basically a 64-bit pointer to a descriptor?
<jekstrand>
Some number of base pointers that get bound and then a base_index+offset?
<jekstrand>
One single table?
<jekstrand>
anholt: How about v3d? ^^
luc4 has quit [Ping timeout: 480 seconds]
<robclark>
jekstrand: so, adreno has two things.. textures (which have tex and samp descriptors) and "IBO"s (SSBOs and Images mapped into a single namespace).. (or well three things if you count UBOs).. those can be used in bindful way (w/ slot # passed as src param to corresponding instruction).. or bindless way that involves some combination of a special "implicit src" register and regular src register..
<jekstrand>
robclark: What are these "base" and "index"?
<jekstrand>
I'm seeing 3 bits for the base. So does that mean you can have 8 bases bound?
<robclark>
base looks like it comes from nir_intrinsic_desc_set()
<anholt>
jekstrand: there's a uniform stream (a FIFO the order you use your uniforms in the program, except with ability to slowly reset location for doing control flow), and descriptors you use are 2ish dwords in that uniform stream.
<jekstrand>
robclark: How do these bases work? Do you have one register for each one?
<robclark>
jekstrand: tbh I've not looked too much at the bindless case, we don't use it on gallium side of things.. cwabbott would know the vk side better
<jekstrand>
Ok
<jekstrand>
We'll see if cwabbott materializes. :)
<robclark>
there is a BINDLESS_BASE register for each shader stage fwiw, with 64b pointer (which I assume is to some chunk of memory that has the usual descriptor layout)
<jekstrand>
Looks like turnip exposes 4 descriptor sets
rasterman has quit [Quit: Gettin' stinky!]
<flto>
robclark, jekstrand: the bases are stored in registers, they are shared between stages (except compute has its own set of registers). a6xx has 5 bases (and a7xx has 8), the driver exposes one less because one is used to implement dynamic descriptors. the low bits of the registers can be used to choose either 16B or 64B stride for the descriptor (turnip only uses 64B stride)
kchibisov has quit [Remote host closed the connection]
kchibisov has joined #dri-devel
<jekstrand>
flto: Ok, that's the picture I was starting to see. Thanks for confirming.
kts has quit [Quit: Konversation terminated!]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
<cwabbott>
what flto said
<cwabbott>
there are 5 or later 8 base registers, the base register to use is baked into the instruction, then there's an offset from the base that can be an immediate or register
saurabhg has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
rasterman has joined #dri-devel
<jekstrand>
cwabbott: Is the offset a full 32 bits?
<cwabbott>
jekstrand: yes, I think so
toolchains has quit [Read error: Connection timed out]
gouchi has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
tursulin has quit [Ping timeout: 480 seconds]
<jekstrand>
anholt: Does v3d not support indirects on texture/image arrays?
<anholt>
jekstrand: you could be clever with the second uniform stream, or just doing a global memory access to load descriptors into regs and using that.
<jekstrand>
anholt: You get image descriptors from shader registers?
<anholt>
(you're feeding dwords of descriptor into the texture unit's fifo, it's kinda up to you how you do so but there's definitely a happier path)
<jekstrand>
Oh
<jekstrand>
And you can get those dwords from anywhere?
<jekstrand>
Interesting
<jekstrand>
I'd forgotten about the weird fifo thing
<anholt>
iirc, I haven't pulled up the spec and this is a bit paged out
<jekstrand>
That's fine
toolchains has quit [Ping timeout: 480 seconds]
<jekstrand>
anholt: What I'm hearing is that you usually get them from a uniform and assume a fixed index that you bake into your list of uniforms fed from the compiler to state setup.
<jekstrand>
And that the other option is to feed the texture thing directly and that can come from anywhere.
<jekstrand>
Ah! Here's the non-const-offset path in v3d40_tex
<jekstrand>
So you could do full bindless. Heat
<jekstrand>
*Neat
<jekstrand>
Whether or not it'd be performant is another question. ¯\_(ツ)_/¯
pochu has quit [Quit: leaving]
luc4 has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
luc4 has quit []
oneforall2 has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
oneforall2 has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<Frogging101>
Is there some documentation somewhere about what the packet opcodes do?
ybogdano has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<Frogging101>
I found a Southern Islands programming guide from AMD. I wonder if they have any newer ones?
apinheiro has joined #dri-devel
<airlied>
Frogging101: the basics don't change much
Guest6277 has quit []
<Frogging101>
Yeah, I assumed as much
<Frogging101>
Is this like how the Real™ ISO C standard is behind a paywall, but the drafts are effectively just as good? :p
<airlied>
not really, because it does change a fair bit :-)
YuGiOhJCJ has joined #dri-devel
<airlied>
AMD just don't write that many docs for the new GPUs since we mostly understand it and they provide code
<Frogging101>
Might still be due for an update. The latest one is 10 years old
toolchains has joined #dri-devel
<airlied>
Frogging101: not sure if the benefits for the investment is there yet :-)
<airlied>
it's not like they have those docs sitting around internally afaik
<Frogging101>
ah I see
toolchains has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
jfalempe_ has quit []
toolchains has joined #dri-devel
mvlad has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
toolchains has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
ngcortes has quit [Read error: Connection reset by peer]
danvet has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<jekstrand>
airlied: When using mmap() with a requested address, are there any additional alignment requirements beyond page size?
<jekstrand>
airlied: Like are there cases when mapping across PCIe where you might need a higher alignment?
<HdkR>
I'm still hoping for 4k pagesize and iommu 16k problems not being an issue on Macbooks :)
<jekstrand>
Then again, we don't have a query for userptr...
<jekstrand>
No, we do have an alignment property for host pointer. I'll add one for this, too.
iive has quit [Quit: They came for me...]
fxkamd has quit []
heat has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
<airlied>
jekstrand: most things just use getpagesize()
<airlied>
that's about all you can really do
<airlied>
the bad ones hardcode 4096
jfalempe has quit [Remote host closed the connection]
jfalempe has joined #dri-devel
pcercuei has quit [Quit: dodo]
<HdkR>
I'm a bad one :>
apinheiro has quit [Ping timeout: 480 seconds]
<ccr>
"Data Alignment Cops is filmed on location with the men, women and non-binary genders of alignment enforcement. All suspects are innocent until proven guilty in a code review."