Add DRM modifiers to EGLImage creation #9453
Conversation
|
This seems to make sense. Do you have your nvdec wrapper code anywhere I can see? The challenge has always been that you can't trivially export the decoded frames from cuda. But I do know that the decoded frames are in a linear format so I'm surprised that modifiers are necessary. |
|
I don't have the wrapper code released yet, I'm still trying to squash the last (I hope) major bug out of it, where part of CUDA will crash after about 64 frames. |
|
Yuck, but not surprising. So you tried copying the frame to allocated memory and then export with cuMemExportToShareableHandle and that couldn't be imported? |
|
Yes, that was my first idea/hope, but using cuMemExportToShareableHandle doesn't seem to produce fd's that are DMA-BUF compatible. I do plan on revisiting it once I've got it fully working to see what can be improved, but trying to work my way through this is a bit of a slog as there's basically no real documentation on how to do this. |
|
Hmm. They claim that there is some way to import it into GL. Maybe you can slightly simplify it by exporting it as a shared memory handle and then importing it via that other extension and then export from EGL as a dma bug. That at least avoids the eglstream mess. |
|
@elFarto Can you give the change a proper description? Explain that we should be exporting the frames with modifiers for correctness even if it was working before. |
Include the supplied DRM modifiers in the call to to eglCreateImage. Modifiers are required on certain implementations, and the eglCreateImage call can fail without them.
|
Implemented in #9507. Sorry for ignoring your PR, I didn't see it until now. |
While attempting to get mpv to use my VA-API implementation on-top of NVDEC, I noticed that the VA-API GL path doesn't correctly set the DRM modifiers when creating the EGLImage. Without the modifiers the creation fails.