<dj-death>
pq: I think we have tests in piglit to verify yuv imports
<pq>
dj-death, are they testing also the GL_TEXTURE_2D path?
<pq>
the only change in weston is that it switched from GL_TEXTURE_EXTERNAL_OES to GL_TEXTURE_2D.
<dj-death>
how do you give the yuv format through GL_TEXTURE_2D?
<pq>
via the EGL import, just like any other format
<pq>
this is about importing dmabuf as EGLImage and bingind that as GL texture
JohnnyonFlame has joined #dri-devel
<pq>
in GL ES v2/3, if that matters
ahajda_ has joined #dri-devel
KunalAgarwal[m] has left #dri-devel [#dri-devel]
<javierm>
tzimmermann: hi, I noticed that you sent a PR for drm-misc-next, are you planning to send one for drm-misc-fixes this week too ?
<javierm>
tzimmermann: or that's for mripard ?
<tzimmermann>
mripard does fixes
MajorBiscuit has joined #dri-devel
<javierm>
tzimmermann: got it. Didn't know if you folks alternate it or handled different branches
pixelclu- has quit []
pixelcluster has joined #dri-devel
KunalAgarwal[m] has joined #dri-devel
rasterman has joined #dri-devel
<KunalAgarwal[m]>
Hey. I Hope now msg is visible to all users
pcercuei has joined #dri-devel
<pq>
KunalAgarwal[m], it is, welcome!
<KunalAgarwal[m]>
ahh trying since 3 days to get recognised here.. probably some matrix issue :-)
<javierm>
KunalAgarwal[m]: glad that it worked :) welcome
<pq>
yes, I hear matrix does not make it easy to get through, and we also suffer from occasional quit/join floods when every user of some popular matrix relay disconnects.
Daaanct12 has joined #dri-devel
dschuermann_ has left #dri-devel [#dri-devel]
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
<digetx>
hi, do anyone know why async plane commits are only available for the cursor plane? is any specific reason why async commits couldn't be exposed to all planes? perhaps nobody cared yet? it's a one-line change to expose the async updates universally and with that I can move video plane around screen without a huge lag
moony has joined #dri-devel
Daaanct12 has quit [Ping timeout: 480 seconds]
dschuermann has joined #dri-devel
<pq>
digetx, why would you get a huge lag to begin with?
<digetx>
because there is a need to wait for vblanks for synchronous updates
<pq>
but why does that cause a *huge* lag? The lag is only at most one refresh period.
<pq>
are you not accumulating the movements between flips, and instead trying to move more often than the refrehs rate?
<digetx>
for example, if you have a touchscreen, then your finger touch inputs are queued and then you move the plane and it moves slowly in comparison to your finger
<pq>
there is some rationale for cursor plane needing to be updated many times per refresh cycle to minimize the hand-eye latency with mice, and cursor planes might be backed by special hardware that allows that, while other planes might not allow that, on hardware where cursor planes are special.
<pq>
digetx, does that not just mean that your program is trying to move the plane on every touch input event, instead of accumulating input event until the next flip?
<digetx>
yes and I can't change it
<pq>
digetx, async plane updates are useful for reducing latency further when your latency is already capped at one refresh cycle.
<pq>
that's very unfortunate
<digetx>
okay, so async updates aren't exposed universally because h/w capabilities differ and we want to have a common behaviour for all drivers
<pq>
hardware could differ, yes
jljusten has joined #dri-devel
<digetx>
perhaps we could have a per-plane property then that would allow to enable async updates
<pq>
perhaps
<emersion>
atomic KMS doesn't have ASYNC yet
<digetx>
that's what I'm looking to change
<MrCooper>
it could only make a difference in this case by introducing tearing, is that really what you want?
<digetx>
it depends on h/w
<pq>
it cannot, the UAPI must define whether it tears or not
<MrCooper>
without tearing, plane updates can be accumulated until a few milliseconds before start of vblank, so it hardly incurs any latency
<pq>
MrCooper, indeed, the use case here is just to work around a broken KMS application in the kernel.
<MrCooper>
I mean accumulated in user space
<pq>
ideally in userspace yeah, but digetx says he can't, so he's looking to do the same in the kernel
<MrCooper>
if that's not possible, how is it possible to make use of KMS API which doesn't exist yet?
<digetx>
plane commits are armed only on vblank at least by some (most?) h/w and you can commit asynchronously, so there won't be tearing in this case
<pq>
good question :-)
<MrCooper>
digetx: sounds like amending commits, not async commits
<digetx>
yes, it works like amending commits in my case
<daniels>
dj-death: fwiw we do select TEXTURE_OES if it’s declared to be external-only via the format extension - so here it’s being declared as non-external-only (i.e. 2D is OK), but then silently failing anyway, which is definitely an iris/Gallium bug
<MrCooper>
in the KMS API, async means "not synchronized to display refresh"
<digetx>
well, the async cursor updates aren't synchronized and cursor plane is also a regular plane in my case, so I don't feel the difference
<MrCooper>
per above, there are no async cursor updates yet in the atomic KMS API; legacy cursor updates are emulated by amending atomic commits
<MrCooper>
(by some drivers)
<digetx>
alright, I see the difference now, so we may want the "amend-commits" per-plane property then.. but what h/w could do a real async plane updates?
<MrCooper>
some HW can do real async updates for the HW cursor, not sure any can for overlay planes
<digetx>
ok, thank you all
aravind has joined #dri-devel
<linkmauve>
I’m trying to make mpv’s vaapi buffer directly importable on planes, for that I’m updating its linux-dmabuf wayland protocol from version 2 to version 4, and now it looks like it’s completely missing synchronisation during scanout.
<linkmauve>
If I make Weston stop using planes and fallback to GL compositing, synchronisation works properly.
<dj-death>
daniels: yeah, I'm not familiar enough with the state tracker
<dj-death>
daniels: I can't why we couldn't do it
<linkmauve>
The only difference here is that I’m now importing with modifiers instead of with implicit modifiers.
<linkmauve>
The behaviour I see is some kind of tearing where either the top part or the bottom part alternates with a few frames before.
<daniels>
that's presumably mpv's Wayland backend being broken, given it's only about 2 weeks old
<linkmauve>
That’s what I’m working on. :)
<daniels>
:)
<linkmauve>
But it not being broken when compositing would rather point to Weston doing something wrong, wouldn’t it?
<digetx>
sounds like va doesn't know that the buffer is in use by display plane and then the buffer is re-used by va
<emersion>
implicit sync is supposed to prevent this
kts has joined #dri-devel
<MrCooper>
implicit sync can't do anything about premature reuse
mclasen has joined #dri-devel
<MrCooper>
daniels: you mean mpv's support for the linux-dmabuf v4 protocol is 2 weeks old? The Wayland backend per se has been around quite a bit longer :)
<linkmauve>
MrCooper, no, support for the linux-dmabuf v4 protocol is half an hour old, and only on my laptop.
<linkmauve>
v2 (using implicit modifiers) is the current version.
<daniels>
and v2 - where it actually has to manage buffer lifetime - is as said very new
<linkmauve>
(Also that’s v1 version 4 or version 2, but nitpick.)
<MrCooper>
well I got "version 4" from you :)
<javierm>
tzimmermann: I noticed that had I used dim cherry-pick instead of git cherry-pick, I would had catched that your follow-up fix was missing from the set
<daniels>
linkmauve: not necessarily no. scanout means that not only are the buffers held longer, but as KMS doesn’t hold a read reference during scanout, it means you can observe tearing if clients don’t properly wait for release.
<linkmauve>
MrCooper, the old vo_wlshm is old and doesn’t do anything proper, vo_gpu uses GL but supports Wayland, and the new vo_vaapi_wayland uses dmabuf, vaapi, presentation feedback, no OpenGL, etc.
<lynxeye>
linkmauve: When weston puts the buffer on a plane, it holds onto it longer even after the client attached a new buffer, as it may be still active for scanout. Maybe you are not properly waiting for the buffer release event?
<linkmauve>
daniels, lynxeye, thanks I’ll have a further look. :)
* lynxeye
should type faster, or just let daniels do the talking
<linkmauve>
:D
<MrCooper>
vo_vaapi_wayland sounds nice
itoral has joined #dri-devel
<MrCooper>
I was under the impression vo_gpu was also using presentation feedback, wasn't it?
<linkmauve>
I’d like to eventually make it also do what vo_v4l2 wayland would do. ^^
<linkmauve>
MrCooper, ah perhaps, I haven’t checked that backend in a long time.
shankaru has quit [Quit: Leaving.]
<daniels>
lynxeye: haha no, please do just type faster
<daniels>
lynxeye: turns out that having COVID is pretty terrible for a) having a functional brain, or b) having the energy to use it
<linkmauve>
Oh no, I hope you’ll get well soon. :(
<linkmauve>
Last time I had it, for one month I couldn’t function at all.
<daniels>
ugh, sorry to hear :( yeah, hoping it's more like a week than a month but let's see
<tzimmermann>
javierm, ok. does dim cherry-pick print a warning?
<javierm>
tzimmermann: pretty useful. I opened dim to add something like that and noticed that already implements it :)
<tzimmermann>
:)
<javierm>
basically I want to avoid others to make the same mistakes I do
<javierm>
that's why I think that mentioning this command in a more prominent place is a good idea
chaim has quit [Quit: Konversation terminated!]
sagar_ has joined #dri-devel
rkanwal has joined #dri-devel
devilhorns has joined #dri-devel
MrCooper has quit [Quit: Leaving]
MrCooper has joined #dri-devel
heat has joined #dri-devel
swick has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
T_UNIX has joined #dri-devel
dreda has joined #dri-devel
dreda is now known as Guest4424
JoniSt has joined #dri-devel
<JoniSt>
pepp: Looks like I've hit a sore spot for drivers with that test I wrote... I'll update the MR with your suggestions in a bit :)
Daanct12 has quit [Quit: Leaving]
<JoniSt>
I hope the test actually triggers the TC bug too that I wanted to trigger... And not just that radeonsi bug
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
<pepp>
JoniSt: zink also fails the test (with or without TC)
<pepp>
JoniSt: but I don't think the test triggers the TC bug, because with the fix from !17394 the test pass on radeonsi
<JoniSt>
For me it also passes with !17338 with TC on radeonsi (but fails without that MR)... I'll try it again with !17394 but without !17338 when I have more time. Really weird
WinLinux1028 has quit [Quit: Leaving.]
<JoniSt>
Maybe I'll just have to write *another* test once !17394 is merged to properly trigger the TC bug
Namarrgon has quit [Quit: WeeChat 3.5]
Namarrgon has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #dri-devel
kts has joined #dri-devel
nchery has joined #dri-devel
itoral has quit []
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
pixelclu- has joined #dri-devel
pixelclu- has quit []
pixelclu- has joined #dri-devel
pixelclu- has quit [Remote host closed the connection]
pixelclu- has joined #dri-devel
pixelclu- has quit []
pixelcluster has quit [Ping timeout: 480 seconds]
Namarrgon has quit [Ping timeout: 480 seconds]
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
aravind has quit [Read error: Connection reset by peer]
pixelcluster has joined #dri-devel
devilhorns has quit []
Guest4424 is now known as dreda
kts has joined #dri-devel
shankaru has quit [Quit: Leaving.]
zehortigoza has joined #dri-devel
maxzor_ has joined #dri-devel
Company has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
<zmike>
JoniSt: are you trying to break my driver?!
* JoniSt
flees from the angry zmike
<JoniSt>
Maybe, but not intentionally :P
<zmike>
so rude
<JoniSt>
I didn't expect Mesa to just explode left and right when I wrote that test :P
wv__ has quit [Read error: Connection reset by peer]
wv__ has joined #dri-devel
<JoniSt>
The actual TC bug might be a bit more difficult to test for, given that my first attempt just hit a totally different bug in radeonsi and zink (and possibly other drivers, but I hope not...)
<JoniSt>
I'll write another test for it later if needed
evadot has joined #dri-devel
sven has joined #dri-devel
milek7 has joined #dri-devel
llyyr has joined #dri-devel
dviola has joined #dri-devel
<jenatali>
JoniSt: sounds like I need to try this test too
<JoniSt>
Probably, yeah. I hope nothing breaks at least for you!
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
ppascher has joined #dri-devel
Namarrgon has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
<jenatali>
I wouldn't be surprised if it did. I've got a known multicontext multithreading bug
<jenatali>
And having a test to verify when I fix it would be great
<JoniSt>
That's true! Anything's better than a Heisenbug
sul has joined #dri-devel
<jenatali>
Well it's not that, I know what's causing it, I just haven't fixed it yet
<JoniSt>
Ah!
<jenatali>
I only saw it in one Android app so far
<KunalAgarwal[m]>
Hey so I have been trying to perform some offscreen rendering using egl.. for which I want to export buffers using gbm. Can anyone help me with the ideal process?
<digetx>
linkmauve: do you have a link to your vo_vaapi_wayland patches?
<daniels>
KunalAgarwal[m]: don't export - if you're going to use GBM then use that to allocate first, create an EGLDisplay with the surfaceless platform, import the GBM BO to an EGLImage -> GL FBO, and render into it
<linkmauve>
Only the first commit is ready for use, the second one adds linux-dmabuf version 4 support, and the third one attempts to do some more synchronisation, unsuccessfully.
jewins has joined #dri-devel
<MrCooper>
kunalagarwal[m]: beware that the surfaceless platform automatically picks a GPU, which may not be the same as used by any running Wayland/X11 session in a multi-GPU system; if you want to use a specific GPU, use the device platform instead
rpigott has quit [Ping timeout: 480 seconds]
<KunalAgarwal[m]>
for context I have been using EGL_PLATFORM_GBM_MESA
<KunalAgarwal[m]>
"gbm_device from the render node, gbm_bo_create_with_modifiers2(), export dmabuf, and go on from there, for the allocation"
<KunalAgarwal[m]>
Not sure about the export dmabuf part. How can I do that?
Haaninjo has joined #dri-devel
<emersion>
gbm_bo_get_fd(_for_plane)
fahien has quit [Quit: fahien]
fahien has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
<KunalAgarwal[m]>
sounds good. will get back after testing and investigating further
<KunalAgarwal[m]>
thanks
alyssa has joined #dri-devel
<alyssa>
jekstrand: How do denorms work on Intel hardware?
<alyssa>
I'm trying to figure out how Iris possibly passed the CL CTS
<jenatali>
alyssa: CL doesn't require denorms for fp32
<alyssa>
jenatali: Ah ah ah
<alyssa>
> Denormalized numbers for the half data type which may be generated when converting a float to a half using vstore_half and converting a half to a float using vload_half cannot be flushed to zero
<jenatali>
You just have to correctly declare whether you support them or flush them
<jenatali>
Right, it does require denorms for fp16
<alyssa>
So you can't support them (due to libclc limitations) and you can't flush them (due to that spec text) C:
<jenatali>
Which is why I had to write manual fp16 conversion code even for the rounding mode that D3D supports, because D3D flushes fp16 denorms IIRC
<alyssa>
delight.
<jenatali>
Yep
<alyssa>
having a similar issue on Mali
<jekstrand>
:-/
<jekstrand>
alyssa: I think Intel does denorms by default
<alyssa>
The hw can either preserve everything or flush everything
<jenatali>
alyssa: What's the libclc limitation?
<alyssa>
Either way fails some part of the CTS, due to libclc flushing things and that spec text resp
<jenatali>
IIRC that code can be compiled to either preserve or flush
<alyssa>
jenatali: the spirv targets are compiled to flush
<alyssa>
I guess I could fix that upstream?
<jenatali>
Yeah
<alyssa>
Pain
<alyssa>
Baguette
<jenatali>
Or you could use my manual fp16 conversion lowering :P
<alyssa>
FWIW, Arm's OpenCL driver advertises full denorm support and then does completely straightforward implementations of everything
<alyssa>
Me trying to do the same was failing a bunch of math_bruteforce tests because of denorms (special functions)
<alyssa>
presumably because libclc was inserting flushes that shouldn't be there with FP_CONFIG_DENORM
<jenatali>
Yeah you probably want to get a denorm-supporting version of libclc
<alyssa>
right ... trying to figure out how we do this logistically then
<alyssa>
do we then have 4 libclc targets for mesa?
<alyssa>
{ 32-bit, 64-bit } x { denorms, ftz }?
<alyssa>
does DX12 not support denorms?
<jenatali>
D3D12 didn't support denorms until shader model 6.2, when it became toggleable (both are required now)
<jenatali>
But uh, we recently learned that one of our vendors just can't do denorm preservation, so that's fun
<jekstrand>
jenatali: Where does this 256B stride alignment requirement for dozen come from?
<alyssa>
jenatali: Oh, for extra funsies, in addition to "preserve all" and "flush all", Mali (Valhall) has a dx11 mode
<alyssa>
flush fp32, preserve fp16 :-p
<jenatali>
jekstrand: For buffer <-> image copies D3D requires a 256 byte pitch alignment
<jekstrand>
jenatali: Ok. Makes sense, I guess. Vulkan doesn't so that's going to be fun for you...
<jenatali>
I know, we're adding a feature to relax it
<jekstrand>
In any case, it's good to now that genuinely comes from the driver.
<jenatali>
Which, I guess I could just avoid inserting this, but then small swapchains would just fail if that feature's unavailable
<jekstrand>
Or they'd use whatever fallback path you have to have anyway.
<jenatali>
Hm, I don't remember if we added a fallback path for that. That might just be a case where we're failing now if we don't have a driver supporting that feature. Or maybe we did a fallback path but I don't remember helping design one :)
<jekstrand>
:)
<jekstrand>
In any case, the fallback is going to suck so let's not do that.
<alyssa>
oh, hum, actually the DX11 mode might do what I need?
<jenatali>
jekstrand: Agreed - I pushed a few patches to your MR that are trivial and give me what I want
<alyssa>
DX11 mode (flush fp32, preserve fp16) for F16_TO_F32 will flush the output but not the input
<jenatali>
alyssa: That sounds right
<alyssa>
So it'll correctly handle converting an fp16 denorm into an fp32 normal
<alyssa>
Are there are any numbers that are denorms in both fp16 and fp32 though?
<jenatali>
Don't think so
* alyssa
doesn't remember off hand
<jenatali>
fp32 denorms are way below the range of expressible fp16 even if you include fp16 denorms
<jekstrand>
jenatali: Yeah, what I'm wondering is how we want to make this work, exactly. For the PRIME path, we have a fixed 256B alignment because that's required for linear texturing on some devices.
<alyssa>
right, so every fp16 denorm is normal as fp32, and every fp32 denorm is zero as fp16, so it works out?
<jekstrand>
It seems like we ought to maybe max() over tome things?
<jenatali>
jekstrand: Oh I didn't see that anywhere, maybe I just missed it
<jekstrand>
jenatali: It's in wsi_common_drm.c
<jenatali>
Ah
<jekstrand>
256B isn't a very high alignment. Typically 64 pixels. We could just always do that on the buffer path, I guess.
<jekstrand>
Or we could make it configurable more places.
<jekstrand>
IDK
<jekstrand>
It's all a big mess
<jenatali>
I'd be inclined to just remove the linear_stride / size_align params and just hardcode them to 256B/4KiB
<jenatali>
Which I would've proposed had I seen that the PRIME path had those values :)
<jekstrand>
jenatali: HOw about we key it off of optimalBufferCopyRowPitchAlignment?
<jenatali>
Works for me
<jenatali>
Hm, but PRIME would need it hardcoded anyway because it's the other GPU that matters, and the driver for that other GPU isn't loaded?
<jekstrand>
Which dozen sets to 1... :joy:
<jekstrand>
I'll fix that. :)
<jenatali>
:O
<jenatali>
That's a bug
<jekstrand>
Yeah, PRIME will still need to force 256
mclasen has quit [Ping timeout: 480 seconds]
<jekstrand>
jenatali: Does D3D also reqiure the offset to be 256B-aligned?
<jenatali>
Offset has to be... 512-aligned I think?
<jekstrand>
Mind double-checking that? It's 1 too and I'd like to fix both while I'm here.
<jenatali>
Which, I'd prefer the #defines from the header instead of hardcoded numbers personally, but it's not a big deal, they're not going to change values with new headers
mclasen has joined #dri-devel
Ntemis has joined #dri-devel
fxkamd has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<jekstrand>
jenatali: Pushed the MR. It's got 3 new patches.
<jenatali>
jekstrand: great, will look in a few
nchery has joined #dri-devel
<jekstrand>
jenatali: Hrm... I should really make both X11 and Wayland fall back automatically. :-/
<jekstrand>
Or maybe not?
<jekstrand>
IDK what we want there.
<jenatali>
Fall back?
<jenatali>
If export fails fall back to software?
<jekstrand>
We could detect that there's no zwp_linux_dmabuf_v1 and silently fall back to SHM.
<alyssa>
jekstrand: OOI, what's making you look at WSI?
<jekstrand>
alyssa: jenatali asked me to. :)
<alyssa>
Ah
<jekstrand>
alyssa: It was a classic "here's some horror patches" followed by me going "OMG! No! Let's clean that up!" :D
<jekstrand>
They weren't that much of a horror show.... It's more WSI that's a horror show.
Duke`` has joined #dri-devel
<jenatali>
A situation where I knew I didn't know enough to get it right
<jenatali>
And one more reason I owe you a beer when we finally actually meet at XDC (hopefully)
<Thaodan>
work on foss to support non-foss = profit for any non-foss vendor?
fxkamd has quit []
wv__ has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
fxkamd has quit []
luc4 has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
<jenatali>
jekstrand: Pretty sure you can drop the Draft: tag on that MR since you dropped the hack commit, unless you had more reasons to hold off on it?
ybogdano has joined #dri-devel
fahien has quit [Quit: fahien]
luc4 has quit []
luc4 has joined #dri-devel
whald_ has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
zehortigoza has quit [Remote host closed the connection]
zehortigoza has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
zehortigoza has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
FireBurn has quit [Remote host closed the connection]
anarsoul|2 is now known as anarsoul
<anarsoul>
kchibisov: nope, I think it's X11 + EGL thing
<kchibisov>
I was just looking at EGL_KHR_platform_wayland and it mentions that Pixmaps are not a thing and will always result in an error, but from my experience pbuffers are the same on Wayland.
<kchibisov>
Since there's no EGLConfig supporting those.
<ajax>
they don't make much sense in wayland
<ajax>
they only barely made sense in x11 in a pre-ARB_fbo world
<ajax>
their semantics are "the display server allocates this and may lose it at any time", but wayland surface storage is allocated by the client
<daniels>
... specifically, that there are no T760s available
<daniels>
ah, they're both there, but just running terminal jobs which never time out, so something has gone wrong in our job submission because there should be an enforced timeout
<alyssa>
jekstrand: Ah. There's a vec8 phi in the way. C:
<alyssa>
On some code paths, I lowered phis to scalar without copypropping after. I see the issue now.
<alyssa>
Easy enough to fix, and no the fix is not "just run the progress loop HARDER"
<daniels>
or no, just because the DRM jobs have a timeout of 90min
<daniels>
tomeu: ^ can this please get cut down to 30 to match Mesa? I'm not sure of any reason why igt should take 90min ...
toolchains has quit [Read error: Connection timed out]
toolchains has joined #dri-devel
<jekstrand>
alyssa: That'll do it. :D
<alyssa>
jekstrand: But now I'm wondering if I want to assert a postcondition on my NIR opt/lowering about the sizes of things
ybogdano has joined #dri-devel
<alyssa>
but I guess it doesn't matter, because they're (now) asserted as preconditions in emit_alu which is good enough
<Sachiel>
I think that happens if you build in the same dir as the source?
toolchains has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
alyssa has quit [Quit: leaving]
<mattst88>
ah, probably
toolchains has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
ngcortes has joined #dri-devel
<Ntemis>
alyssa: so panfrost is left to rot? No panvk no gles3.2? :(
rasterman has joined #dri-devel
<Ntemis>
at least if we had gles3.2 would be on par with the libmali driver
gouchi has quit [Remote host closed the connection]
<HdkR>
Ntemis: What spawned this discussion?
<HdkR>
Panfrost is on a great upward trajectory
<Ntemis>
this line right here: <alyssa> kisak: can I stop being a FOSS maintainer now do you have any suggestions of an exit strategy?
<mattst88>
heh, I can appreciate that question
<Ntemis>
I find your response baring amazing news though
<Ntemis>
Hope is not lost
<HdkR>
That was just a sarcastic, tongue in cheek statement. Don't read that much in to it :)
srslypascal has quit [Ping timeout: 480 seconds]
<Ntemis>
ah i understand , thanks for the update
sul has quit [Read error: Connection reset by peer]
sul has joined #dri-devel
<Ntemis>
So..since i found some active people that can help me out ....:D
<daniels>
Ntemis: panfrost isn't being left to rot; panvk is still being worked on, and the reason ES3.2 isn't done is just pragmatic
<Ntemis>
yes if we get psnvk working gles3.2 is not that much needed
<daniels>
implementing geometry & tessellation shaders is a heroic amount of work (since the hardware doesn't support it) for very very little reward (since very few apps actually use it, and even if they tried it wouldn't be anywhere near as performant as they hoped)
<Ntemis>
*panvk
<daniels>
panvk is unlikely to expose GS/TS for that same reason
<daniels>
itmt, Gallium Panfrost does expose ES3.1 plus all relevant extensions
<Ntemis>
it does yes but we have issues on various heavy duty gpu cores
<Ntemis>
Dolphin ppsspp mupen64plus
<daniels>
Dolphin is an absolute nightmare case for GPU drivers, because you're trying to use general-purpose shaders to emulate one GPU within another GPU
<Ntemis>
thats the idea yes
<HdkR>
Also Dolphin only needs GS for line emulation, which is fine to have it slightly incorrect.
<daniels>
it doesn't mean that Panfrost is abandoned, just that you're asking the most demanding thing of it possible, and making that specific thing work really fast is not the highest priority
<Ntemis>
yes am not demanding anything is foss
<Ntemis>
will be done when it will be
<daniels>
when I said 'most demanding thing of it', I meant: Dolphin is kind of the ultimate-difficulty stress test for real-world uses
<Ntemis>
the other two are also demanding
<daniels>
yes :)
<Ntemis>
i can link you an image to test them out
<Ntemis>
what board you have?
<daniels>
images & boards isn't the problem - time is the problem
<Ntemis>
i know :(
icecream95 has joined #dri-devel
<Ntemis>
anyway i need help with patching mesa for ps4 pro gpu to work
<Ntemis>
i need some info where to look
<Ntemis>
sec to give you some details
<HdkR>
Once all the time is spent implementing everything else, Mali will likely just have a piece of hardware on the market that supports mesh shaders, then hey, free GS.
<HdkR>
;)
<Ntemis>
amen to that mate
<daniels>
yeah, the perpetual tension between 'squeeze every last fraction out of Midgard' vs. 'my RK3588 doesn't even run it at all yet'
<Ntemis>
where i need to look to patch in the model so mesa can work on it?
<Ntemis>
and/or if possible to merge the support in if possible
<HdkR>
No idea, probably something kernel or firmware related.
<Ntemis>
i have the kernel and the firmware of the gpu
<Ntemis>
i just need the mesa to work on it
<Ntemis>
is a GCN4 Polaris 10 variant
<daniels>
yeah, it would be a very long road, but first you'd need to start with drivers/gpu/drm/amdgpu/ inside the kernel to make its amdgpu driver pass the probe() callback, then make sure it exposes a /dev/dri/renderD128 device, then run igt-gpu-tools against it to make sure the kernel support works properly
<JoniSt>
Well, it's a "variation"... So it probably is incompatible in weird and wonderful ways (most likely in its memory setup, consoles do weird stuff)
<mareko>
mesh shaders can't fully do GS, but a subset of GS is possible
<daniels>
after that you've got libdrm's amdgpu support you'd probably need to add things to, then mesa's src/gallium/drivers/amdgpu/ to add any necessary IDs and workarounds to
<daniels>
but without any of us knowing how that GPU has been customised, it's impossible to say what work needs to be done
<Ntemis>
i got the picture
ahajda__ has joined #dri-devel
<HdkR>
mareko: The harsh reality sets in now
<Ntemis>
So kernel part is done
<Ntemis>
i have the gpu working fine
<Ntemis>
and is exposed
<Ntemis>
libdrm is patched and ready
<Ntemis>
and it works
<mareko>
AMD does GS using mesh shaders + extra stuff, and it's the extra stuff that is tricky (otherwise wouldn't have it in hw)
<Ntemis>
the part i need help is in mesa
<Ntemis>
so i only need to patch src/gallium/drivers/amdgpu/ ?
<Ntemis>
or anything else?
<daniels>
Ntemis: src/gallium/drivers/radeonsi/si_pipe.c -> radeonsi_screen_create() is your entrypoint
<Ntemis>
we already have some half baked support but is shit
<Ntemis>
they treat the gpu badly
<Ntemis>
because the one that implemented the support treated it as a kaberi
<Ntemis>
which is by miles wrong
mclasen has joined #dri-devel
<Ntemis>
kabini/kaberi i dont recon the atcual name atm
<Ntemis>
let me check the code
<Ntemis>
FAMILY_KV
<Ntemis>
so kabini+kaveri
ahajda_ has quit [Ping timeout: 480 seconds]
<Ntemis>
scrap that got it
<Ntemis>
return "bonaire";
<Ntemis>
that is epicly wrong
<JoniSt>
Ntemis: Well, according to Wikipedia, the APU contains a Polaris variant (Polaris10?) with certain architecture elements backported from Vega (such as FP16 improvements). The memory subsystem must also be vastly different than that of any discrete GPUs, but the existing(?) drivers for the PS4 GPU might help with that. Expect a lot of GPU hangs, though, while bringing it up.
<Ntemis>
yes is polaris 10
<Ntemis>
am not familiar with internal amd names though
<Ntemis>
what gladius must return to be a polaris 10?
luc4 has quit []
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]