Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] vo_gpu_next: use libplacebo interop for GL hwdec #10763

Closed
wants to merge 1 commit into from

Conversation

haasn
Copy link
Member

@haasn haasn commented Oct 20, 2022

Pass a ra_pl wrapper to the hwdec functions, instead of the original ra_ctx the OpenGL context was created from.

I'm well aware that this is all a gigantic mess and we should be making the code less reliant on ra, not more... but at least this allows us to start using the OpenGL interop inside libplcaebo for --vo=gpu-next, which is a step forwards as it allows for less messy integration and upstream bug fixes (e.g. EGLImageKHR mapping on desktop GL).

Pass a `ra_pl` wrapper to the hwdec functions, instead of the original
`ra_ctx` the OpenGL context was created from.

I'm well aware that this is all a gigantic mess and we should be making
the code *less* reliant on `ra`, not more... but at least this allows us
to start using the OpenGL interop inside libplcaebo for --vo=gpu-next,
which is a step forwards as it allows for less messy integration and
upstream bug fixes (e.g. EGLImageKHR mapping on desktop GL).
@haasn
Copy link
Member Author

haasn commented Oct 20, 2022

Unfortunately I think this breaks some hwdecs, e.g. aimagereader, d3d11egl. Ideally we would rewrite these on top of pl_gpu abstractions as well, the way dmabuf / cuda are handled currently.

But, I think in writing this comment I've already made the decision that we should probably not try integrating vo_gpu and vo_gpu_next more, but should instead be doing the opposite: rewriting context creation and hwdec code from scratch, factoring out common helpers where needed, and remove all dependency of gpu_next on ra_ctx code.

I will probably end up doing this after 0.35, because it would represent both a major breaking change and a regression in functionality.

@sfan5 sfan5 added the meta:rfc label Aug 20, 2023
@kasper93
Copy link
Contributor

As this breaks some hwdecs and needs significantly different approach, I'm closing this for now. Feel free to reopen, create a new one.

@kasper93 kasper93 closed this Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants