An experiment of libplacebo on macOS with MoltenVK #111
Comments
|
Hi, not sure if you saw, but this MR already introduces support for the portability extension. Is that a hard requirement these days? I can try rebasing it on master and merging it. (Also note that master does not use VkEvent at all) The fact that it's still a beta extension is icky. I don't know why they can't get around to making it stable if they already require it for release versions of MoltenVK... Edit: I rebased it onto current master. |
No I didnt check the PR list on gitlab, but I am glad to see that. What about removing the volkan version requirement, at least for macos? What about the graphic issue? |
|
Notice that opengl mode failed too in my first try
Any ideas? |
I could do this. I'm not sure it serves a real purpose anyway, since vulkan 1.1 is ancient. |
|
@CarterLi I updated the MR to drop the vulkan requirement. Can you test if you still get the graphical corruption with that branch? Also, can you test with a more familiar/recognizable source file? (I'm not sure what it's supposed to look like) Finally, can you compile with nuklear and show me the configuration of the UI? (In particular, is it picking a transparent background color? What happens if you change it?)
Nope. Something like an if (!gl_check_err(gpu, "pl_gpu_create_gl: 1")) goto error;Replacing |
Thanks for your quick reply, but I have to test it tomorrow ( in my timezone ) |
|
Some other projects such as ppsspp do use moltenvk on macOS but they dont have such issues Strange |
|
The graphic is still corrupted
The source file can be found here: iina/iina#3539 (comment) |
|
plplay crashed when I was trying to resize the window It didn't crash with sdl2 mode. I don't know if it was a glfw issue or plplay issue. It's constantly reproducible |
Seems that this line is problematic Line 176 in 93d05c4 |
|
It works fine on my end.
Build Configuration
But sometimes it shows me this error: error message |
Looks like a GLFW issue. Our usage of the GLFW API is not exactly complex. Simply calling
Thanks, will fix. |
Pushed a fix for it. Wonder how far OpenGL gets for you now? |
haasn
added a commit
that referenced
this issue
Nov 19, 2021
Prevents UB on pl_plane_find_fmt() when comparing the row stride against the texel alignment. cf. #111
Should be fixed as well. |
Not getting any error now. Thanks. |
We'd better give up |
|
More info about the graphic issue The corrupted image was displayed outside the video image, which depended on the radio of window width / height The graphic was initially normal, then became corrupted after my video starting to play https://drive.google.com/file/d/1X13Slc8zrauazlaE88fxPClC2pTF3fEX/view?usp=sharing |
|
@CarterLi what about this diff? diff --git a/src/opengl/gpu.c b/src/opengl/gpu.c
index 88583766..2a519ce2 100644
--- a/src/opengl/gpu.c
+++ b/src/opengl/gpu.c
@@ -432,9 +432,9 @@ void gl_buf_write(pl_gpu gpu, pl_buf buf, size_t offset,
return;
struct pl_buf_gl *buf_gl = PL_PRIV(buf);
- glBindBuffer(GL_COPY_WRITE_BUFFER, buf_gl->buffer);
- glBufferSubData(GL_COPY_WRITE_BUFFER, buf_gl->offset + offset, size, data);
- glBindBuffer(GL_COPY_WRITE_BUFFER, 0);
+ glBindBuffer(GL_ARRAY_BUFFER, buf_gl->buffer);
+ glBufferSubData(GL_ARRAY_BUFFER, buf_gl->offset + offset, size, data);
+ glBindBuffer(GL_ARRAY_BUFFER, 0);
gl_check_err(gpu, "gl_buf_write");
RELEASE_CURRENT();
}
@@ -446,9 +446,9 @@ bool gl_buf_read(pl_gpu gpu, pl_buf buf, size_t offset,
return false;
struct pl_buf_gl *buf_gl = PL_PRIV(buf);
- glBindBuffer(GL_COPY_READ_BUFFER, buf_gl->buffer);
- glGetBufferSubData(GL_COPY_READ_BUFFER, buf_gl->offset + offset, size, dest);
- glBindBuffer(GL_COPY_READ_BUFFER, 0);
+ glBindBuffer(GL_ARRAY_BUFFER, buf_gl->buffer);
+ glGetBufferSubData(GL_ARRAY_BUFFER, buf_gl->offset + offset, size, dest);
+ glBindBuffer(GL_ARRAY_BUFFER, 0);
bool ok = gl_check_err(gpu, "gl_buf_read");
RELEASE_CURRENT();
return ok;We should move the OpenGL debugging to a different issue. I still would like to get OpenGL 2.1 working in libplacebo. |
|
@CarterLi I think I know what's going on. This patch should fix it, right? diff --git a/src/vulkan/gpu_pass.c b/src/vulkan/gpu_pass.c
index 53c5d017..53564473 100644
--- a/src/vulkan/gpu_pass.c
+++ b/src/vulkan/gpu_pass.c
@@ -572,13 +572,13 @@ no_descriptors: ;
};
}
- VkAttachmentLoadOp loadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
+ VkAttachmentLoadOp loadOp;
if (pass->params.load_target) {
- if (pass->params.blend_params)
- loadOp = VK_ATTACHMENT_LOAD_OP_LOAD;
pass_vk->initialLayout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
+ loadOp = VK_ATTACHMENT_LOAD_OP_LOAD;
} else {
pass_vk->initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
+ loadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
}
VkRenderPassCreateInfo rinfo = {
@@ -991,7 +991,7 @@ void vk_pass_run(pl_gpu gpu, const struct pl_pass_run_params *params)
.sType = VK_STRUCTURE_TYPE_RENDER_PASS_BEGIN_INFO,
.renderPass = pass_vk->renderPass,
.framebuffer = tex_vk->framebuffer,
- .renderArea = (VkRect2D){{0, 0}, {tex->params.w, tex->params.h}},
+ .renderArea.extent = {tex->params.w, tex->params.h},
};
vk->CmdBeginRenderPass(cmd->buf, &binfo, VK_SUBPASS_CONTENTS_INLINE); |
It works. But HDR mode was not enabled. |
|
I wonder what's faster, performance-wise. We have two options for dealing with partial rendering:
The vulkan specification just gives the nebulous "may cause a performance penalty" for approach 2, but I have no idea how to quantify the costs of I wonder if you're in a position to do benchmarks? |
Works like a charm, great! |
This is known/expected, there's no implementation for HDR switching in OpenGL mode, and no extension for it, so nothing we can do. |
I'd like to help. Any guidelines? |
Not sure myself. I think the best way to benchmark something like this currently is via For the time being I'm going to just not worry about it, I think. |
Off topic. How do you choose colorspace for display to use if a video source doesn't contain mastering display metadata? I'm struggling at this issue: iina/iina#3539 (comment) |
|
For reference, this would be the other way of doing it: (applies onto current master) diff --git a/src/vulkan/gpu_pass.c b/src/vulkan/gpu_pass.c
index 53564473..a12f0b2c 100644
--- a/src/vulkan/gpu_pass.c
+++ b/src/vulkan/gpu_pass.c
@@ -572,10 +572,11 @@ no_descriptors: ;
};
}
- VkAttachmentLoadOp loadOp;
+ VkAttachmentLoadOp loadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
if (pass->params.load_target) {
+ if (params->blend_params)
+ loadOp = VK_ATTACHMENT_LOAD_OP_LOAD;
pass_vk->initialLayout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
- loadOp = VK_ATTACHMENT_LOAD_OP_LOAD;
} else {
pass_vk->initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
loadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
@@ -991,7 +992,7 @@ void vk_pass_run(pl_gpu gpu, const struct pl_pass_run_params *params)
.sType = VK_STRUCTURE_TYPE_RENDER_PASS_BEGIN_INFO,
.renderPass = pass_vk->renderPass,
.framebuffer = tex_vk->framebuffer,
- .renderArea.extent = {tex->params.w, tex->params.h},
+ .renderArea = scissor,
};
vk->CmdBeginRenderPass(cmd->buf, &binfo, VK_SUBPASS_CONTENTS_INLINE); |
|
We'd better removing the version check for |
|
@CarterLi I'm less comfortable doing that, because the shaderc version is non-negligible, and shaderc is a normal library (not like the vulkan SDK which is a horrific abomination). I suggest instead figuring out why version infromation isn't resolving for you. (Try asking meson devs) |
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version:
The process:
mesonfailed to find vulkan.Solved by removing volkan version requirement in
meson.build-Dvulkan-registryspecified ). Ranbuild/demos/plplay -v ~/HDR.webm, I gotNotably
Solved by enabling
VK_KHR_portability_subsetAnd lots of warnings were printed on the console
Solved by enabling
VkPhysicalDevicePortabilitySubsetFeaturesKHR::eventswithFull log
The text was updated successfully, but these errors were encountered: