macslayer has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
aravind has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
<javierm>
tzimmermann: Ok, went through that thread now
<javierm>
tzimmermann: The problem seems to be that when having both simpledrm and a native DRM driver built-in, simpledrm is probed after the native DRM driver removed the conflicting devices?
<tzimmermann>
yes
<tzimmermann>
that is my understanding
<tzimmermann>
but it should not happen, as i outlined in my reply to the patch
<javierm>
tzimmermann: yes, the aperture infra should call sysfb_disable() from aperture_remove_conflicting_devices()
<tzimmermann>
and AFAIU the i915 device is the primary vga device
<tzimmermann>
otherwise it wouldn't be handled by simpledrm at all
<tzimmermann>
i don't understand what's happening
<tzimmermann>
javierm, is it possible to probe devices in parallel?
<tzimmermann>
such that i915 would probe the native device, while simpledrm probes the platform device?
<javierm>
tzimmermann: I think there's a way to make the probe be async
<tzimmermann>
hyperv_drm seems to use that, but nothing else within drm
<tzimmermann>
javierm, there's a question/idea i have: the platform device has currectly no conenction to the pci device. maybe we should make the platform device a subdevice of the native one?
<tzimmermann>
the native device is available from vga_default_device()
<tzimmermann>
that would allow to model such dependencies
<javierm>
tzimmermann: yeah, the only connection is the aperture. What I don't understand here is why that is not enough
<javierm>
do you think is a race then?
<tzimmermann>
neither do i
<tzimmermann>
no idea
<tzimmermann>
i hope they can further debug it
<javierm>
I think your question is the crux, is sysfb_disable() being called at all?
<javierm>
that would explain why simplerm is probed at least
<javierm>
*simpledrm
<tzimmermann>
and it should unless the i915 device is not the vga default
<tzimmermann>
javierm, do you know if there's a clear order for probing a parent and its subdevices?
<javierm>
tzimmermann: I think there is not, unless device links are used
<tzimmermann>
i see. that looks like something different
lynxeye has joined #dri-devel
<javierm>
so AFAIU that's the only way to give some ordering to the device <-> driver match / driver probe
<javierm>
otherwise is brute force and that's why we have -EPROBE_DEFERRAL
<tzimmermann>
javierm, i think it solves a different problem
donaldrobson has joined #dri-devel
<javierm>
tzimmermann: so what Huacai's patch did is to call sysfb_init() in the subsys init call to register the "simple-framebuffer" device as early as possible
<javierm>
tzimmermann: then the i915 pci device is registered by ACPI, that matches the i915 driver and is probed
<tzimmermann>
ok?
<javierm>
then i915 calls drm_aperture_remove_conflicting_pci_framebuffers() and since is the primary device, it should call calls sysfb_disable()
<tzimmermann>
exactly
<javierm>
so either that does not happen (because is not the primary?) or the simpledrm driver is matched in the meantime
<javierm>
in the window between i915 is probed and the simple-framebuffer device is removed
<javierm>
tzimmermann: could that be possible? Only if using that .probe_type = PROBE_PREFER_ASYNCHRONOUS but neither simpledrm nor i915 set it?
<tzimmermann>
can we move the sysfb code to a later point?
<tzimmermann>
something like: (1) probe pci bus and devices, (2) sysfb, (3) probe pci drivers in modules ?
<javierm>
tzimmermann: it used to be in device_initcall() before Huacai's patch changed to subsys_initcall() and that seemed reasonable to me
<javierm>
tzimmermann: but yes, I think you are correct and we could make it sure that happens after all the real devices have been registered by ACPI, OF or whatever
<tzimmermann>
that would put i915 before sysfb; unless it's a module
<javierm>
probably device_initcall_sync() or even late_initcall()
<javierm>
tzimmermann: yes, and sysfb_init() would then be a no-op because will check if is disabled already
<tzimmermann>
exactly. the sysfb code would return immediately
<javierm>
tzimmermann: can you mention in the thread and propose a patch? And also update the comment that should not only happen after PCI but after all the devices have been registered
<tzimmermann>
well, it's just an idea for now. i'd like them to first debug this further
<javierm>
that makes sense, it will delay a little bit when the simple framebuffer is present but seems the correct thing to do
<javierm>
tzimmermann: Ok
<javierm>
tzimmermann: regardless, I think that you are correct that should happen after device_initcall()
<tzimmermann>
but more generally speaking, we should have a clear idea about the dependencies here
<javierm>
tzimmermann: ideally all drivers should request their memory regions and this handled at the device core
<MrCooper>
Mesa advertises EGL configs which claim RGB10 is renderable with GLES, but is_format_color_renderable says it's not; which is correct?
cmichael has joined #dri-devel
tursulin has quit [Quit: Konversation terminated!]
ficoPRO10 has quit [Ping timeout: 480 seconds]
ficoPRO10 has joined #dri-devel
<javierm>
pq, emersion: any thoughts on https://bugzilla.kernel.org/show_bug.cgi?id=218115? The commit mentioned in the report is 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the primary plane")
<javierm>
which just makes the FB_DAMAGE_CLIPS property to be exposed by the virtio-gpu driver
<emersion>
javierm: my first guess would be a bug in the driver's implementation of FB_DAMAGE_CLIPS?
<emersion>
since i haven't received bug reports for any other driver
<javierm>
emersion: the implementation is very basic, it just does a drm_atomic_helper_damage_merged() to get a merged damaged rectangle
<javierm>
but also I didn't notice any flickering with mutter
<emersion>
does mutter support this prop?
<javierm>
emersion: it does, yes
<emersion>
is your mutter version high enough?
<sima>
javierm, aside, but virtio_gpu_crtc_atomic_flush looks very funny
<javierm>
emersion: I tested to whatever was latest HEAD at the time the patch was posted
<emersion>
the impl in wlroots is very basic as well, basically just forwarding damage
<sima>
it sets output->needs_modeset = true, which virtio_gpu_primary_plane_update looks at
<sima>
but the helpers call atomic_flush _after_ plane_update
<sima>
should probably be in atomic_begin, or I'm just extremely dense rn :-)
<sima>
also not sure whether the early return if there's no damage is entirely correct ...
<emersion>
i haven't found a way to submit an empty damage region via the uAPI
<sima>
flip without any damage
<emersion>
so i just do full damage in that edge case
<sima>
implies full damage
<emersion>
empty damage = nothing changed
<emersion>
full damage = everything changed
<sima>
not how the internals work, see drm_atomic_helper_damage_iter_next() and iter->full_damage in that code
<sima>
but yeah aside from the atomic_flush confusion I don't see anything obviously wrong in the virtio damage handling
<sima>
ah I think I see how the atomic_flush works now, the check does catch the initial modeset for different reasons
<sima>
and from then on the disable sets the output->needs_modeset for the subsequent enable, where the issue was per 3954ff10e06e4
<sima>
so it does work
<javierm>
sima: flip without any damage implies full damage? That's not what all the drivers that use this drm_atomic_helper_damage_merged() helper behave
<sima>
just rather confusion way to implement this :-)
<sima>
javierm, you get a full damage rect if there's none from that helper
<sima>
emersion, I guess we have a bit a perf issue of needless uploads if you just move a plane around :-/
<emersion>
:sadface:
<sima>
so we might need a special "I actually mean no damage, trust me" knob somewhere
<sima>
but not sure how to squeeze that into the current uapi without breaking things anywhere
<javierm>
sima: yes, but returns valid == false
<emersion>
is the no damage case this: FB_DAMAGE_CLIPS=0 and same FB_ID as before?
<sima>
javierm, yeah I think we need a new drm_atomic_helper_buffer_damage_merged which handles this case
<sima>
probably with a defense "upload everything" approach sadly
<sima>
and then roll that out to all the drivers that do damage handling with buffer uploads
<sima>
which is a lot of them :-/
<sima>
oh we have some drivers which do buffer damage with the iter too, so we'd also need a buffer_damage version of that
JohnnyonFlame has joined #dri-devel
<javierm>
sima: yeah, drm_atomic_helper_damage_merged() isn't that smart. jfalempe found that for some drivers with very slow vram copies it could cause perf issues if the damaged rect was almost a full damage
<sima>
actually no, I think all the damage_iter users are correct as-is
<sima>
javierm, yeah if you upload to vram then do the damage_iter and it will be correct, since that needs frame damage
<sima>
but virtio and similar virt drivers need buffer damage
<sima>
javierm, from a few quick greps I think only virtio and hyperv need to be fixed
DottorLeo has quit [Quit: Konversation terminated!]
<pq>
sounds good to me - is anyone still confused about what frame damage and buffer damage are?
<sima>
hm ast cursor maybe also needs buffer_damage
<sima>
pq, I think I clued up on it
<pq>
I could point to the EGL ext spec that explains it with ascii art
<javierm>
pq: which one is that? I would be interested in the ascii art :)
<javierm>
sima: if FB_ID changed then do a full update ?
<sima>
ok gm12u320 just freaks me out
<sima>
has an async worker
<sima>
refcounts the fb
<sima>
but the fb_map is in the plane state
<sima>
probably a use-after-free race :-(
<javierm>
sima: FB_ID changed and no damage rects I mean
<sima>
repaper looks like it should use shadow plane helpers, because it just gets it exactly wrong like everyone did before shadow plane helpers got fixed
<sima>
javierm, FB_ID changed means full damage irrespective of whether you have clips or not
<emersion>
sima, does it?
<emersion>
because all compositors will change FB_ID each page-flip with partial damage
<sima>
emersion, also I think if it hurts we can fix this with minimal history tracking of damage and fb
<sima>
javierm, yeah, but only for the buffer_damage version of iter_init
<sima>
if you do this for everyone emersion will cry
<emersion>
:P
<emersion>
sima, makes sense to me
<pq>
wait, using FB_DAMAGE_CLIPS with atomic flips is useless, the drivers see full frame damage anyway?
<sima>
pq, no
<sima>
it does work, but it's buggy for drivers who need buffer damage right now
<pq>
sima, then I totally misunderstood your: "FB_ID changed means full damage irrespective of whether you have clips or not"
<sima>
which is a very small part of all the drivers that support damage (really just one if you ignore cursor ast)
<sima>
and the quickest fixes for that one driver is to just go full damage
<sima>
pq, yeah, but _only_ for drivers that need buffer damage (which is virtio only I think)
<emersion>
pq, that's just an easy unoptimized thing to do in case the driver wants buffer damage
<pq>
aah
<emersion>
yeah i got scared as well lol
<sima>
javierm, oh correction, vmwgfx uses the iter directly and also needs buffer damage I think
<sima>
so 2 drivers impacted
<javierm>
sima: Ok
<sima>
javierm, and I misread ast-cursor, it should be fine (since the buffer in vram is per-plane, not per-fb)
<javierm>
I'm going to have lunch now but I will try to reproduce the virtgpu issue on a VM with weston and then give it a try to your suggestion
<sima>
yeah same
<sima>
and a walk, it's nice&sunny outside
yyds has quit [Remote host closed the connection]
<javierm>
sima: enjoy!
<emersion>
:D
<sima>
javierm, I guess summarized: if the upload target is per plane or per crtc, then you need frame damage and the current code is ok
<sima>
if the upload target is per-buffer (like with virtio), then you need buffer damage and we have a bug with the current code
<sima>
but it's sometimes a bit tricky to tell from reading driver code
rasterman has quit [Quit: Gettin' stinky!]
<pq>
that summary sounds good to me
<pq>
if it's per-buffer, you also need "buffer age" or similar damage accumulation algorithm
<pq>
soon one might be reinventing Pixman regions
<pq>
a single bounding rectangle can become very pessimistic fast
Daaanct12 has quit [Quit: WeeChat 4.1.1]
<pq>
but also it's not good to carry myriads of rects in a region, sometimes reducing the number of rects at the cost of enlarging damage is beneficial - that's a problem I haven't seen a solution for yet
<pq>
*region struct
rasterman has joined #dri-devel
rasterman has quit []
rasterman has joined #dri-devel
<javierm>
sima: awesome. Thanks again
itoral has quit [Quit: Leaving]
Company has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
<emersion>
pq, Pixman region is actually not so great
<emersion>
mstoeckl had ideas for a better data structure
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
<pq>
cool
<pq>
with union and intersection operations both?
<emersion>
we were mainly interested in union
<pq>
I think Weston intersects damage with opaque region etc. to find out the areas to paint with/without blending.
<pq>
so there might be use for intersection as well, beyond intersecting with a simple rect
<pq>
emersion, is still axis-aligned pieces, or do you go with arbitrary geometry?
<daniels>
that was pretty pathological in a bunch of ways ...
yuq825 has quit []
<pq>
emersion, I totally agree that trying upstream new stuff into pixman is not a... how to say it nicely... plan I'd choose. :-)
<emersion>
yeah :o
<Company>
do you have requirements for float regions?
<emersion>
pq, if you ever need, feel free to ping me for reviews there
<Company>
because all our stuff is floats, but we round to ints so we can use pixman's regions
<emersion>
i don't need floats no
<emersion>
for damage it's not very useful
<emersion>
easy enough to floor/ceil
Ahuj has quit [Ping timeout: 480 seconds]
<pq>
damage can always approximated outwards, opaque regions can always be approximated inwards, and neither in the opposite direction.
<pq>
float regions are probably not too useful until everyone has a display with pixels smaller than they can see :-)
<pq>
for compositor purposes
<Company>
yeah, it's only useful for transforms
<Company>
and if you have too many of them
<Company>
but I guess even with fractional scaling it's only the final one - and if the boxes are 1px larger than required, so be it
<Company>
for opaque regions it's somewhat relevant though
<Company>
because you want maximized windows to cover their full area
<Company>
and not round wrong and end up with the bottommost line not covered
<pq>
Opaque regions can be shrunk freely without causing wrong behaviour. You're right about window regions though.
yyds has joined #dri-devel
jsa1 has joined #dri-devel
<Company>
I meant opaque regions covering the whole window
<Company>
so you can do direct scanout
<pq>
right
<Company>
and with 125% or 175% you have odd prime numbers screwing up everyone's math
Mangix has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
xq has joined #dri-devel
<xq>
heya o/ I'm working on some pretty low level linux program right now, using DRM via ioctls, and i'm searching for a place to drop some questions on that topic. Is this the right place? If so: There's the DRM_PLANE_TYPE_PRIMARY define, and i can query properties, but how do i know which property is the correct one to use?
<pq>
xq, properties are identified by their string names. You look for a specific string name, and you'll find the uint64_t that is used to refer to that property on that specific KMS object.
<xq>
pq: no, i haven't seen that. googling for the docs is kinda impossible i guess :D
<xq>
thanks, this is enough info for me to continue <3
<pq>
xq, maybe consider using libdrm. Things are still very low level even with it.
<xq>
yeah, i know. but libdrm enforces me to link C :D
<pq>
Ok. I don't think you'll find many (any?) examples that didn't use it, though.
<xq>
yeah, i'm just reading libdrm sources for reference right now
<xq>
so i do a DRM_IOCTL_MODE_GETPROPERTY with drm_mode_get_property, check for the name and if it matches, i found the correct property id, which i then can use always(?) to match to the property without having to query again?
<pq>
xq, the property id is (can be) specific to the object id you queried it from, so don't assume the same property id works for all objects that have the same named property.
<xq>
ok
<xq>
because i figured that the property often has several objects assigned
flto_ has joined #dri-devel
<pq>
an object has several properties, and many objects can have the same property (but different value since it's a different object)
<xq>
pq: drivers/gpu/drm/drm_mode_config.c:232 i think i found what i was searching for. so i can basically only rely on the string "type" in userspace for planes
<pq>
MrCooper, eh heh. Well, I'm happy to not need to deal with SHAPE as one cannot simplify that region much, if the launcher looks like what I can guess it might look like.
<pq>
xq, correct, that's what I was trying to say. :-)
<xq>
thanks for the help. now i can finally remove the hardcoded plane ids :D
<MrCooper>
pq: yeah, I'm afraid the only hope there is that Wine is unnecessarily using SHAPE for translucency
<pq>
xq, the same name string usage also applies to enum property values, although many older enums may have numbers defined in the headers too. You can always rely on the strings.
<emersion>
sway doesn't do the SHAPE stuff and it's definitely causing issues
<emersion>
black regions on some game launchers
<pq>
I think black regions are an improvement there.
AnuthaDev has joined #dri-devel
<MrCooper>
emersion: in this case the main issue seems to be Xwayland itself submitting GPU commands for thousands of rects, some of which are just 1x1
<MrCooper>
I guess in principle it would be possible to make this work more efficiently in xserver, for someone who enjoys diving into a huge pile of baroque C code
neniagh has joined #dri-devel
<Company>
GTK3 had some code to turn bitmaps into regions
pekkari has quit [Quit: Konversation terminated!]
<Company>
because some X API needed a region but we only had a bitmap or so
<Company>
you could do the same and turn the region into bitmap
<Company>
they tile the full range and then every tile can be represented either by an actual bitmap, an EVERYTHING/NOTHING flag, run-length encoding and I think those are all the possibilities
<Company>
I might be forgetting one
<Company>
so you could have a region impl that dynamically switches between the options depending on number of rects
AnuthaDev has quit [Quit: AnuthaDev]
<emersion>
sima: so i got my very first dma heap working for vc4. i'm wondering a bit about permissions though
<emersion>
if we are to use it from Mesa, we need to be able to open it?
<emersion>
right now it's only root-readable
<emersion>
is it ok to make it world-accessible by default?
<emersion>
or is it not, and we need to come up with something else to pass the heap FD around?
xq has quit [Quit: Leaving]
macslayer has joined #dri-devel
fxkamd has joined #dri-devel
tursulin has joined #dri-devel
<emersion>
(funny note, seems like allocating a 4k scanout buffer fails with ENOMEM on rpi4 -- 1080p works fine)
<daniels>
cma too small?
<Company>
(noticed yesterday that rpi4 is having issues with ENOMEM if I want to use GL and Vulkan at the same time, but didn't investigate that yet)
xq has joined #dri-devel
<emersion>
yea probably cma too small
<emersion>
daniels, btw if you have thoughts wrt the above, lemme know
<daniels>
hmm yeah, about permissions?
<daniels>
I'd be tempted to give them all the same perms as rendernodes, on the grounds that you can already allocate infinite memory through those ...
<emersion>
yea, but not scanout memory
<emersion>
but yeah
<emersion>
abusing scanout mem is not so different from abusing regular mem
<xq>
pq: thanks for the help, i got it running \o/
fxkamd has quit []
djbw has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
agd5f_ has quit []
agd5f has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
AnuthaDev has joined #dri-devel
ficoPRO10 has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
ficoPRO10 has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
Danct12 has left #dri-devel [A-lined: This user has been AViVA-lined!]
Danct12 has joined #dri-devel
donaldrobson has joined #dri-devel
<enunes>
emersion: I've been looking into rpi4 stuff as well, in particular what to do with that wl_drm usage in the v3dv wayland wsi. are you looking into something similar at the moment?
<enunes>
in particular it doesn't seem like we can delete it without breaking direct scanout of clients as of now. I tried to delete it and, well, it broke
<enunes>
I seem to recall that dma heap was a proposed solution for that
<enunes>
from what I understand so far and a chat with leandrohrb5 , the dmabuf feedback implementation in wayland wsi doesn't magically solve it by itself either
<daniels>
enunes: the dmabuf-feedback stuff won't _magically_ fix it, but it does tell you where the compositor's scanout device is, so you can use that to open it and allocate from vc4
greenjustin__ has joined #dri-devel
cmichael_ has joined #dri-devel
<enunes>
daniels: so that would mean to just replace the wl_drm driver-specific use with another dmabuf feedback implementation right? and other drivers might still need to do the same?
<enunes>
I'm trying to figure out if there's something we can do in the common layer to avoid that, or special cases like v3dv vc4 might still need their own wayland dmabuf feedback code
cmichael has quit [Ping timeout: 480 seconds]
<emersion>
enunes: yes, this is what i'm trying to fix
<emersion>
i think we could pass a scanout dma-buf heap to the common code and let it do the right thing
<emersion>
but yeah, the current behavior of always picking scanout memory isn't very nice
<daniels>
well, all the code to collect all the dmabuf feedback stuff is there in the common code - it looks like all you have to do is take the target_device dev_t from dmabuf-feedback (which we already have in wsi_common_wayland) and pull that into v3dv which currently expects an fd
<daniels>
bcm isn't special here, it's not the only platform where hitting scanout requires you to allocate from the display device
<emersion>
daniels, can't allocate scanout if we're not DRM master
<emersion>
dumb buffers are only for DRM masters
<daniels>
... master? that would imply that only the compositor can allocate, so it doesn't really matter what you do in Wayland WSI
<emersion>
hm, sorry
<daniels>
auth'ed primary node?
<emersion>
not master, authenticated primary node
<emersion>
yeah
<daniels>
right, I thought that got relaxed a few years back so auth was no longer required
<emersion>
and that's not the future
flom84 has joined #dri-devel
<emersion>
the motivation for not relaxing that is that random clients really shouldn't use dumb buffers
<daniels>
(imagine that reads create rather than destroy)
<daniels>
but yeah, I agree wrt heaps being the actual future
<emersion>
hm.....
<emersion>
why the heck does v3d tries to auth then...
<enunes>
it does allocate a dumb buffer currently
<emersion>
yeah but it doesn't need the auth stuff
cmichael_ has quit []
<emersion>
well, primary nodes may not be accessible at all
<emersion>
headless, or systemd-less (systemd will facl the primary node when physically logged in)
frankbinns has quit [Ping timeout: 480 seconds]
jeeeun84135190 has quit []
flom84 has quit [Remote host closed the connection]
<emersion>
hm, it doesn't seem like dumb buffers ever required DRM master…
<emersion>
(or maybe my git-log fu isn't good enough?)
<enunes>
so one thing I'm trying to wrap my head around is, if the dmabuf feedback offers formats known to be good for scanout and a request for allocation, couldn't the common code do the allocation through that and let the compositor handle it?
flom84 has joined #dri-devel
jeeeun84135190 has joined #dri-devel
<enunes>
or does this hit a loop if this would go back to the mesa wsi code?
<daniels>
enunes: right, it can and does
<emersion>
but this calls back into the driver for the actual allocation
<daniels>
yep
<daniels>
the one thing I can see that's missing is allowing the driver to get the device node for the device the compositor is telling it should allocate for
<emersion>
that's not a big deal for v3d, because the display driver will always be vc4
<emersion>
might be for others
Company has quit [Quit: Leaving]
<enunes>
but then it should be able to allocate even in the other device anyway as long as it's linear etc?
<emersion>
except when running (1) on a compositor without wl_drm (2) headless (3) systemd-less
tobiasjakobi has joined #dri-devel
<enunes>
I mean, allocate in the gpu device without the trouble to get to the display device
<emersion>
(because v3d uses dumb buffers and wl_drm auth)
<emersion>
so, no scanout?
glLiquidAcidARB has joined #dri-devel
glLiquidAcidARB has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
<enunes>
if it's a format that can be scanned out and with a modifier understood by the display device / no modifiers, should be scanout-able?
<daniels>
that usually stumbles on either a) the display controller having a stronger pitch alignment constraint which we currently have no way to communicate, or b) the display controller requiring contiguous alloc because it doesn't have S/G IOMMU
<daniels>
I think vc4 fails both
donaldrobson has quit [Ping timeout: 480 seconds]
<enunes>
ok fair, so if we had ways to communicate all these constraints, I suppose it would not make a difference in this case which device we used to allocate then
mripard has quit [Read error: Connection reset by peer]
lynxeye has quit [Quit: Leaving.]
<enunes>
so I guess it is worth it to try to plug the target device coming from dmabuf feedback into the v3dv wsi code, as well as deleting the authentication, and see if we can remove the wl_drm code this way?
mripard has joined #dri-devel
<daniels>
I think that's a great start, yeah
<daniels>
and given that it's so hardware-specific, you could just hardcode a particular alignment if you're allocating for vc4
tobiasjakobi has quit []
alyssa has left #dri-devel [#dri-devel]
greenjustin__ has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
mort_6 is now known as mort_
frieder has quit [Remote host closed the connection]
<i509vcb>
Are EGLSync and EGLSyncKHR the same object type? I heard apparently in EGL 1.5 EGLSyncKHR became EGLSync but I see no evidence of such a thing in the EGL specification?
<i509vcb>
(EGL_ANDROID_native_fence_sync appears to work on plain EGLSync from what I've seen)
frankbinns has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Aura has quit [Ping timeout: 480 seconds]
<emersion>
there are aliases yes
<emersion>
you should see in the Khronos XML
frankbinns has quit [Ping timeout: 480 seconds]
Aura has joined #dri-devel
flom84 has quit [Ping timeout: 480 seconds]
ficoPRO10 has quit []
iive has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
AnuthaDev has quit []
rz_ has joined #dri-devel
rz has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
crabbedhaloablut has quit []
YuGiOhJCJ has joined #dri-devel
JohnnyonFlame has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<sima>
emersion, probably need an allocations service so that a single app doesn't exhaust the heap?
<sima>
allowing everyone is a bit much yolo perhaps
<emersion>
hm
<emersion>
the scope of this work would increase a whole lot
<emersion>
plus it's already free-for-all atm
<emersion>
and also an issue for regular memory as said above
<emersion>
regular GPU memory that is
<emersion>
if we do want an alloc service, logind/seatd seem like a natural place… or maybe the compositor directly
<dj-death>
karolherbst: not sure if you've played much with reading structures from global memory in rusticl
<dj-death>
karolherbst: but looks like like this in OpenCL : VkDrawIndirectCommand param = *(global VkDrawIndirectCommand *)indirect;
<dj-death>
karolherbst: that will result in a load to temporary variable in NIR
<dj-death>
karolherbst: and lower_io is lowering all of that to scratch load/store
<dj-death>
karolherbst: which is ridiculous if you use all those values immediately
<dj-death>
karolherbst: maybe you have some special passes to avoid that kind of stuff?
aravind has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<dj-death>
ah just don't lower_io temp variables
<dj-death>
and use nir_lower_vars_to_ssa instead
heat_ has quit []
heat has joined #dri-devel
<karolherbst>
yeah, lower to ssa first
<dj-death>
somehow not doing anything :(
<karolherbst>
mhhh... weird...
<karolherbst>
maybe throw some load propagation at it as well?
<karolherbst>
but indirects are also kinda... uh... annoying
<karolherbst>
kinda depends on how the shader looks like before io lowering
aravind has quit [Ping timeout: 480 seconds]
Duke` has quit [Ping timeout: 480 seconds]
<jenatali>
dj-death: Sounds like you're missing opt_memcpy?
<dj-death>
jenatali: no, it's there
<dj-death>
looks like I'm getting into those nir_deref_instr_has_complex_use() cases
<jenatali>
:(
a-865 has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
<dj-death>
yeah it's casting
<dj-death>
deref_ptr_as_array too
a-865 has joined #dri-devel
guru_ has quit [Read error: Connection reset by peer]
i-garrison has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
oneforall2 has joined #dri-devel
<jenatali>
dj-death: Last time I looked, that ptr_as_array and casting was inserted by memcpy lowering
<jenatali>
Which, you should be able to get a field-by-field deref copy through memcpy optimization first
<dj-death>
jenatali: thanks, will have another look
apinheiro has quit [Quit: Leaving]
<DavidHeidelberg>
eric_engestrom: as u wrote the priority gitlab-runner wrapper, do you think it would be doable something like "if any other runner won't pick job in 30 seconds, use this runner" wrapper?
* DavidHeidelberg
moves to #freedesktop w/ this discussion
aradhya7 has quit [Quit: Connection closed for inactivity]
YuGiOhJCJ2 has joined #dri-devel
YuGiOhJCJ has quit [Read error: Connection reset by peer]