summaryrefslogtreecommitdiffstats
path: root/video/out/opengl/ra_gl.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: attempt re-using the FBO format for p->output_texNiklas Haas2017-12-251-0/+3
| | | | | | | | | This allows RAs with support for non-opaque FBO formats to use a more appropriate FBO format for the output tex, possibly enabling a more efficient blit operation. This requires distinguishing between real formats (which can be used to create textures) and fake formats (e.g. ra_gl's FBO hack).
* vo_gpu: allow invalidating FBO in renderpass_runNiklas Haas2017-12-251-0/+4
| | | | | | | | | This is especially interesting for vulkan since it allows completely skipping the layout transition as part of the renderpass. Unfortunately, that also means it needs to be put into renderpass_params, as opposed to renderpass_run_params (unlike #4777). Closes #4777.
* msg: reinterpret a bunch of message levelsNiklas Haas2017-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
* vo_gpu: d3d11: add RA caps for ra_d3d11James Ross-Gowan2017-11-071-0/+5
| | | | | | | | | | | | | | | | ra_d3d11 uses the SPIR-V compiler to translate GLSL to SPIR-V, which is then translated to HLSL. This means it always exposes the same GLSL version that the SPIR-V compiler supports (4.50 for shaderc/glslang.) Despite claiming to support GLSL 4.50, some features that are tied to the GLSL version in OpenGL are not supported by ra_d3d11 when targeting legacy Direct3D feature levels. This includes two features that mpv relies on: - Reading from gl_FragCoord in the fragment shader (requires FL 10_0) - textureGather from any texture component (requires FL 11_0) These features have been exposed as new RA caps.
* vo_gpu: export the GLSL format qualifier for ra_formatJames Ross-Gowan2017-11-071-0/+2
| | | | | | | | | | | | | | | Backported from @haasn's change to libplacebo, except in the current RA, there's nothing to indicate an ra_format can be bound as a storage image, so there's no way to force all of these formats to have a glsl_format. Instead, the layout qualifier will be removed if glsl_format is NULL. This is needed for the upcoming ra_d3d11 backend. In Direct3D 11, while loading float values from unorm images often works as expected, it's technically undefined behaviour, and in Windows 10, it will cause the debug layer to spam the log with error messages. Also, apparently in GLSL, the format name must match the image's format exactly (but in Direct3D, it just has to have the same component type.)
* vo_gpu: add namespace query mechanismJames Ross-Gowan2017-11-071-1/+6
| | | | | | Backported from @haasn's change to libplacebo. More flexible than the previous "shared || non-shared" distinction. The extra flexibility is needed for Direct3D 11, but it also doesn't hurt code-wise.
* vo_gpu: ra_gl: fix crash trying to use glBindBufferBase on GL 2.1wm42017-11-031-2/+7
| | | | | | | Apparently this is required, but it doesn't check for it. To be fair, this was tested by creating a compatibility context and pretending it's GL 2.1. GL_ARB_shader_storage_buffer_object actually requires GL 4.0 or up, but GL_ARB_uniform_buffer_object requires only GL 2.0.
* vo_opengl: refactor into vo_gpuNiklas Haas2017-09-211-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
* vo_opengl: make the ra_renderpass names consistentNiklas Haas2017-09-131-1/+1
| | | | The random space kept screwing me over
* vo_opengl: generalize UBO packing/handlingNiklas Haas2017-09-121-0/+1
| | | | | | This is simultaneously generalized into two directions: 1. Support more sc_uniform types (needed for SC_UNIFORM_TYPE_PUSHC) 2. Support more flexible packing (needed for both PUSHC and ra_d3d11)
* vo_opengl: fix the renderpass target format at creation timeNiklas Haas2017-08-271-0/+1
| | | | Required for vulkan.
* vo_opengl: use UBOs where supported/requiredNiklas Haas2017-08-271-0/+1
| | | | | | | | | | | | This also introduces RA_CAP_GLOBAL_UNIFORM. If this is not set, UBOs *must* be used for non-bindings. Currently the cap is ignored though, and the shader_cache *always* generates UBO-using code where it can. Could be made an option in principle. Only enabled for drivers new enough to support explicit UBO offsets, just in case... No change to performance, which is probably what we expect.
* vo_opengl: add support for UBOsNiklas Haas2017-08-271-2/+8
| | | | | Not actually used by anything yet, but straightforward enough to add to the RA API for starters.
* vo_opengl: refactor shader_cache bindingNiklas Haas2017-08-271-13/+18
| | | | | There's no reason to be needlessly wasteful with our binding points here. Just add a CAP for it.
* vo_opengl: be explicit about IMG_RWNiklas Haas2017-08-271-8/+10
| | | | | | | | | | | | Both vulkan and opengl distinguish between rendering to an image and using an image as a storage attachment. So make this an explicit capability instead of lumping it in with render_dst. (That way we could support, for example, using an image as a storage attachment without requiring a framebuffer) The real reason for this change is that you can directly use the output FBO as a storage attachment on vulkan but you can't on opengl, which makes this param structly separate from render_dst.
* vo_opengl: refactor tex_upload to ra_buf_poolNiklas Haas2017-08-221-0/+6
| | | | | | | | | | Also refactors the usage of tex_upload to make ra_tex_upload_pbo a RA-internal thing again. ra_buf_pool has the main advantage of being dynamically sized depending on buf_poll, so for OpenGL we'll end up only using one buffer (when not persistently mapping) - while for vulkan we'll use as many as necessary, which depends on the swapchain depth anyway.
* vo_opengl: allow texture uploads to failNiklas Haas2017-08-181-1/+3
| | | | Surprisingly makes the code shorter, not longer
* vo_opengl: refactor RA texture and buffer updatesNiklas Haas2017-08-181-42/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - tex_uploads args are moved to a struct - the ability to directly upload texture data without going through a buffer is made explicit - the concept of buffer updates and buffer polling is made more explicit and generalized to buf_update as well (not just mapped buffers) - the ability to call tex_upload/buf_update on a tex/buf is made explicit during tex/buf creation - uploading from buffers now uses an explicit offset instead of implicitly comparing *src against buf->data, because not all buffers may actually be persistently mapped - the initial_data = immutable requirement is dropped. (May be re-added later for D3D11 if that ever becomes a thing) This change helps the vulkan abstraction immensely and also helps move common code (like the PBO pooling) out of ra_gl and into the opengl/utils.c This also technically has the side-benefit / side-constraint of using PBOs for OSD texture uploads as well, which actually seems to help performance on machines where --opengl-pbo is faster than the naive code path. Because of this, I decided to hook up the OSD code to the opengl-pbo option as well. One drawback of this refactor is that the GL_STREAM_COPY hack for texture uploads "got lost", but I think I'm happy with that going away anyway since DR almost fully deprecates it, and it's not the "right thing" anyway - but instead an nvidia-only hack to make this stuff work somewhat better on NUMA systems with discrete GPUs. Another change is that due to the way fencing works with ra_buf (we get one fence per ra_buf per upload) we have to use multiple ra_bufs instead of offsets into a shared buffer. But for OpenGL this is probably better anyway. It's possible that in future, we could support having independent “buffer slices” (each with their own fence/sync object), but this would be an optimization more than anything. I also think that we could address the underlying problem (memory closeness) differently by making the ra_vk memory allocator smart enough to chunk together allocations under the hood.
* vo_opengl: make blitting an explicit capabilityNiklas Haas2017-08-181-3/+6
| | | | | | | | | Instead of merging it into render_dst. This is better for vulkan, because blitting in vulkan both does not require a FBO *and* requires a different image layout. Also less "hacky" for OpenGL, since now the weird blit=FBO requirement is an implementation detail of ra_gl
* vo_opengl: fix incorrect glBindFramebuffer() callwm42017-08-151-1/+1
| | | | Used the wrong binding.
* vo_opengl: fix dangling pointers when VAOs are not availablewm42017-08-151-2/+2
| | | | | | | | | | This is for legacy GL: if VAOs are not available, the helper has to specify vertex attributes again on every rendering. gl_vao_init() keeps the vertex array for this purpose. Unfortunately, a temporary argument was passed to the function, instead of the permanent copy. Also, it didn't use num_entries (instead expected the array being terminated by a {0} entry). Fix that source code indentation too.
* vo_opengl: handle probing GL texture formats betterwm42017-08-111-6/+43
| | | | | | | | | | | | | | | | | | Retrieve the depth for each component and internal texture format separately. Only for 8 bit per component textures we assume that all bits are used (or else we would in my opinion create too many probe textures). Assuming 8 bit components are always correct also fixes operation in GLES3, where we assumed that each component had -1 bits depth, and this all UNORM formats were considered unusable. On GLES, the function to check the real bit depth is not available. Since GLES has no 16 bit UNORM textures at all, except with the MPGL_CAP_EXT16 extension, just drop the special condition for it. (Of course GLES still manages to introduce a funny special case by allowing GL_LUMINANCE , but not defining GL_TEXTURE_LUMINANCE_SIZE.) Should fix #4749.
* vo_opengl: move strictly private ra_gl structs to .c filewm42017-08-111-0/+35
| | | | So that nothing accidentally accesses these.
* vo_opengl: separate hwdec context and mapping, port it to use rawm42017-08-101-76/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
* vo_opengl: go back to using GL_TIME_ELAPSEDNiklas Haas2017-08-081-16/+25
| | | | | | | | Less flexible than GL_TIMESTAMP but supported by more platforms. This will mean that nested queries have to be detected and silently omitted, but oh well. Not much use for them anyway. Fixes #4721.
* vo_opengl: don't call glGetProgramBinary if GL_PROGRAM_BINARY_LENGTH==0wm42017-08-081-2/+4
| | | | Noticed in #4717, although the issue might be about something else.
* client API: more opengl_cb clarificationswm42017-08-071-1/+1
| | | | Also fix a typo in ra_gl.c. Too greedy for a separate commit.
* vo_opengl: add another ra_format field to exclude insane formatswm42017-08-071-0/+1
| | | | | | Generic description of pixel formats is hard. In this case, the Apple special format for packed YUV could have been interpreted as a RGB format with funny packing.
* vo_opengl: further GL API use separationwm42017-08-071-4/+48
| | | | | | | | | | | | | | | Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
* vo_opengl: fix minor memory leakwm42017-08-071-1/+4
| | | | Don't leak the buffer if glGetProgramBinary() fails.
* vo_opengl: nuke ra_gl->first_runNiklas Haas2017-08-071-6/+12
| | | | | | Completely unnecessary, we can just update the uniforms immediately after creating the program. In theory, for GLSL 4.20+, we could even skip this, but oh well.
* vo_opengl: simplify mirroring and fix it if glBlitFramebuffer is usedwm42017-08-071-5/+2
| | | | | | | | | | | | | | | | | | The vp_w/vp_h variables and parameters were not really used anymore (they were redundant with ra_tex w/h) - but vp_h was still used to identify whether rendering should be done mirrored. Simplify this by adding a fbodst struct (some bad naming), which contains the render target texture, and some parameters how it should be rendered to (for now only flipping). It would not be appropriate to make this a member of ra_tex, so it's a separate struct. Introduces a weird regression for the first frame rendered after interpolation is toggled at runtime, but seems to work otherwise. This is possibly due to the change that blit() now mirrors, instead of just copying. (This is also why ra_fns.blit is changed.) Fixes #4719.
* vo_opengl: generalize ra_buf to support other buffer objectsNiklas Haas2017-08-071-37/+70
| | | | | This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
* vo_opengl: drop ra_gl.h from shader_cache.cNiklas Haas2017-08-061-0/+1
| | | | | | Since the GL *gl is no longer needed for the timers, we can get rid of the sc->gl dependency. This requires moving a utility function (which is not GL-specific anyway) out of gl_utils.h and into utils.h
* vo_opengl: move timers to struct raNiklas Haas2017-08-061-0/+73
| | | | | | | In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
* vo_opengl: ra_gl: make getting GL ptr slightly less tediouswm42017-08-051-35/+20
|
* vo_opengl: move shader handling to rawm42017-08-051-1/+381
| | | | | | | | | | | | | Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
* vo_opengl: organize ra PBO flag slightly differentlywm42017-08-051-1/+1
| | | | | | | | Instead of having a mutable ra_tex field (and the only one), move the flag to struct ra, since we have only 2 tex_upload user calls anyway, and both want the same PBO behavior. (At first I considered making it a RA_TEX_UPLOAD_ flag, but why bother. PBOs are a terribly GL-specific thing, so we can't expect a reasonable abstraction of it anyway.)
* vo_opengl: make OSD code use ra for textureswm42017-08-051-3/+13
| | | | | | | | | | | | This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
* vo_opengl: restore OSX "old" hwdecwm42017-08-051-1/+1
| | | | Probably. Untested.
* vo_opengl: pass ra objects during rendering instead of GL objectswm42017-08-051-3/+154
| | | | | | | | | Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
* vo_opengl: make fbotex helper use rawm42017-08-051-2/+35
| | | | | | | | Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
* vo_opengl: use GL_CLIENT_STORAGE_BIT for DRNiklas Haas2017-08-031-1/+1
| | | | | | | | | mesa won't pick client storage unless this bit is set, and we *absolutely* want to be using client storage for our DR PBOs. Performance is shit on AMD otherwise. (Nvidia always uses client storage for persistent coherent buffers whether you tell it it or not, probably because it's way faster and nvidia doesn't trust users to figure that out on their own)
* vo_opengl: remove unused ra_mapped_buffer.preferred_align fieldwm42017-08-031-1/+0
| | | | | | | | | | | It makes no sense to have this on an already created buffer. If anything, the ra backend would have to export this as a global value (e.g. struct ra field), so that whatever allocates the buffer can account for the required alignment. Since this code is in vo_opengl.c in the first place, and since GL doesn't dictate any special alignment here, it doesn't make sense in the first place to export this. (Maybe something like this will be required later.)
* vo_opengl: manage dither texture via rawm42017-07-291-3/+8
| | | | | | | | | Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
* vo_opengl: use ra_* for format negotiation toowm42017-07-291-0/+3
| | | | | | | | | | | | | Format handling via ra_* was added earlier, but the format negotiation part was forgotten. Actually move some aspects of it to ra_get_imgfmt_desc(). Also make sure the unorm and float formats selected by the common format lookup functions are linear filterable. (For OpenGL, this is implicitly guaranteed, so it wasn't done before.) Whether these assumptions should be checked/enforced in the ra code at all is a bit fuzzy, but with ra being helper code only for the actual video renderer, it's probably justified.
* vo_opengl: start work on rendering API abstractionwm42017-07-261-0/+290
This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-08 20:29:05 +0000