<anholt_>
note that that MR doesn't include opt_algebraic gutting or copy prop removal.
<tarceri>
I think one of the things was I needed to handle things other than just mat4 or vec4
<tarceri>
I think there was a least 1 regression in shaderdb from that
<anholt_>
I've got a couple listed there.
pcercuei has quit [Quit: dodo]
<anholt_>
oh, something I was thinking about as we make progress on this: since nir_opt_algrebraic is good at matching the biggest pattern, I think some of the variants you have dealing with 1.0s being optimized away should end up being unnecessary once we have GLSL optimization deleted.
paulk-bis has quit [Ping timeout: 480 seconds]
<tarceri>
I hope so because I think there were more corner cases
<tarceri>
Although I think nir might have been getting to them first also
<tarceri>
*nir opts
<alyssa>
~irregular reminder that alu is cheap and memory is not~
<alyssa>
(so I'm good with small shaderdb alu count regressions if they mean shorter compile time, etc)
<tarceri>
It's really a massive chain of todos with these things. You try to remove one pass and you need to remove another handful, fix ten year old bugs, and speedup NIR passes :P
<alyssa>
Lol
<alyssa>
I want a graph of "line count of src/compiler/glsl/ over time"
<anholt_>
finding that glsl ir opt code I wrote 13 years ago is still load-bearing is a little distressing.
<alyssa>
scaled appropriately and captioned "not stonks"
<zmike>
ideally zoomed in until it has become pixelated
<tarceri>
I'm not sure if it will ever get there but ideally GLSL IR would get to a point were its just a small layer between ast and nir. Being able to to the gl compile calls in NIR would be great rather than having to wait until link time.
nchery has quit [Ping timeout: 480 seconds]
<alyssa>
anholt_: italove was working on that AFAIK, not planning to work on it myself unless italove gets stuck
<alyssa>
anholt_: Oh, I see you added patches yourself
<alyssa>
r-b'd
aravind has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
alyssa has quit [Quit: leaving]
stuart has quit []
nchery has quit [Remote host closed the connection]
<mi6x3m>
kj, aha!! important piece of intel, thank you
<mi6x3m>
let me check
JohnnyonFlame has quit [Ping timeout: 480 seconds]
paulk-bis has quit [Read error: Connection reset by peer]
paulk has joined #dri-devel
<tzimmermann>
javierm, thanks for the review
Adrinael_ has joined #dri-devel
<tzimmermann>
javierm, i've seen the virtio patch. but it seems unrelated to actual nomodeset option
<javierm>
tzimmermann: not quite, the goal of the patch is to disable modsetting while still keeping the rendering part
<tzimmermann>
javierm, IIRC there was some discussion about the semantics of nomodeset when we merged it. and IIRC we decide to ignore those corner cases then. that's back on the table now, i guess
Adrinael has quit [Ping timeout: 480 seconds]
<tzimmermann>
TBH, i think i'd prefer a module option here.
<javierm>
tzimmermann: yeah, we didn't add nomodeset handling to DRM only drivers (i.e: that have DRIVER_RENDER but no DRIVER_MODESET)
<tzimmermann>
let me type up a reply mail
<javierm>
tzimmermann: a separate option than virtio-gpu.modeset then?
<tzimmermann>
no
<tzimmermann>
let me take a look. if there's already such an option, we wouldn't need another
<javierm>
tzimmermann: thanks for your answer. I agree with your thoughts
<javierm>
tzimmermann: I'll let others decide what should be done for this particular driver, but we should think about the 'nomodeset' and modules 'modeset' params semantics and try to make it consistent
frieder has joined #dri-devel
<tzimmermann>
javierm, wasn't that super complicated? IIRC we couldn't outright remove pre-existing modeset parameters because too many blogs, comments, guides refered to it?
aravind has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: I didn't mean to remove 'nomodeset' or modules 'modeset' but just make the behaviour consistent
<javierm>
i.e: make all drivers to fail probing for example
aravind has joined #dri-devel
<tzimmermann>
javierm, we do this for modeset, don't we?
<tzimmermann>
they all fail registering/probing
<javierm>
tzimmermann: as mentioned in the thread at least i915 and nouveau only disable the KMS part IIUC
<javierm>
so I wonder if in that case the aperture helpers would kick the firmware-provided framebuffer anyways
<tzimmermann>
nouveau apparently doesn't register
<vsyrjala>
iirc i915 becomes a dead husk if you use that
<tzimmermann>
i915 doesn't register either
<tzimmermann>
yeah
<tzimmermann>
so do all the other drivers with modeset
<tzimmermann>
that's why i called it repurposing modeset
<tzimmermann>
virtgpu would then register, but as render-only driver
<javierm>
tzimmermann: right, sorry my bad. I just grepped the drivers that weren't doing a "return" after the check
<tzimmermann>
no worries, we've been fighting with the semantics ever since
<tzimmermann>
i guess we could do this for other drivers as well, if we convince maintainers
<javierm>
but I see now that both drivers check later if use_kms or nouveau_modeset respectively and return with no success
<tzimmermann>
that would be i915, nouveau, radeon
<tzimmermann>
i just don't know if anyone cares. i'm not even sure why virtio needs that option
<vsyrjala>
i915 already has a i915.disable_display. though all that does it claim all connectors are disconnected
<tzimmermann>
and a few other drivers only support modesetting (ast, mgag200, bochs)
<vsyrjala>
that's as far as we're willing to take it in i915. anything else would be madness when the display hardware is still actually present
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<vsyrjala>
well, i guess we could take it a notch further by rejecting all kms ioctls, if that were possible. but we still need to initialze the full kms stuff internally
<tzimmermann>
vsyrjala, i tend to agree. i don't see the benefit of that option; besides 'because we can'
<javierm>
tzimmermann: yeah, those allow to disable modsetting (which is really disable register / probe) and to override the global 'nomodeset' param
<javierm>
tzimmermann: it seems the goal is to reduce the attach surface since ChromeOS doesn't use virtio-gpu for KMS, only for rendering
<javierm>
*attack
<javierm>
tzimmermann: anyways, if all drivers fail to probe with either 'nomodeset' and the modules 'modeset=0' then I'm a happy camper and the semantics are consistent
<javierm>
even if the naming is confusing :)
<tzimmermann>
javierm, i've send an email about the real-world use of the option.
<digetx>
tzimmermann: robclark already said explicitly on the ML that the config option is for security reasons and nothing else
<digetx>
but yes, I suggested that the commit message should be improved
<tzimmermann>
digitx, did he. i see two mails from rob. neither speaks of security
<javierm>
tzimmermann: yeah, could be. I guess in practice though most people will just use 1 or 0 for this param, or just the global 'nomodeset'
<javierm>
tzimmermann: probably if you remove the per-module parameters nobody will even notice :)
<tzimmermann>
digitx, i didn't see this before. thanks
<tzimmermann>
it's still really vague AFAICT
<tzimmermann>
those modeset ioctls are DRM-wide. so why isn't this a DRM-wide option?
<javierm>
tzimmermann: that's a very good point. It would make more sense to have a Kconfig option to just disable KMS then
<javierm>
so that drm_core_check_feature(dev, DRIVER_MODESET) will always return false for example
<digetx>
perhaps it could be a DRM-wide option as alternative; it's a global vs per-driver option preference, the global variant should work in Rob's case
<javierm>
digetx: yeah, because the only DRM driver that will be used in the VM will be virtio-gpu anyways
<digetx>
actually, not true :) there is option with passthrough gpu + virtiogpu
<digetx>
and Google uses that case it too
<javierm>
digetx: ah, so they pass-through the host GPU and use the native DRM driver in the guest? I thought that they used the virtio-gpu native contexts support and that only used the mesa driver in the guest
<javierm>
but still virtio-gpu to tunnel the native DRM driver ioctls over virtio
<digetx>
there are multiple use-cases, depending on product; pass-through second host GPU + virtio-gpu is one variant, solely native context virtio-gpu is another
<javierm>
digetx: got it
kts has quit [Quit: Konversation terminated!]
kzd has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
fab has quit [Quit: fab]
Major_Biscuit has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #dri-devel
cheako has joined #dri-devel
kts has joined #dri-devel
phasta has quit [Quit: Leaving]
MajorBiscuit has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
alanc has quit [Remote host closed the connection]
ice9 has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
aissen_ has quit []
aissen has joined #dri-devel
<llyyr>
I get `amdgpu: os_same_file_description couldn't determine if two DRM fds reference the same file description.` when starting any opengl application on Mesa built from the main branch, looking at the git logs there were some related changes to src/egl and it's probably also related to my issue #8394
<llyyr>
`mpv --no-config` can reproduce this, goes away with `mpv --no-config --gpu-api=vulkan`
pcercuei has quit [Read error: Connection reset by peer]
<emersion>
with a recent-ish kernel?
pcercuei has joined #dri-devel
<llyyr>
6.1.2
<llyyr>
6.1.12*
<emersion>
yeah
<emersion>
do you have the allow-kcmp Meson option set?
<llyyr>
it's set to auto
<emersion>
it's supposed to be enabled then…
<llyyr>
I just copied the options from my distro (tumbleweed) and set `Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec` because they don't build with those anymore
<llyyr>
also it works fine on 23.0.0
<llyyr>
!13422 is the only related change that's on the main branch but not on 23.0.0
probablymoony has joined #dri-devel
heat has joined #dri-devel
<digetx>
tzimmermann: you've re-added (likely accidentally) the wrong conflict resolution for drm-shmem to dim's rerere, don't you mind if I'll revert it?
<tzimmermann>
digitx, ok
<tzimmermann>
i picked the dma-lock patch and the export_symbol_gpl patch IIRC
yuq825 has left #dri-devel [#dri-devel]
<tzimmermann>
digetx ^
<vsyrjala>
digetx: is a fix coming soon, or do we need to think about a revert?
moony has quit [Ping timeout: 480 seconds]
<mripard>
marex: I'm sorry, I did my best
<robclark>
javierm, tzimmermann: for displaying guest windows there is a sort of "wayland proxy" that proxies the surfaces/fences to host compositor so kms in the guest is unused.. I'll respin the patch with a better commit msg after breakfast
<jani>
vsyrjala: is it broken on drm-misc-next too, or is this just about wrong conflict resolutions?
<jani>
I mean the conflict resolution could be wrong even if it builds
<jani>
idk
<robclark>
digetx: re: #ifdef vs #if IS_ENABLED() in the driver struct, #ifdef is already used (for example, for debugfs) nearby, so sticking with #ifdef there seemed more consistent.. but agree with your other comment about better commit msg
<vsyrjala>
jani: not sure. i presumed it's broken in general
<digetx>
vsyrjala: jani: that is a general issue, I'll try to fix it asap; if it will be taking too much time, then will be good to revert
<javierm>
robclark: I see. That's the virtio-wayland thing, right?
<javierm>
robclark: and I understood that was unused, it was just about compile vs runtime option
<tzimmermann>
jani, vsyrjala, digetx, i'll take a look
<digetx>
vsyrjala: jani: that's a warning about a missing resv lock; the dma-buf locking rules became stricter since 6.2 kernel and they are enforced for shmem in the offending patch
<digetx>
robclark: ack
<tzimmermann>
digetx, vsyrjala, jani, i'm going to revert 67b7836d4458 ("drm/shmem-helper: Switch to reservation lock")
<digetx>
tzimmermann: okay, that perhaps the best option; will fix it without rushing and we'll try again
<tzimmermann>
digetx, from what i can tell, the _pin code never acquires the lock
Zopolis4 has quit []
<tzimmermann>
and that is probably not hot-fixable
<digetx>
the shmem shouldn't get the pin lock, it should be a lock missing in other place for dma-buf exporting code path
<jani>
tzimmermann: eyballing the commit, does that revert also help with the conflict?
<jani>
*eye
<digetx>
tzimmermann: it's not a problem for the current drivers as they don't rely on the new resv locking rules
gawin has joined #dri-devel
<tzimmermann>
digetx, exactly. but not just there. enything that calls drm_gem_object_funcs now needs to hold that lock first
<tzimmermann>
jani, we'lkl see
<digetx>
tzimmermann: I've the same thought, will see where the lock is missing
<tzimmermann>
jani, if i post a revert, how do i get your CI to test it?
<tzimmermann>
digetx, you mention that you are working on a fix. do you want to try first?
<robclark>
javierm: yeah, virtio-wl (although I'd like to see it replaced w/ a virtgpu-wayland context type so we can get rid of a downstream guest kernel driver.. but no one has had time for that yet)
Haaninjo has joined #dri-devel
<robclark>
javierm: I'm in favor of a compile time option because it is easier to reason about.. which is important when you have four different host kernel LTS branches and three different guest kernels for different guest OSs (plus beta+stable and CrOS-LTS version branches for each of those)
<digetx>
tzimmermann: I already reproduced the reported warning, working on it, though also busy with other things in parallel
<javierm>
robclark: yeah, it's harder to re-enable it by mistake
<robclark>
right
<MrCooper>
llyyr: git bisect would probably be easiest to find what broke it for you
fab has joined #dri-devel
<jani>
tzimmermann: Cc: intel-gfx, ensure it applies on top of drm-tip, that's all
vliaskov_ has joined #dri-devel
<jani>
tzimmermann: in the more general case, if you post a series, also ensure you Cc the complete series
lemonzest has quit [Quit: WeeChat 3.6]
vliaskov has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
bgs has joined #dri-devel
lemonzest has joined #dri-devel
JohnnyonFlame has joined #dri-devel
kzd has quit [Quit: kzd]
fab has quit [Quit: fab]
pallavim has joined #dri-devel
kzd has joined #dri-devel
Duke`` has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
fab has joined #dri-devel
fxkamd has quit []
frieder has quit [Quit: Leaving]
sarnex has quit [Quit: Quit]
sarnex has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
smiles has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
digetx has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.6]
<marex>
mripard: let's see what happens now
digetx has joined #dri-devel
macromorgan has quit [Quit: Leaving]
nchery has joined #dri-devel
<karolherbst>
uhm.. llvmpipe uses 32 bit pointers when doing a 32 bit build, right?
<airlied>
if a tree falls in the woods...
<HdkR>
One would hope so
<karolherbst>
yeah.. just noticed today, that llvmpipe always claims to be 64 bits, so CL is probably broken in 32 bit applications :)
<airlied>
if a tree falls in the woods...
<airlied>
:-P
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<airlied>
I wonder where you'd find a 32-bit CL program in the wild
<karolherbst>
wine
srslypascal has quit [Ping timeout: 480 seconds]
<karolherbst>
but also apparently somebody uses it on a 32 bit host...
<airlied>
for wine wouldn't it need an application to use it?
<karolherbst>
sure
<karolherbst>
already got bugs like that
<airlied>
I wonder where you'd find a 32-bit CL program in the wild
<airlied>
for Windows
gawin has joined #dri-devel
<karolherbst>
yeah
<karolherbst>
I fixed a bug recently for that
<airlied>
but maybe there are a bunch
<karolherbst>
it's windows
<karolherbst>
applications were 32 bit only for a looong time
<airlied>
yeah I'm just more surprised there's any CL apps
<karolherbst>
nice.. it's image arguments which are broken
junaid has joined #dri-devel
mvlad has quit [Remote host closed the connection]
djbw has joined #dri-devel
dwlsalmeida4 has quit []
gawin has quit [Ping timeout: 480 seconds]
dwlsalmeida has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<dwlsalmeida>
airlied Lynne Hey there, I am trying to cook up some initial vulkan video vp9 support in Mesa following along your footsteps. I have an AMD box which I can test through RADV. Do any of you have any documentation on the firmware interface? I am taking cues from radeonsi, but sometimes I miss a more unambiguous source.
ybogdano is now known as Guest6190
ybogdano has joined #dri-devel
<airlied>
dwlsalmeida: no the radeonsi interface is all the info available
macromorgan has joined #dri-devel
<airlied>
dwlsalmeida: the interface is usually sane until you have to work out how references work
<dwlsalmeida>
airlied I noticed this was a problem with AV1 as well, IIRC? something about it being hard to uniquely identify a frame
<dwlsalmeida>
in v4l2 there's timestamps, so that was easy over there
<airlied>
yeah the fw appears to write some frame indexes into the context buffers, and gets upset when they are different
<airlied>
it was also a bit painful for h264, but more around how vulkan DPB mgmt is explicit
<airlied>
I thought av1 was the same problem, but it was slightly different
<marex>
mripard: hey, so, I spent a while communicating with jagan_ now and I think there is a cyclic dependency between DSIM probe and DSI83 bridge probe
<marex>
mripard: if no dsi_host available, DSI83 does -EPROBE_DEFER and that's the end
<dwlsalmeida>
airlied Btw this confuses me -> void *render_pic_list[32];
<dwlsalmeida>
I assume this comes from h264 (i.e. 16 x 2 fields), and just carries over to the other codecs? because VP9 only has up to 8 frames as references at a time
<dwlsalmeida>
Also would you mind a quick review once this progresses a bit more? I can open up a MR same as you did
<marex>
mripard: at the same time, if DSIM bridge/host attemps to look up bridge in its .probe() callback, it fails with EPROBE_DEFER too, because the bridge driver didn't probe yet
<marex>
mripard: so, there is a cyclic dependency between DSIM host and DSI83 bridge , since they both depend on each other at .probe() time
<marex>
mripard: it seems that is why jagan was going on about the .attach time bridge look up all the time
<DemiMarie>
airlied: totally undocumented firmware interface? That sucks.
<DemiMarie>
I wonder if anyone has tried fuzzing the firmware.
<DemiMarie>
marmarek: this kind of stuff is why I am nervous about GPU security
<airlied>
dwlsalmeida: render_pic_list is a vaapi ism anyways
<airlied>
but yes it's sized for h264
<dwlsalmeida>
airlied do you happen to remember where this number comes from? -> #define RDECODE_VP9_PROBS_DATA_SIZE 2304
<dwlsalmeida>
The actual probability table is 2040 bytes long
<dwlsalmeida>
I do vaguely remember this number 2304 from somewhere though ...
iive has joined #dri-devel
JohnnyonFlame has joined #dri-devel
Zopolis4 has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
<airlied>
dwlsalmeida: is it sizeof struct rvcn_dec_vp9_probs_s ?
gawin has joined #dri-devel
srslypascal has joined #dri-devel
<karolherbst>
airlied: seems like your llvmpipe pointer fix actually breaks 32 bit stuff now
<karolherbst>
uhh.. maybe there are just more bugs around somewhere...
<mareko>
tarceri: what does gl_nir_link_glsl/spirv need nir_link_opt_varyings for? can we move it after gl_nir_link_glsl/spirv?
gawin has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<agd5f>
DemiMarie, if you have specific questions we can ask the firmware teams.
Jeremy_Rand_Talos_ has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<agd5f>
er dwlsalmeida ^^
ybogdano has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
gallo72 has joined #dri-devel
stuart has joined #dri-devel
nchery has joined #dri-devel
<dwlsalmeida>
airlied agd5f it isn't, that's why I am asking. I think I will run a frame through vaapi on my machine to dump the stuff from radeonsi and have a look, it will probably be a good starting point, but I will keep your suggestion in mind if I am totally stuck thanks a lot
nchery has quit []
<airlied>
dwlsalmeida: normally I just break on the get_*_msg functions and finish them and stare into the result structs
<airlied>
dwlsalmeida: for those buffers though it's normally just a matter of not caring or understanding
<airlied>
the fw wants what the fw wants, so you give it 2304 + 256
ZenWalker has quit [Ping timeout: 480 seconds]
<airlied>
the 256 is for segment data
<airlied>
so it's likely the hw just left some extra space or aligned something
ybogdano has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos__ has joined #dri-devel
fab has quit [Quit: fab]
Jeremy_Rand_Talos_ has quit [Read error: Connection reset by peer]
agd5f_ has joined #dri-devel
nchery has joined #dri-devel
ZenWalker has joined #dri-devel
ybogdano has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Zopolis4 has quit []
<anholt_>
nir_lower_precision so far increases freedreno reg pressure by 1%, instr count -.14% Now to go write unit tests and see if it's actually working as intended.
YuGiOhJCJ has joined #dri-devel
agd5f has joined #dri-devel
<tarceri>
mareko: no you want to remove varying before linking uniforms etc because you can eliminate more of the shader and uniforms