ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
ella-0 has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
flacks has joined #dri-devel
flacks_ has joined #dri-devel
flacks has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
flacks has joined #dri-devel
flacks_ has quit [Ping timeout: 480 seconds]
jolan has quit [Quit: leaving]
jolan has joined #dri-devel
Lyude has quit [Quit: WeeChat 3.2]
Lyude has joined #dri-devel
bbrezillon has quit [Read error: Connection reset by peer]
mripard has quit [Read error: Connection reset by peer]
mripard has joined #dri-devel
bbrezillon has joined #dri-devel
cphealy has joined #dri-devel
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
Duke`` has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
pendingchaos_ has quit [Read error: Connection reset by peer]
pendingchaos has joined #dri-devel
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
rasterman has joined #dri-devel
Company has quit [Quit: Leaving]
rcf has quit [Quit: WeeChat 3.1]
gouchi has joined #dri-devel
JohnnyonFlame has quit [Remote host closed the connection]
Namarrgon has quit [Ping timeout: 480 seconds]
Namarrgon has joined #dri-devel
pendingchaos has quit [Remote host closed the connection]
pendingchaos has joined #dri-devel
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
Hi-Angel has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Hi-Angel has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
aperezdc has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
gawin has joined #dri-devel
<MrCooper>
Plagman: halfline is our plymouth guru
Hi-Angel has joined #dri-devel
pendingchaos has quit [Read error: No route to host]
pendingchaos has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
Company has joined #dri-devel
Danct12 has quit [Quit: Quitting]
gawin has quit [Ping timeout: 480 seconds]
vup2 has quit [Remote host closed the connection]
vup has joined #dri-devel
tarceri has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
danvet has joined #dri-devel
vocalfan has joined #dri-devel
<vocalfan>
Heyya
<vocalfan>
I've been having a bit of an issue recently after I updated Mesa. Whenever I try to start one of my games on Ryujinx, I get an NVDEC h264 crash when the game tries to use a video.
<vocalfan>
Which... Didn't occur a week ago.
<HdkR>
vocalfan: If you're using nvdec then you aren't using mesa. Mesa doesn't implement nvdec video decoding
<vocalfan>
Then... What is this?
<vocalfan>
"Ryujinx.NvdecProcessor Application : Unhandled exception caught: System.ArgumentNullException: Value cannot be null. (Parameter 'ptr')"
<HdkR>
Maybe you were using the nvidia blob but an OS update half borked the install?
<HdkR>
Hard to tell since that error doesn't really say much
<vocalfan>
I use AMD 5700XT lol.
<vocalfan>
I can send the full error if you want.
<vocalfan>
Ryujinx.NvdecProcessor Application : Unhandled exception caught: System.ArgumentNullException: Value cannot be null. (Parameter 'ptr')
<vocalfan>
at System.Runtime.InteropServices.Marshal.GetDelegateForFunctionPointer[TDelegate](IntPtr ptr)
<vocalfan>
at Ryujinx.Graphics.Nvdec.H264.Decoder..ctor()
<vocalfan>
at System.Runtime.InteropServices.Marshal.GetDelegateForFunctionPointer(IntPtr ptr, Type t)
<vocalfan>
at Ryujinx.Graphics.Nvdec.H264.FFmpegContext..ctor()
<vocalfan>
at Ryujinx.Graphics.Nvdec.NvdecDecoderContext.GetDecoder()
<vocalfan>
at Ryujinx.Graphics.Nvdec.H264Decoder.Decode(NvdecDecoderContext context, ResourceManager rm, NvdecRegisters& state)
<vocalfan>
at Ryujinx.Graphics.Nvdec.NvdecDevice.Decode(CodecId codecId)
<vocalfan>
at Ryujinx.Common.AsyncWorkQueue`1.DoWork()
<vocalfan>
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
<vocalfan>
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
<vocalfan>
--- End of stack trace from previous location ---
<vocalfan>
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
<vocalfan>
at System.Threading.ThreadHelper.ThreadStart()
<vocalfan>
There.
<HdkR>
Oh, then you're definitely not using host nvdec and this would be them emulating the nvdec on the TX1.
<HdkR>
Also long pastes should go to some paste website.
<vocalfan>
What would break this? x3
<HdkR>
From context, it looks like they are trying to create an ffmpeg decoder and "something" is going wrong. That something would likely need to be discovered by the project devs
<vocalfan>
I mean, idk if they can.
<HdkR>
Although probably good to check if you're still getting hardware video decode by checking vainfo and other video decode apps
<vocalfan>
How would I see that on Vainfo?
<HdkR>
vainfo will tell you what is doing the video decoding
<HdkR>
Myself running it currently throws a bunch of Intel information at me
<HdkR>
Well looks like va-api is theoretically working :P
<vocalfan>
"Theoretically" XD
<HdkR>
Getting information isn't quite the same as it actually working, but it is usually close enough
<HdkR>
If you give the Backtrace to the Ryujinx dev then maybe they can put more checking around the decoder initialization though and find out what is exactly failing rather than just asserting
<robclark>
mareko: would it be cheating too hard to make tc get_device_reset_status() not sync? Ie. device resets are asynchronous in the first place, so I was contemplating making it call directly thru to driver in frontend thread instead of flushing
vocalfan has quit [Quit: Leaving]
rbrune has joined #dri-devel
gawin has joined #dri-devel
xexaxo has quit [Read error: Connection reset by peer]
xexaxo has joined #dri-devel
Danct12 has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
gouchi has joined #dri-devel
shashank1202 has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<mareko>
robclark: that should be fine
<mareko>
robclark: I don't know if radeonsi can handle it though
<robclark>
I put up an RFC at !13163 .. I could easily make it so drivers can opt-in to making it not sync, if that is needed
<zmike>
eh there's not that many drivers implementing tc
<zmike>
what is it like 4?
<robclark>
I got a bit lost digging thru radeonsi winsys ;-)
<robclark>
zmike: looks like 5 now
<robclark>
crocus
<zmike>
ah yea
<zmike>
but changes to iris can just copypaste there anyway
<robclark>
true
<zmike>
zink won't need any changes, at the least
<robclark>
ok, so at least two don't need changes then ;-)
<zmike>
:)
<mareko>
robclark: radeonsi looks thread-agnostic to me
<mareko>
so you can call get_device_reset_status from any thread
<robclark>
I think the only limit is you can't call it from two different threads (for freedreno at least, but I think also others)
<mareko>
actually not any thread, but calling it from the frontend thread is fine
<robclark>
but if you are always calling from frontend thread, that should be ok
<robclark>
right
<mareko>
and that's only because of the callback
<robclark>
I never did wire up the callback.. since, IIRC mesa itself can handle the callback (and I don't have any async notification from kernel)
slattann has joined #dri-devel
vup has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
heat has joined #dri-devel
slattann has quit []
<mareko>
I think we check the reset status at every flush
<mareko>
so the callback then becomes useful
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.2]
shashank1202 has quit [Quit: Connection closed for inactivity]
gouchi has quit [Remote host closed the connection]
jewins has joined #dri-devel
rbrune has quit [Ping timeout: 480 seconds]
sagar_ has quit [Remote host closed the connection]
sagar_ has joined #dri-devel
xlei has quit [Read error: Connection reset by peer]
<halfline>
Plagman: i don't recall that limitation in the api, but a git grep for ply_image_rotate shows we don't actually call it every in tree, so it could have just gone unnoticed
<halfline>
obvious workaround I guess would be to pad out your images by a factor of sqrt(2) i suppose
<halfline>
feel free to file it too of course
gawin has joined #dri-devel
boistordu_ex has joined #dri-devel
ngcortes has joined #dri-devel
shashank1202 has quit [Quit: Connection closed for inactivity]
boistordu_ex has quit []
Hi-Angel has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
boistordu_ex has joined #dri-devel
pcercuei has quit [Quit: dodo]
boistordu_ex has quit []
muhomor has quit [Ping timeout: 480 seconds]
reductum has joined #dri-devel
boistordu_ex has joined #dri-devel
<Plagman>
the image is used elsewhere so i can't easily change its dimensions
<Plagman>
i'm not sure if sqrt(2) is it, i'm trying to rotate it 90degs so it completely matches the fb size, but it seems like its width is clipped by the fb height
<Plagman>
if it's a clipping situation i'm not sure if any amount of extra padding would do much
<Plagman>
maybe i just need to set the sprite dimensions explicitely as well?