<anarsoul|2>
I'm working on adding atan and atan2 opcodes to nir. What whould be the best place to add lowering for them to avoid adding another lowering pass to each backend compiler?
penguin42 has quit [Remote host closed the connection]
<karolherbst>
anarsoul|2: nir_opt_algebraic if it's not too complex
<karolherbst>
anarsoul|2: I hope you mean like glsl atan, right?
<anarsoul|2>
I would dare to rewrite this amount of C in py
<karolherbst>
I see that nvidia has native tanh btw
<karolherbst>
anarsoul|2: maybe... we should just check if the backends have it and either call nir_atan or emit the opcode...
<karolherbst>
could be the easiest way out
<karolherbst>
just add a "has_atan" flag to nir compiler options
<anarsoul|2>
but is backend already initialized when we translate glsl to nir?
<karolherbst>
glsl_to_nir takes a nir_shader_compiler_options at least
<karolherbst>
let's see if this is also the driver one...
<karolherbst>
yeah.. looks like it
<karolherbst>
NirOptions set inside src/mesa/state_tracker/st_extensions.c, and NirOptions passed to glsl_to_nir
<karolherbst>
so I think you can actually use it this way
<karolherbst>
I think we also do something with this with ffma? mhh
benjaminl has quit [Ping timeout: 480 seconds]
<karolherbst>
maybe that was a patch of mine
<alyssa>
anarsoul|2: the "proper" answer is nir_lower_alu but I don't know if all backends call it
<anarsoul|2>
alyssa: unfortunately not all backends call it, I checked
<anarsoul|2>
that was my first thought
<anarsoul|2>
karolherbst: thanks, it works!
<karolherbst>
though I guess nir_lower_alu would work as well.... mhhh.... annoying.. maybe st/mesa should just call nir_lower_alu?
<karolherbst>
depends if you also want to add fancy optimizations based on atan
<anarsoul|2>
oof, atan2 in utgard isn't really nir or ppir friendly :)
<karolherbst>
what does that mena?
<karolherbst>
it clobbers other registers?
<anarsoul|2>
it should be lowered to temp.xyz = atan2_pt1(y, x); temp.x *= temp.y; result = atan2_pt2(temp.xyz)
<karolherbst>
ohh wait...
<karolherbst>
we have something like that on nvidia as well
<anarsoul|2>
well, I guess temp is a reg and not ssa
<karolherbst>
or at least we had....
gfxstrand has quit [Ping timeout: 480 seconds]
<karolherbst>
is atan2_pt1 maybe something like 1/2π?
<karolherbst>
ehh a * 1/2π I mean
<karolherbst>
mhh.. though doens't make sense if it takes two values?
<karolherbst>
guess it's just something funky
<anarsoul|2>
no, atan2_pt1 produces a vec3
<anarsoul|2>
and yeah, it takes 2 values
<anarsoul|2>
atan_pt2 is common for atan and atan2, it takes vec3 and produces actual result
<anarsoul|2>
for atan2 you also need to multiply temp.x by temp.y
<karolherbst>
I'm sure deep down all of this makes sense
JohnnyonF has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
fxkamd has quit []
fxkamd has joined #dri-devel
<alyssa>
anarsoul|2: what's wrong with translating nir_op_atan2 to that series of 3 ppir instructions?
<anarsoul|2>
alyssa: nothing, we just never had to create an additional ppir_reg in ppir before (currently each nir_reg corresponds to ppir_reg), so some plumbing is necessary
<anarsoul|2>
slightly more work than I originally anticipated
<alyssa>
for lima/gp, since gpir needs explicit load/store register instructions anyway, you can just translate nir load_reg/store_reg to gpir load_reg/store_reg without anything else
<anarsoul|2>
I'd run your lima/gp suggestion through cwabbott if he still remembers gpir details
illwieckz has joined #dri-devel
<anarsoul|2>
honestly, it'd be easier to rewrite ppir from scratch than writing an optimizer for its current version. Yet it's enormous amount of work and I just don't have that much spare time atm
<alyssa>
really?
<alyssa>
ppir looked pretty clean to me
<anarsoul|2>
alyssa: it's hard to transform it
<alyssa>
ah..
<alyssa>
well, nir_legacy will be there for you then :)
<anarsoul|2>
I guess what we lack is nir_builder equivalent for ppir
mbrost_ has quit [Ping timeout: 480 seconds]
<alyssa>
yeah..
danylo has quit [Quit: Ping timeout (120 seconds)]
danylo has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
camus1 has joined #dri-devel
mbrost_ has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
gfxstrand has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
aravind has joined #dri-devel
sima has joined #dri-devel
rz_ has joined #dri-devel
benjaminl has joined #dri-devel
rz has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost_ has quit [Read error: Connection reset by peer]
fxkamd has quit []
ngcortes has quit [Ping timeout: 480 seconds]
a-865 has quit [Quit: ChatZilla 0.17b1 [SeaMonkey 2.53.17/20230610105000]]
<marcan>
I figure if anywhere people here might know: what is the "usual"/"intended" mechanism to avoid racing KMS driver probe/hotplug with things like display managers/X?
<marcan>
we used to have dcp returning from the probe function and initializing asynchronously, which caused problems with gdm. making it synchronous fixed that, but now I ran into a similar thing where the Fedora initial setup GUI tries to start X in the middle of the DCP probe
<marcan>
I always assumed there had to be some udev settle thing but I guess that's not a thing these days... so how are things supposed to be sequenced to avoid these races?
itoral has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
itoral_ has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
<airlied>
marcan: you should just send an updated hotplug even when you find new things connected
ngcortes has joined #dri-devel
<airlied>
are you still discovering connectors at that stage?
<airlied>
or just connected/disconnected?
<Lynne>
emulating raytracing is unvulkan
<airlied>
all of raytracing is emulated
<airlied>
it should have been done in a layer :-P
<Lynne>
if raytracing is emulated, I ask, nay, demand, that the driver exposes multiple queues even if no such exist just to alleviate the overhead of externally synchronized submissions
<Lynne>
it's literally free fps
tzimmermann has joined #dri-devel
<airlied>
I do wonder how much of raytracing could have been done with custom compute shader launch mechanisms
<ishitatsuyuki>
raytracing hardware are invoked from shaders, there's no separate queues
<marcan>
airlied: still discovering connectors because there's no inherent serialization with device probe as far as I can tell?
<marcan>
it gets even messier with the handoff from simpledrmfb, since that means one drm device goes away and another one replaces it
<marcan>
which is fine for TTYs but we need to wait until the "real" device comes in before starting any display servers/managers if we don't want things to go really wrong
<marcan>
the issue here was that X died with "no screens"
<Lynne>
ishitatsuyuki: I meant in general, not specifically for raytracing, it was a spec mistake, and someone from microsoft here happily pointed out d3d12 made no such errors
<ishitatsuyuki>
hm
<marcan>
Lynne: just wait until you discover how much of vulkan will be emulated on Apple hardware :p
<Lynne>
you mean moltenvk or asahi?
<marcan>
asahi
<marcan>
transform feedback? emulated. geometry shaders? emulated. tessellation? depending on what you do, emulated. blending? emulated.
<marcan>
(but at least emulated on the GPU, not like macOS which does half of those things on the *CPU* for OpenGL. yes really.)
alanc has quit [Remote host closed the connection]
<airlied>
marcan: how did you make it sync to fix gdm?
alanc has joined #dri-devel
<airlied>
like you could block on the first kms interaction until you have at least one connector found
<marcan>
the kernel stuff got reworked to block driver probe until all the initial stuff is ready, that seemed to fix it. my assumption was there would be serialization between that modprobe and gdm, which at least on ALARM is the case I believe (since the modprobe happens in the initramfs while gdm obviously runs from the rootfs)
kzd has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
<marcan>
previously it was just going off and kicking the init asynchronously and returning from probe quickly, before the actual DRM device got created
<airlied>
you could do that and then just block on the first open or get resources
<marcan>
but in this case it looks like X isn't being serialized with anything, and I'm not sure we can do much on the kernel side about that? if it doesn't at least wait until the real KMS DRM device is created, it's either going to find simpledrm and get it yanked out from under it a second later, or find no device at all
<marcan>
airlied: not if the DRM device doesn't even exist yet
<airlied>
well when you start modprobing it should kick out simpledrm straight away
<airlied>
but yeah you'd need to create the device to stop something finding no devices
<marcan>
yeah but if nothing is waiting for the probe func to return at all then there's no way to close that race
<marcan>
which seems to be the case here I think
a-865 has joined #dri-devel
<marcan>
AFAIK we do create the device before returning from probe, but clearly X isn't waiting for that
<airlied>
X doesn't know to wait for anything
<marcan>
and if it's not waiting for the module load to complete (which probes synchronously as far as I know), then it's always going to be racy
<marcan>
right, which is why I thought distros had to serialize this somehow
<marcan>
in traditional initramfs setups where you do your thing, wait for it to be done, then pivot to the real root, that point is suitably serializing
<marcan>
but it seems these days systemd does some handoff something something and udev doesn't actually wait for settling in the initramfs or anything, it just all gets parallelized
<marcan>
and now I'm wondering what the serialization point is, if any (or are all systems just broken and just not hitting the race by chance? :p)
<marcan>
I'd say that udev rulefile needs to be updated to ban simpledrm... but under what conditions? doesn't "nomodeset" also break simpledrm since it's KMS?
<marcan>
the problem though is ideally we *do* want simpledrm fallback to work... and again the only way I can think of to make that work is to just wait for all drm drivers to probe
<marcan>
(the idea being that dcp might not exist or fail to probe under some situations, but you still want a dumb GUI to work)
<airlied>
yeah it's the age old problem, of when to take the fallback path as the only path
<marcan>
and then there's the renderonly GPU/kmsro issue to deal with, if DCP probes before the GPU that's also going to break
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
pcercuei has joined #dri-devel
akselmo has quit [Remote host closed the connection]
akselmo has joined #dri-devel
akselmo has quit [Remote host closed the connection]
akselmo has joined #dri-devel
jagan_ has joined #dri-devel
rasterman has joined #dri-devel
itsmeluigi has joined #dri-devel
<mripard>
jani: if it's still relevant, you have my acked-by
<mripard>
(and an additional: yes, finally!) :)
hansg has joined #dri-devel
<tzimmermann>
marcan, it's not really uerspace' job to second-guess the DRM devices; just use whatever /dev/dri/card is there (even if simpledrm isbeing removed shortly afterwards); and if nothing's there userspace should wait
<tzimmermann>
wrt Xorg: just give up, even if Xorg can be made to work correctly, it's probably either a hack or a rewrite of the DRM backend
<emersion>
^
JohnnyonFlame has joined #dri-devel
<emersion>
the renderonly case is a bit shaky though
<tzimmermann>
i think, i missed half of the discussion
JohnnyonF has joined #dri-devel
<emersion>
i don't have good ideas to fix that one, except a list of KMS drivers which are expected to have a separate render node…
<emersion>
in mesa
<emersion>
so that mesa can block for a bit
<emersion>
but that breaks as soon as there's a system with just a display device and no render device
<emersion>
well, s/breaks/times out/, which is not a nice UX
<tzimmermann>
i missed the first half of the discussion. what was the initial problem? there's a render node and the modesetting node comes up late?
<mripard>
instead of a KMS drivers list, can't we use the driver features which shouldn't have DRIVER_MODESET?
mbrost has quit [Ping timeout: 480 seconds]
<emersion>
mripard: the compositor will wait for a display device to come up
<emersion>
so the compositor already waits for the DRIVER_MODESET device to come up
<emersion>
the problem is when the render device is late
pochu has joined #dri-devel
vliaskov has joined #dri-devel
<emersion>
the compositor doesn't know when a KMS device is renderonly or not, the only way to know is to try to create a GL context
<emersion>
at that point, we're in mesa and mesa sees only the KMS device it's been initialized with, but no render node
<mripard>
sorry, I meant DRIVER_RENDER
<emersion>
some systems don't have a render device
<emersion>
we can't stall these systems for 5s just in case a render device shows up later
<mripard>
sure, but if it causes an issue, I'd expect the list of platforms that would run a compositor without a render node to be fairly small
<mripard>
so maybe we can have a list of devices that are known not to have GPU?
<mripard>
and just assume they do
<emersion>
i'd really rather have the contrary…
<mripard>
but I'm not even sure that the driver name is the right tool for that
<mripard>
I'm pretty sure we have drivers that run on both platforms
<emersion>
right
<mripard>
not platforms, but systems with and without GPUs
<emersion>
that's what i was scared of
<emersion>
is devicetree of any help here?
sarahwalker has joined #dri-devel
<javierm>
marcan: how plymouth worked around this was to threat simpledrm as a fallback and only use it without a timeout if modeset or plymouth.use-simpledrm is in the cmdline
<mripard>
emersion: could be, we could link the GPU to the display through the device tree, and even expose that through sysfs if it makes sense
<mripard>
also, we have platforms using ACPI that show up, so I'm not sure it's the proper solution
<tzimmermann>
javierm, OMG i really wish they had at least tried to fix this in simpledrm
<emersion>
iirc sima was not a fan of having the kernel involved
<emersion>
anyways, we can have whatever logic we want in the mesa loader
<javierm>
tzimmermann: yeah... but I guess this is inevitable. When I first replaced {efi,vesa}fb with simpledrm, a lot of stuff broke due efifb behind harcoded all over the stack
<javierm>
tzimmermann: I guess now we have simpledrm instead :)
<emersion>
:/
<javierm>
*being hardcoded
<mripard>
worst case scenario, we use the driver name like you suggested, and if some platforms break we can always use the platform name as a secondary check
<emersion>
is the platform name different when there is no GPU?
<emersion>
or do you mean something else than the KMS device platform name?
<emersion>
there is a mesa MR somewhere to use driver names in the loader iirc
sarahwalker has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, they should have looked whether the information is there (edid, orientation, etc) rather than hard-coding driver workarounds
<javierm>
tzimmermann: yes, I don't disagree but what I tried to say is that user-space will always workaround the kernel if needed
<javierm>
tzimmermann: another example is mutter having a deny list for atomic KMS (i.e: virtgpu due missing cursor hotspots support in atomic)
pochu has quit [Ping timeout: 480 seconds]
<emersion>
;_;
<emersion>
fwiw, in wlroots we have a policy of no workarounds
<javierm>
pq: speaking of which, I see that you are still discussing with vmware folks. But IIRC you just asked for more documentation ?
<tzimmermann>
i'm beginning to look at this as a challenge >:‑)
<emersion>
lol
<javierm>
haha
lynxeye has joined #dri-devel
<sima>
marcan, airlied yeah I think the entire driver load sync is a) busted and b) the bucket is just passed around because everyone says it's too hard to solve
<sima>
emersion, not really getting the full context from scrollback?
<emersion>
sima, discussion about how to solve the renderonly problem, where user-space needs to figure out when a KMS device should be used with a separate render device
<emersion>
we discussed at some point to have a kernel API "is this renderonly?"
<emersion>
but iirc it was deemed user-space's problem to solve
<emersion>
not sure that's enough context
<sima>
emersion, don't you have that already? if it's not supporting kms or not listing any outputs at all it's probably a renderonly drm node?
<emersion>
i mean, i can detect renderonly nodes just fine
<javierm>
but was told that disabling it would break other use cases...
<javierm>
but it was added by commit 25b4e70dcce9 ("driver core: allow stopping deferred probe after init")
<sima>
wtf why are people trying to make optional dependencies work
<sima>
they. just. dont.
* sima
sighs
<javierm>
sima: the worst thing is that Rob added it as a debugging mechanism and then somehow got "promoted" in commit e2cec7d68537 ("driver core: Set deferred_probe_timeout to a longer default if CONFIG_MODULES is set")
<sima>
javierm, ah you're trying to make this a debug hack, that looks reasonable
<javierm>
sima: that was the original intention, see commit 25b4e70dcce9
tursulin has joined #dri-devel
<sima>
this feels like i915 and the preliminary hw support
<javierm>
but commit e2cec7d68537 changed from "this is a debug option" to "make 30 secs the default"
<sima>
every few years you need to rename the knob
<javierm>
for me makes no sense to have this. Either is a best effort or not, you can't have both
<sima>
yeah, and the default must be to reprobe forever
<javierm>
sima: exactly, otherwise you are breaking for instance modules loading
<javierm>
anyways, I got tired to argue and gregkh attitude of we know better than you let me drop that series
<javierm>
*led me to
<sima>
hm gregkh not supporting this is a bit funny, since he's the one that usually insists that the kernel can't tell userspace when it's done probing all the drivers
<sima>
(because it fundamentally can't)
<sima>
javierm, so you just carry the last patch as a fedora fixup?
epony has joined #dri-devel
<javierm>
sima: I don't. I just built-in some drivers to make it work and moved on
<pq>
javierm, yes, I was failing to communicate that I want some vague doc about how input ties to output in order to define how hotspot works. And not a vmware code level spec of what their stack does.
<javierm>
pq: cool, agreed that it would be useful (as said, it took me some time to understand what cursor hotspots and cursor commandeering was or worked)
<mripard>
emersion: I meant the SoC name
<emersion>
ok, i don't know about this, but this sounds more reliable
<emersion>
but potentially a pain to list all SoCs
<mripard>
like I said, only for drivers that support both drivers with and without GPUs
<javierm>
mripard: but even in that case you never known whether let's say v3d will eventually show up for vc4 to use it or fallback to llvmpipe / SW rendering
<mripard>
sure
<javierm>
sima: to wrap up the probe deferral and time out dicussion, IMO the only sensible option would be for user-space to tell the kernel to give up
<sima>
javierm, yeah that might be one option
<javierm>
because only user-space knows when it doesn't have for example more modules to load
<javierm>
and if people want to do it earlier, they can do in the initramfs
<pq>
javierm, happy to see someone at least skim my emails, because usually no kernel dev confirms nor disagrees with my comments so I can't know if what I'm saying makes sense. And it's difficult to comment when you doubt if you are not leading someone in a wrong direction.
<javierm>
pq: I did read the emails in that thread but didn't have anything useful to say :)
<javierm>
I mentioned earlier in that thread that agreed with you about having proper uAPI documentation about cursor hotspots since is not a trivial concept to wrap your head around
<sima>
+1 on that, especially since with cursor hotspot defacto it was just a lot of "hacked until it did what we wanted with Xorg"
<pq>
the last hotspot thread did run off in a tangent, but I mean also other threads like solid_fill and...
<sima>
for some vague notion of "this makes the user feel like the entire thing is more responsive than it really is"
<sima>
pq, imo kms uapi needs at least one ack from a compositor person (especially for the documentation part)
<pq>
sima, that's cool :-)
<pq>
...VKMS stuff
urja has quit [Read error: Connection reset by peer]
camus1 has quit [Read error: Connection reset by peer]
<sima>
pq, note that the no-op out is not entirely true, it does have an impact on locking and sync
<emersion>
ah, but that section linked above is for props only
<sima>
so if you e.g. including a different crtc, even if you change nothing, you'll sync/block against that
<pq>
FYI, I practically never look at the userspace coming with new UAPI, so I might not even notice it is missing.
<emersion>
and there are no links between the 2, because we don't know how to make these in Sphinx
<sima>
emersion, we've not been requiring docs for uapi formally, so this gap is not an oversight
<emersion>
"Each new property introduced in a driver needs to meet a few requirements, in addition to the one mentioned above"
<emersion>
above where?
<sima>
but I think consensus has moved that we should require docs for at least new uapi
<pq>
sima, is there a good reason to sync/block there?
<pq>
rather than just check the actual change comes out to nothing, so drop it
<sima>
pq, the kernel doesn't support dropping only part of a state after validating it
lina has quit [Ping timeout: 480 seconds]
<pq>
you can't drop it before validating?
<sima>
I guess we could do some opt and check the current prop value, and if it matches not get that state
<sima>
pq, we'd need to not acquire the kernel-side state struct to begin with I think
<sima>
everything else is a bit too brittle
<pq>
ok, sounds too complicated for any benefit
<sima>
emersion, maybe an earlier version of that patch added this section in the uapi file?
<sima>
I think a link to the userspace requirements and the test/validation requirements would be good
<sima>
pq, I think checking and not grabbing the state might work without causing issues
<sima>
hm
<emersion>
oh right we also have a test/validation section
<sima>
not sure, because "what is the current value of this prop" works by a) grabbing the current state b) converting the value from kernel state representation to property value
<sima>
so we can't even really do that
<sima>
pq, I guess adding a note that it might lead to oversynchronization across crtc would be good
lina has joined #dri-devel
<sima>
emersion, but yeah more links for all this would be good, and then maybe 2nd patch to put down a formal requirement for new uapi to be documented and that doc being acked by userspace folks?
<emersion>
yeah, sounds good
<emersion>
i need to learn how to do links now :<
<sima>
I think we're essentially there now, and the leftover gaps in existing uapi docs isn't too bad to make this an onerous requirement for a small addition
<sima>
emersion, I have to google it every time too :-P
<pq>
sima, indeed - will you reply on the patch, or should I deliver your greetings?
<sima>
pq, I replied
<pq>
thanks!
epony has quit [Remote host closed the connection]
<alyssa>
if even MSVC supports it I see no reason not to use it
<alyssa>
jenatali: ^
<jenatali>
Sure
<penguin42>
Libreoffice is moving to it
* alyssa
thought it was a C++ only thing
<penguin42>
hmm, I'll admit to not trying it in C, although I see a few examples of it in qemu's generated headers
<pq>
Weston uses it in C in couple of headers. The old style guards are still prevalent.
<pq>
gcc and clang are happy with it
djbw has quit [Read error: Connection reset by peer]
<emersion>
it was rejected in C23
<penguin42>
oh great; for making life too easy?
<emersion>
tbh i never got bitten by a duplicate #ifdef guard
<CounterPillow>
I've never been in a car crash, airbags clearly aren't needed
<penguin42>
emersion: I think I've been bitten by it once in a long time; but I've seen a few close calls - typically where people start out by duplicating a header and modifying it and then forgetting to change the guards
<penguin42>
emersion: Or where there are multiple headers of the same name and people don't agree on a scheme
<emersion>
CounterPillow: not a good argument for thsi discussion
<emersion>
penguin42: yes, agreeing on a scheme is important indeed
<penguin42>
emersion: I think it's rare enough not to need someone doing a global replace, but common enough that it's probably a good idea for new headers or if you're already making a close change
<emersion>
i think standards are important
<penguin42>
fair
<pq>
but if #pragma once is not it, then there is no standard?
smiles_1111 has joined #dri-devel
<emersion>
i personally think the standard way (ifdef guard) isn't too much of a hassle to justify diverging from the standard
<emersion>
but yeah, some people have no problem writing gcc-specific or gcc-and-friends-specific code
<pq>
If you're used to it, sure, but not having to do it and just slap a #pragma once feels sooo goood, and guaranteed to not silently fail causing wtf moments.
<daniels>
emersion: tbf, 'and friends' here does seem to include every compiler I've heard of and many I haven't
<emersion>
i don't really care, i want someone writing a compiler from just the standard to be able to compile my code
<pq>
if the pragma is ignored, the build failures will be very obvious - and frustrating
<emersion>
> Any pragma that is not recognized is ignored.
<pq>
for C? haa haa. for Rust? There is no standrd? What about Go?
<emersion>
Go has a standard
<emersion>
and it's quite short
<emersion>
Rust doesn't have a standard and that's a major flaw
<psykose>
language standard debate hour woo
<emersion>
yeah, sorry about that
* emersion
goes back to writing C
* psykose
hands a + to emersion, just the one
<emersion>
:D
<daniels>
psykose: not a #?
<psykose>
that's four +'s
<penguin42>
emersion: I sympathise, the '#pragma once' seems to be a little unusual in being a bit wider than 'gcc and friends' but as you say still not a standard
<alyssa>
ended up reworking a pile of panfrost blend code, cc'ing you for review since you probably understand it better than I do tbh
<bbrezillon>
alyssa: I'll try to have a look tomorrow
<alyssa>
thx
kzd has joined #dri-devel
Pierce[m] has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
<Pierce[m]>
I thought I'd ask here rather than making an issue on the mesa Gitlab, but where would be the best place to ask about the pvr driver supporting different chips in the same family?
<kisak>
(from not-a-mesa dev) Looking for support on newer hardware than what the driver supports or older hardware. There's a high chance there's a massive pile of technical restrictions on hardware going older.
mbrost has quit [Ping timeout: 480 seconds]
<Pierce[m]>
Same family, so not older or newer per se
<Pierce[m]>
Afaict the driver only supports the AXE-1-16M and GX6250, meanwhile there are a couple RISC-V devices that use the BXM-4-64 and the BXE-4-32
epony has quit [Remote host closed the connection]
epony has joined #dri-devel
smiles_ has quit [Remote host closed the connection]
smiles_ has joined #dri-devel
renfeng has joined #dri-devel
djbw has joined #dri-devel
benjamin2 has joined #dri-devel
benjamin1 has joined #dri-devel
crabbedhaloablut has joined #dri-devel
Guest5642 has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
benjamin2 is now known as benjaminl
cmichael has quit [Quit: Leaving]
CME_ has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
CME has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
epony has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
epony has joined #dri-devel
epony has quit [Remote host closed the connection]
mattst88 has quit [Quit: leaving]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
mattst88 has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<dottedmag>
Is DRM_IOCTL_MODE_DIRTYFB still relevant? I see wlroots does not use drmModeDirtyFB.
kts has joined #dri-devel
<sima>
dottedmag, only if you do frontbuffer rendering, it does nothing when you're pageflipping
<sima>
well, nothing useful :-)
<dottedmag>
sima: Thanks
<sima>
emersion, makes sense to me
mattrope has quit [Remote host closed the connection]
epony has joined #dri-devel
<emersion>
ty
benjamin1 has quit [Quit: WeeChat 3.8]
mattrope has joined #dri-devel
<austriancoder>
alyssa: if you have time it would be nice if you could have a second look at !24054
mbrost_ has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
i509vcb has joined #dri-devel
kts has joined #dri-devel
smiles_ has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
illwieckz has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
Haaninjo has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
eballetbo has quit [Quit: Client limit exceeded: 20000]
<zmike>
anholt / DavidHeidelberg[m]: what do you think about having a couple frames from steam in ci trace jobs?
iive has joined #dri-devel
<DavidHeidelberg[m]>
zmike: the steam overlay? Make sense. (I guess it'll be small)
kts has quit [Ping timeout: 480 seconds]
<zmike>
like the main steam client
<zmike>
it's pretty small
<DavidHeidelberg[m]>
Yeah. I recall some long (long) time ago I feel like I saw some corruption there, so I guess it eould be nice.
<zmike>
unfortunately a lot of issues in steam come from glx
<zmike>
which can't be tested through traces
<karolherbst>
penguin42: I hit a weird fail with device and host timer today, and the CTS complains about this: deviceStartTime: 3577608128229, deviceEndTime: 3469253489
<karolherbst>
and... I have no idea how that can happen...
<karolherbst>
took like 200 runs to hit it once
ngcortes has joined #dri-devel
<everfree>
could anyone point me at where id start trying to figure out why my graphics hardware can do 1920x1080 output but not 1280x1024? (embedded stuff because of course it is). I have run into this before with a different chip and I vaguely remember finding a table of supported dispaly clocks hardcoded into the drm driver source code or something like that. i also remember not being able to figure out how
<everfree>
to properly figure out all the numbers to add a new clock, and im not sure if thats how every drm driver works
<everfree>
the hdmi output is added via an out of tree patch so that's extra fun (i.MX cadence)
<airlied>
everfree: usually there are pll calculations
<airlied>
instead of mode tables
epony has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
benjamin1 has joined #dri-devel
sravn has quit [Read error: Connection reset by peer]
jagan_ has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
pixelcluster has quit [Ping timeout: 480 seconds]
mbrost__ has quit [Ping timeout: 480 seconds]
mattrope has quit [Remote host closed the connection]
benjamin1 has quit []
benjaminl has joined #dri-devel
<benjaminl>
ooh, shader trap handlers sounds like a huge improvement. what I've been doing currently is binary-searching the shader by cutting it off at different points
<benjaminl>
works, but kinda miserable
hansg has quit [Quit: Leaving]
epony has quit [Remote host closed the connection]
<gfxstrand>
zmike: The gallivm patch in the nir register MR
<gfxstrand>
zmike: I think it looks okay but IDK what's going on with thet AOS stuff. Passes CI at least.
<zmike>
probably want airlied for a more comprehensive review
* zmike
-> couchmode
<airlied>
int nae = nir_intrinsic_num_array_elems(decl);
<airlied>
int num_array_elems = nir_intrinsic_num_array_elems(decl);
<airlied>
consistent :-P
<airlied>
you want airlied in a few hours maybe, this airlied isn't useful
Andy[m]1 has quit []
<gfxstrand>
I think we might actually ship this mess today
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<airlied>
okay rb for the gallivm supplied
<karolherbst>
I need a soltuion for initializers on global memory I think...
<karolherbst>
or global global mem in general I think :D
pixelcluster has joined #dri-devel
pixelcluster_ has joined #dri-devel
<gfxstrand>
Yeah...
<gfxstrand>
TBH, I don't think it should be that hard.
<karolherbst>
well
<karolherbst>
the details are hard
<karolherbst>
like imagine you have 5 variables
<gfxstrand>
Biggest problem will be linking
<karolherbst>
and one entry point only accesses three of them
<karolherbst>
and nir happily DCEing the others
<karolherbst>
though
<gfxstrand>
Don't DCE them
<karolherbst>
we could also just bind a buffer per variable
<karolherbst>
okay, but does vtn also ensure they are processed in the same order?
<gfxstrand>
No, let's not bind a buffer per variable unless we really need to
<gfxstrand>
Same order? It should
<karolherbst>
right
<gfxstrand>
The bigger question, IMO, is linking. What happens if there's more than on SPIR-V used to create a program?
<karolherbst>
it doesn't matter
<karolherbst>
it only matters for like fully linked programs
<karolherbst>
maybe spirv-link might need some fixing there, but I think it handles it just fine
<karolherbst>
there is also no way to actually extract the data besides through a kernel part of the final binary
<karolherbst>
"This information is only available after a successful program executable has been built for at least one device in the list of devices associated with program." and other sentences like that
<karolherbst>
(though that's for ctors/dtors)
<tleydxdy>
is there a way to tell which process hold a reference to a dma-buf? I'm running into a problem unloading amdgpu because there's one dma_buf not releases
vliaskov has joined #dri-devel
<tleydxdy>
I did a trace for module_put/get and it's from a dma_buf_export did by Xorg
<tleydxdy>
but xorg is dead already so I wonder what's keeping the dma_buf alive
rcf has quit [Quit: WeeChat 3.8]
pixelcluster has quit [Ping timeout: 480 seconds]
rcf has joined #dri-devel
<karolherbst>
gfxstrand: I think the biggest open qusestion for me atm is, who is responsible for extracting the initializer? Should we just accept our fate and let vtn do it on any entrypoint and provide the full thing or should we have a helper function just for extracting it?
<robclark>
tleydxdy: /sys/kernel/debug/dma_buf/bufinfo has some info, but it looks like not which processes have it imported.. perhaps lsof and/or `ls -l /proc/*/fd/|grep dmabuf`
<robclark>
actually just `lsof | grep dmabuf` would work
<karolherbst>
maybe we have to split spirv_to_nir into two functions... one for general processing with a parsed result which one then can crate nir_shaders from... or something.. dunno
<karolherbst>
might also allow for some reduction of CPU overhead
<tleydxdy>
yeah, I tried listing /proc/*/fd but none of the fd is a dmabuf
<karolherbst>
I suspect almost everything before "vtn_build_cfg(b, words, word_end);" could be done per spirv, and then everything after that is per entry point
<gfxstrand>
karolherbst: We have `nir_gather_explicit_io_initializers()`
<karolherbst>
right.. but what if you have a spirv with like 10 entrypointers, do you do it for every nir containting the same data?
<gfxstrand>
So if we don't dead-code and we know all the SPIR-Vs in have the same global variable order, that should do the trick.
<karolherbst>
or do we have a special case for ctors/dtors?
<karolherbst>
mhhh
<karolherbst>
actually...
<karolherbst>
we could allow spirv_to_nir to create ctor nir shaders and only that would contain the initializer
<karolherbst>
need it anyway if we want to support ctors
<karolherbst>
Initializer execution mode I mean
<tleydxdy>
fwiw the dma-buf have a write fence by drm_sched on gfx queue
<karolherbst>
sooo.. from a cl runtime perspective we could either make clc report if we have Initializers (either constant data or an actual Initializer entry point) and then ask spirv_to_nir to build that one for us, or we just try it always and spirv_to_nir might fail to give one to us...
<karolherbst>
the only constant data case might look weird then as there are no instructions...
<robclark>
tleydxdy, hmm, sounds a bit like amdgpu needs to block unload until scheduled jobs complete or are successfully canceled, because it is deadlocking itself..
<karolherbst>
anyway.. that's kinda the part I'm the most concerned about atm
<tleydxdy>
the fence is signaled tho
<robclark>
sure, that doesn't really matter
<robclark>
hmm, or maybe something in the job cleanup path hangs
<tleydxdy>
also if I don't see Xorg doing dma_buf_release wouldn't that be a problem in itself?
jewins has quit [Ping timeout: 480 seconds]
gabertron has joined #dri-devel
<karolherbst>
gfxstrand: do you think it would be weird to create a nir_shader without any instructions/functions, but only variables + some global init data?
<karolherbst>
though I guess the runtime could also just check if the function body actually has any instructions
<karolherbst>
and like not run it if there isn't any
<gfxstrand>
If we're going to have an init shader, we can make it do the initialization
<gfxstrand>
Then it would have stuff
<gfxstrand>
Or we can do the initialization with a memcpy from the CPU
<gfxstrand>
:shrug:
<karolherbst>
yeah well.. the thing is, those init kernels are expected to run single thread...
<karolherbst>
*threaded
<karolherbst>
but yeah.. we could also just always do it on the GPU side
<karolherbst>
and then from a runtime perspective it would look the same
<karolherbst>
yeah... maybe just do this, it's sucks a little, because you'll probably end up binding a constant buffer which copies the content...
<robclark>
tleydxdy: not sure.. but if Xorg process has exited all it's file handles should be closed.. I trust the kernel process tear-down codepaths a lot more than any driver unload codepath
<karolherbst>
I'll play around with it and see where it leads me to
<robclark>
process cleanup paths actually get tested
<gfxstrand>
karolherbst: A little constant buffer doesn't sound like a bad plan.
<tleydxdy>
yeah, therefore I was thinking something must be keeping the dma-buf alive
<tleydxdy>
but what
<karolherbst>
yeah.. it just fails pointless to copy the exact some content to another buffer on the gpu side :D
<karolherbst>
*feels
<karolherbst>
gfxstrand: how about.. if the Initializer nir_shader has a constant buffer and no instructions, the runtime just uses the constant buffer to init the global one
<karolherbst>
...
<karolherbst>
feels dirty, but...
<karolherbst>
maybe I shouldn't worry about it too much
<karolherbst>
let's see...
<karolherbst>
ahh.. most impls these days report 64k as the max size.. whatever then
<karolherbst>
though they used to report 1G-10G
<karolherbst>
AMD PAL and APP.. whatever
<karolherbst>
I think I'll look into this once I'm done with non uniform work groups :D
mattrope has joined #dri-devel
ultra has quit [Remote host closed the connection]
ultra has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
nehsou^ has quit [Ping timeout: 480 seconds]
nehsou^ has joined #dri-devel
fxkamd has joined #dri-devel
pcercuei has quit [Quit: dodo]
<alyssa>
robclark: what's the current state of a2xx?