ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
fantom has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
Nasina has quit [Ping timeout: 480 seconds]
haaninjo has quit [Quit: Ex-Chat]
glennk has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
smpl has quit [Ping timeout: 480 seconds]
aissen has quit [Ping timeout: 480 seconds]
guludo has quit [Ping timeout: 480 seconds]
aissen has joined #dri-devel
The_Company has joined #dri-devel
calico has joined #dri-devel
The_Company has quit []
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
the_sea_peoples has joined #dri-devel
calico has quit [Quit: Leaving]
YuGiOhJCJ has joined #dri-devel
tarceri_ has quit []
tarceri has joined #dri-devel
<tarceri>
MrCooper: thanks. I think I'll put any further fix attempts on hold until rob merges his series, I think we will want the bigendian users testing his series before it lands to avoid regressing further and we can try put the final pieces together after
kisak has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
<robclark>
tarceri: gee, thanks for introducing my MR to b/e quagmire ;-)
feaneron has quit [Ping timeout: 480 seconds]
<robclark>
that said, I think my MR removes any of the "endian aliased" pipe formats other than __DRI_IMAGE_FOURCC_SARGB8888 (and idk what b/e cases that might effect) so I guess at least closer to not sucking
lemonzest has joined #dri-devel
<tarceri>
lol
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
Duke`` has joined #dri-devel
<tarceri>
robclark: I'll review what I can to keep things moving along ;)
croissant_ has joined #dri-devel
<tarceri>
it shouldn't hold up your series as long a it doesn't completely break the driver loading again
nerdopolis has quit [Ping timeout: 480 seconds]
croissant__ has joined #dri-devel
<robclark>
tarceri: I had been trying to preserve current breakage carefully... but pls have a look at my rebase to double check my work
<robclark>
(the format things are headache inducing ;-))
croissant has quit [Ping timeout: 480 seconds]
Duke`` has quit []
Duke`` has joined #dri-devel
<tarceri>
I have a feeling the color may flip like they did with the mr I closed (unless you mr fixes something else) but that can probably be dealt with later. It seem like dri and pipe don't always act the same way where they are used but we might just need to fix the use locations rather than the definitions
croissant_ has quit [Ping timeout: 480 seconds]
<robclark>
maybe there are other hidden bugs... but IMO we should just have drm and pipe formats
<tarceri>
and yeah its confusing stuff but by the time its all cleaned u it will be much better than the way it was a few year ago with magic numbers mapped together everywhere. It not surprising it all fell apart
<robclark>
if we map drm to pipe faithfully then rest is for things with b/e hw to find the bugs
<robclark>
(and by things I mean ppl.. sry ofc)
<tarceri>
haha, I'm one of those thin... err people now.
<tarceri>
I think there are openpowerpc things it the works too so I'm sure this would all come back one day even if all the old hardware was to melt at once
<robclark>
some arm things are bi-endian too... but I think nv had the right idea when they convinced power to give in and go l/e.. it's just too big a windmill to tilt against
<tarceri>
yeah
<tarceri>
I discovered a powerpc linux facebook group with around 3000 members the other day should I direct them to your MR? :-P
<robclark>
pls don't :-)
<tarceri>
j/k
<hazard_hitman>
haha
kzd has quit [Ping timeout: 480 seconds]
<robclark>
direct them to piglit or whatever way we can reproducibly test their use-case in ci.. and then leave it up to the ci maintainers to balance ci resources vs benefit to community.. but if there aren't ci tests proving something is broken, then it isn't
<airlied>
not sure anyone wants to run a BE GPU CI machine :-)
<airlied>
keeping the s390 stuff in is enough of a fight
<tarceri>
is there r300 ci now?
<robclark>
if no one cares enough to keep lights on in Ci then no one cares enough if an MR breaks them
<robclark>
I mean CI isn't the end of the day for "working" but it is the bare minimum
<airlied>
I don't think you can ask someone to run CI for community stuff really, it's not sustainable
<airlied>
like we can barely get enough functional hardware in one place to sustain what we do have
<airlied>
I can't imagine anyone getting a G5 + gpu combo into a stable enough state to run on, it'll always be finding regressions and fixing it
<airlied>
or we declare we only care about s390 + llvmpipe and burn anything else down, and tell them to stick to old mesa
<robclark>
without CI we are just hoping changes don't break things... beyond that it is up to folks who care to step up
<robclark>
not trying to break things intentionally.. just saying it is hard to repro issures otherwise
<tarceri>
robclark: if they test your series and the worst thing that happens is the colours flip I'm happy for you to push those first 3 patches and I'll plug away at fixes eventually
<tarceri>
i added my rb
<robclark>
thx
<robclark>
at least everyone agrees on getting rid on dri formats :-P
croissant_ has joined #dri-devel
croissant_ has quit [Remote host closed the connection]
croissant has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
croissant__ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.6.3]
lemonzest has joined #dri-devel
Nasina has joined #dri-devel
dolphin has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
itoral has joined #dri-devel
MeysamAsg[m] has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
alarumbe has quit []
Duke`` has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
dolphin has quit [Quit: Leaving]
libv has joined #dri-devel
davispuh has quit []
libv_ has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
libv_ is now known as libv
rasterman has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
fab has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
blaztinn has quit [Remote host closed the connection]
blaztinn has joined #dri-devel
<MrCooper>
zamundaaa[m]: e.g. when the commit became ready to program to HW, and when the deadline for that was
northernking1 has quit [Remote host closed the connection]
jsa1 has joined #dri-devel
vliaskov has joined #dri-devel
frieder has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
<daniels>
I have seen the MRs but this heatwave has been doing bad things to my brain; hopefully it settles down tomorrow and I can do things which aren't just completely mindless
<tarceri>
daniels: you've gone full native. Handling the heat like a true brit :-P
<daniels>
genuinely part of the reason I left!
<daniels>
but also ... everywhere in this place is designed to capture as much heat as possible and never let it escape. which works well most of the year tbf
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
apinheiro has quit [Ping timeout: 480 seconds]
<tarceri>
I could use a bit of that right now
Nasina has quit [Read error: Connection reset by peer]
<tarceri>
I got an old G5 with an r300 although most fixes have been for r600 thus far
phasta has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
Nasina has joined #dri-devel
fab has joined #dri-devel
The_Company has quit []
fab is now known as Guest21144
Company has joined #dri-devel
Nasina has quit [Remote host closed the connection]
frieder has joined #dri-devel
Guest21144 has quit []
fab_ has joined #dri-devel
fab_ is now known as Guest21146
Nasina has joined #dri-devel
tyalie has quit []
tyalie has joined #dri-devel
Nasina has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
Guest21146 has quit []
<pinchartl>
vsyrjala: it would be nice if you could CC the cover letter to everybody when you send a series. I always have to look it up
itoral has quit [Remote host closed the connection]
lsntvt has joined #dri-devel
u-amarsh04 has joined #dri-devel
edt_ has quit [Remote host closed the connection]
warpme has joined #dri-devel
vliaskov_ has quit [Remote host closed the connection]
vliaskov_ has joined #dri-devel
nerdopolis has joined #dri-devel
warpme is now known as Guest21150
pepp has quit [Ping timeout: 480 seconds]
SquareWinter68_ has joined #dri-devel
SquareWinter68 has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
kts has joined #dri-devel
pepp has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
Nasina has joined #dri-devel
kzd has joined #dri-devel
asrivats_ has joined #dri-devel
fab has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.6.3]
kts has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
idr has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
<daniels>
tarceri: you'll be glad to hear my British internet has also decided it's too hot to work
frieder has quit [Remote host closed the connection]
<zmike>
jenatali: I see in mediafoundation you're using set_fence_timeline_wait, but it's not obvious to me where that frontend is calling sync/signal
<jenatali>
Looking
dsimic is now known as Guest21157
dsimic has joined #dri-devel
Guest21157 has quit [Ping timeout: 480 seconds]
<jenatali>
zmike: I'm not finding that function name - what's the function you're talking about?
rasterman has quit [Quit: Gettin' stinky!]
<zmike>
it's a pipe_screen method
<jenatali>
Just trying to find the context of where in the stack the problem is
<jenatali>
Ah, value, not wait
<jenatali>
zmike: The fence is passed as a pointer into a bunch of video methods which implicitly signal/wait on it
<zmike>
can you elaborate on that?
<zmike>
I'm fixing the timeline semaphore implementation because it's broken, and it's not clear how to fix things here
<jenatali>
What's broken? :)
<zmike>
by spec, you can set the timeline value, wait, set the timeline value again, signal
<zmike>
and this is fine
<zmike>
but the current implementation has the value as a separate screen method without any synchronization
<zmike>
so you will flush on the signal and use the second value for both the wait and signal
<jenatali>
The wait should also flush?
<zmike>
that isn't a requirement
<zmike>
the value should have been passed to the sync/signal methods
<zmike>
and not be a separate method
<zmike>
so I'm fixing that
<jenatali>
Sure. IIRC I had talked about doing that but it was a ton of churn for a low-value thing
<zmike>
yes I'm not a fan of the churn
<zmike>
but the current implementation is broken
<zmike>
so
<zmike>
another day, another full-tree refactor
<jenatali>
So I see a pipe_fence_handle in pipe_vpp_desc, as well as pipe_picture_desc
<jenatali>
But if you're going to put values to go along with fence handles, then you also need them in every place where a fence is created, don't you?
<zmike>
how about I'll put up the MR and you can tell me what to fix
warpme has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
<jenatali>
Sure, I'll take a look at it
warpme is now known as Guest21161
mripard_ has joined #dri-devel
Guest21161 has quit []
mripard has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
Nasina has joined #dri-devel
<robclark>
karolherbst: shouldn't rusticl be returning an error if app ignores pipe_compute_state_object_info::max_threads ?
<karolherbst>
probably?
<karolherbst>
if you check clEnqueueNDRangeKernel there are many error codes I haven't bothered to implement yet
<karolherbst>
mhhh
<karolherbst>
robclark: it seems like I have added a check for it?
<zmike>
I left the original call intact so you can see
<jenatali>
zmike: So the problem is, all pipe_fence_handles for us are timeline semaphores under the covers. So far they've just had an implicit value associated with them
<zmike>
hm
<zmike>
I'm not sure how that affects this
<jenatali>
So passing a value just for the server sync/signal is kinda broken
<jenatali>
Since then you've basically got 2 values - one that's embedded in the pipe_fence_handle as a single point in time, and another one that treats the pipe_fence_handle has a full timeline
<zmike>
oh, you mean you're setting a timeline value on a regular fence?
jsa1 has joined #dri-devel
<jenatali>
I guess what I'm trying to say is, it seems like the right way to go about this is to make it so that you create a fence with a new driver object that represents a timeline semaphore, and then a timeline value
<jenatali>
If you want the fence to be immutable / not have the sync issues you were talking about
<zmike>
yes that's how it currently works with this MR
<jenatali>
Having a fence both represent a point in time and a timeline is broken
<zmike>
I think you were misusing the api before
<zmike>
the fence create api does have that enum so that the driver is aware it is creating a timeline semaphore
<zmike>
but because mesa uses threads internally, you definitely cannot use a screen method to modify a context object
<jenatali>
So maybe the solution is to just move the setter to a context?
<zmike>
that doesn't make any sense though
<zmike>
timeline values are only valid for timeline semaphores
<daniels>
robclark: sooooo yeah, we are missing some tests for sure - that’s part of the reason I’m so hesitant to introduce something which will likely change behaviour without making it more structurally sound
<daniels>
I mean that entire path is a nightmare
<zmike>
and you can't wait on those the same way you wait on normal fences
<daniels>
but we’re a) doing a bunch of piglit for it and b) also doing YUV target, so hopefully that will all change
<jenatali>
It really seems like a timeline semaphore should be a different kind of driver object entirely then
<zmike>
functionally it is since there is an enum for creating it
<zmike>
if you haven't been adhering to that divide then that's a you problem
<daniels>
so lemme merge the useful cleanups first, have a bash at getting the mapping persisted, and then we can see what else shakes out?
<jenatali>
Hm I see what you're saying
<robclark>
ok.. but I really do need to add some fourcc's to the table sometime before EXT_YUV_target ;-)
<daniels>
robclark: for sure
<robclark>
and do kinda think that whatever we do can't suck much more than what's already there ;-)
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<daniels>
yes except some idiot has to fix it :P
<jenatali>
zmike: Ack, I'm following now. Just to confirm, you can't do client waits on timeline semaphores, right? Only server wait/signal?
<daniels>
let’s see where I get to before I lose the will to live (again)
<zmike>
jenatali: yes
<zmike>
it must go through the interop/externalobjects api
<zmike>
(in GL terms)
<jenatali>
Ok so then I just need to update our driver to store the fence type (if we're not already) and use the internal value for wait/signal unless it's a timeline semaphore, then use the external value
<zmike>
sounds right
<zmike>
also mediafoundation needs to be updated somehow
<jenatali>
And then the places where there's a pipe_fence_handle in the video args should be updated to also take a value, since there's implied server syncs associated there
<zmike>
feel free to push directly to the MR
<jenatali>
Thanks, I think I can get to this later todya
<robclark>
daniels: I think I'm still leaning towards "removing dri_format probably at least fixes more things than it breaks" ;-)
<robclark>
(yeah, I missed the fourcc attrib usage in gbm and egl)
<jenatali>
zmike: Can you elaborate on "functionally this is the same as other types of timeline semaphores, but it is not actually the same as other types of timeline semaphores" ?
<zmike>
jenatali: the mechanics are not the same
<jenatali>
Oh it's just which extension it came through?
<zmike>
like in vulkan terms a vk timeline semaphore is VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT and a d3d12 semaphore is VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT
<zmike>
but a vk timeline semaphore can be used on windows, so a build-time define is not sufficient
<jenatali>
Ok, not a big deal, just didn't quite understand
<zmike>
it's a very minor and stupid detail but still I had to do a full-tree rename
akselmo is now known as Guest21163
Guest21163 has quit [Remote host closed the connection]
<daniels>
robclark: if any of this could be reasoned about in any consistent way I'd be with you on that
<robclark>
I mean, we're going to have to deal with the fallout of dedup _eventually_
rasterman has joined #dri-devel
<jenatali>
zmike: Just to make sure I'm remembering: there's no way for GL to create a timeline semaphore, only import, right?
<zmike>
jenatali: not sure what you mean? it's only available in functions taking pipe_fd_type
<jenatali>
Right, which also take external handles for importing
<zmike>
create_fence_fd, for example
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
warpme has joined #dri-devel
coldfeet has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
olivial has quit [Read error: Connection reset by peer]
olivial has joined #dri-devel
warpme has quit []
<glehmann>
if 4 is the maximum width that you can support, then yes (or maybe for e.g. iadd 4 if 32bit and 8 if 16bit, depends on your kind of vec4)
urja has quit [Read error: Connection reset by peer]
<glehmann>
You can return 0 if you just want to leave an instruction as is, but that opens the question: if you don't want to lower fdot and you don't want to lower the width of other alu, why are you calling the pass?
urja has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
<austriancoder>
glehmann: nir_lower_alu_width(..) lowers nir_op_pack/nir_op_unpack ALU Instructions - thats why I am using it in the first place
<glehmann>
if you are just interested in that, then you can return 1 for those and 0 for everything else
<austriancoder>
glehmann: I will give it a try
<glehmann>
btw, is it inappropriate to say I pity you for having to work with vec4 in 2025?
<glehmann>
:D
asrivats_ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
coldfeet has quit [Quit: Lost terminal]
<alyssa>
glehmann: my first shader compiler targeted vec16 hardware, if you were wondering how I got this way.
<alyssa>
(i8vec16, I mean)
<alyssa>
(it.. supported vec16 swizzles...)
Karyon_ has quit [Ping timeout: 480 seconds]
epoch101 has quit [Read error: Connection reset by peer]
epoch101 has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
asrivats_ has joined #dri-devel
kts has joined #dri-devel
alanc has quit [Remote host closed the connection]
asrivats_ has quit [Remote host closed the connection]
alanc has joined #dri-devel
asrivats_ has joined #dri-devel
vliaskov has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Read error: Connection reset by peer]
asrivats_ has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
<robclark>
so mali is to blame for cl having vec16?
kts has quit []
<karolherbst>
heh...
alarumbe has joined #dri-devel
<karolherbst>
did mali even exist when CL was created? :P
<robclark>
I think mali-400 existed?
vliaskov has quit []
<karolherbst>
mhhh
<karolherbst>
seems to check out
lynxeye has quit [Quit: Leaving.]
epoch101_ has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
coldfeet has quit [Quit: Lost terminal]
Nasina has joined #dri-devel
Nasina has quit [Read error: Network is unreachable]
apinheiro has quit [Quit: Leaving]
Company has quit [Quit: Leaving]
Duke`` has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
Nasina has quit [Ping timeout: 480 seconds]
aswar002_ has quit []
aswar002 has joined #dri-devel
Nasina has joined #dri-devel
pcercuei has quit [Quit: dodo]
Nasina has quit [Read error: Connection reset by peer]