Vulkan revision 2 #4933

haasn · 2017-09-29T02:59:18Z

This improves on the major shortcomings of the ver1 design and enables full use of async transfers, async compute, multi-command queueing, event-based image barriers, safe FBO invalidation, better implicit renderpass layout transitions and more (tm).

It turns out that the VkSemaphore deadlock issue was an nvidia driver bug. This approach works after all, and scales well - especially now that I've refactored it to avoid using VkSemaphores for intra-frame dependencies as much as possible. There is now virtually no performance drop as a result of this refactor even without the fancy async transfer stuff. (And with async transfer on top, the performance goes through the roof again)

I probably won't actually merge this until the fixes for the nvidia deadlock issue make it into an actual driver release, but it would be good to get some testing (on other platforms) and code review out of the way.

NOTE: This is still not entirely optimal. Improvement avenues:

Try and avoid over-abusing CONCURRENT sharing mode (hard)
Try and avoid using VkEvents in trivial scenarios (instead use pipeline barriers). (trivial)
Try recreating VkSemaphores and re-using the VkEvents instead for already-submitted signals. (trivial)
Try improving the logic for when to split the command buffers to maximize performance. (easy-ish but annoying)
Try updating buffers from different queues depending on their type. (medium)
Try and use LOAD_OP_CLEAR to clear color attachments instead of doing the stupid 1x1 blit / vkClear thing. (easy-medium)
Allow recording timestamps from the COMPUTE queue as well as the GRAPHICS queue, to avoid over-submitting tiny command buffers. This should especially help for async compute. (easy)

And probably more that I've forgotten. Let the hate commence!

haasn · 2017-09-29T14:20:51Z

Try and use LOAD_OP_CLEAR to clear color attachments instead of doing the stupid 1x1 blit / vkClear thing. (easy-medium)

Gave this a try but it was slower on nvidia. And I actually have no idea why, because even just uncommenting the clear() call made it slower; probably because it drops the implicit invalidation on the framebuffer, but despite this it was still slower even if I force-invalidated in pass_draw_to_screen.

Still needs testing on AMD I suppose.

haasn · 2017-09-30T21:45:11Z

The test feedback so far has been very positive for windows; and also works great on nvidia, and the official AMD drivers. It also fixes some issues people were having, and makes it faster and more responsive.

RADV/mesa is the only platform that doesn't seem to like it; but I don't think that will hold us back. (Maybe merging it into master will give mesa some motivation to fix the issues?)

haasn · 2017-10-07T19:40:21Z

Rebased. I've also added an option to disable async transfer/compute, mainly for debugging purposes, but also because they seem to be unstable on some drivers (async compute in particular).

haasn · 2017-10-09T23:05:59Z

Nvidia driver version is out and should include the bug fixes for this. With async compute disabled by default it also avoids crashes on several other drivers.

I'd be happy to merge it in this form. @wm4 ?

haasn · 2017-10-16T18:39:57Z

Clang just pointed out a fairly glaring issue in the sharing mode initialization for allocated buffers. In theory, that might have explained some of the issues with async transfer/compute on devices where it led to issues.

(Although probably the only affected buffers are texture upload buffers)

haasn · 2017-10-16T19:08:21Z

(Although probably the only affected buffers are texture upload buffers)

Actually, I'm not even sure if they're affected. I think the only case that was affected were updates for uniform buffers, because UBO buffers are always updated from the graphics queue (for stupid reasons) even when using them with compute shaders.

So that actually makes sense when you think about the async compute stuff. Hopefully this fixed it? If users could try with the above fix and --async-compute again I'd be very grateful.

haasn · 2017-10-25T17:33:50Z

Found and fixed some bugs relating to image synchronization, thanks to a vulkan validation layers update. It's possible that this fixes the crashing on some devices. Testing desired.

aufkrawall · 2017-10-28T14:28:27Z

Does --vulkan-async-compute work for anyone? With Pascal and 387 drivers, I get "device timeout" errors on Windows and it semi-freezes the whole system on Linux.
(But I guess there won't be any performance wins anyway with Pascal if it's compareable to games.)

haasn · 2017-10-28T14:33:18Z

@aufkrawall Can you test with 4a19ae5?

aufkrawall · 2017-10-28T15:00:27Z

It's fixed now (tested on Linux). It doesn't have an influence on the reported frame timings though, GPU usage reported by the driver is also roughly the same.
Do GCN GPUs already perform better with it?

haasn · 2017-10-30T18:28:04Z

@aufkrawall I don't know of any GCN results, but I've heard reports from a user that said async-compute bumped FPS from 520 to 550 on a 1080 Ti.

Apparently the latest round of fixes, plus the new nvidia driver version, means -rev2 will no longer crash or deadlock on windows nvidia. (I still have one swapchain hang on linux nvidia but I suspect a driver bug here as well, since it matches the pattern of the other swapchain-related issues)

Don't know if any AMD Windows users have tested this version. Mesa still doesn't work.

Artoriuz · 2017-10-30T19:10:08Z

I have a RX470 and I'm currently using Windows.

The last time I tried to test the difference on a 540p AVC file (decodes fast) with gpu-hq + ravu-r4 + adaptive-sharpen (just to increase the GPU load), with --vulkan-async-compute and --vulkan--queue-count=3 I got around 490 fps. Without --vulkan-async-compute and --vulkan--queue-count=3 I got around 515 fps.

I could time how long it takes to reach 1min mark or something in both cases, I feel that with async-compute turned on the minimums are higher, but I could be wrong.

AstralStorm · 2017-11-04T19:57:55Z

It is actually broken on Linux and amdgpu-pro when running color conversion. (At least yuv420.)
Valgrind suggests an overrun in mpv code, but couldn't pinpoint it despite full debug info. All thanks to amdgpu-pro not having debug symbols. RGB works more or less fine on that ICD.
(Yes, still kills radv.)

haasn · 2017-11-04T21:51:58Z

@AstralStorm: What does ‘broken’ mean in this context?

sl1pkn07 · 2017-11-05T15:43:53Z

Hi. please rebase, patch failed when apply the PR in master (wscript)

AstralStorm · 2017-11-05T22:12:03Z

@haasn Crashing on surface swap regardless of sync or async or compute mode.

haasn · 2017-11-05T22:19:57Z

@AstralStorm: backtrace? log?

AstralStorm · 2017-11-05T22:40:40Z

Backtrace is useless due to lack of symbols. (Cannot trace back from ICD.) It crashes on the second real frame swap of youtube yuv420 videos (h264). I will provide the log soon.
Reproducible 100% of time (10/10, various videos) with no config, no options other than x11vk and gpu target.

haasn · 2017-11-07T02:50:26Z

@sl1pkn07 rebased; somebody decided to make the same change to mpv master as one of the commits in this PR but did it slightly differently, which was the reason for the conflict...

Untested (ffmpeg master still doesn't work with mpv)

haasn · 2017-11-07T02:51:50Z

@AstralStorm can you reproduce it from inside gdb, and maybe step through the function submit_frame from vulkan/context.c? (or just break on ra_vk_submit and go from there)

sl1pkn07 · 2017-11-07T18:52:00Z

Hi

seems this d98c538, the first hunk, is applied

or patch the PR see it

Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file DOCS/man/options.rst.rej
patching file video/out/vulkan/context.c
patching file video/out/vulkan/ra_vk.c

also conflicts in video/out/gpu/ra.h

the patch is applied in clean clone

greetings

1. No more static arrays (deps / callbacks / queues / cmds) 2. Allows safely recording multiple commands at the same time 3. Uses resources optimally by never over-allocating commands

Instead of associating a single VkSemaphore with every command buffer and allowing the user to ad-hoc wait on it during submission, make the raw semaphores-to-signal array work like the raw semaphores-to-wait-on array. Doesn't really provide a clear benefit yet, but it's required for upcoming modifications.

haasn · 2017-12-09T20:54:03Z

At least one of the radeon developers is looking into the issue with amdgpu and some generations of AMD GPUs; but for the meantime, disabling the use of async transfer avoids triggering the stall (which happens when attempting a buffer->image copy from the compute queue).

DeadSix27 · 2017-12-09T21:09:07Z

@haasn Is he a developer from radeon ? If so, leave a comment about the weird exclusive fullscreen issue.

aufkrawall · 2017-12-09T21:28:50Z

Are you using Windows 10 Creators Update 2? It should by default force every fullscreen application into "direct borderless" mode (which should be what you want), unless you disabled that in the Windows compatibility options for mpv.exe.
I wouldn't bet AMD changes the behavior when this is basically already done by a recent Win 10 version.

DeadSix27 · 2017-12-09T21:46:59Z

@aufkrawall You mean this?:
I tried it on/off, no change.

jeeb · 2017-12-10T16:11:52Z

@Artoriuz I did poke @haasn about this a couple of days ago and it seemed like he wanted to wait for the amdgpu fixes, but I might have understood him wrong. As long as this has close to zero effect on anything else I'd just take this in since vulkan has more or less been experimental in mpv so far as well.

aufkrawall · 2017-12-10T18:54:17Z

For me it worked absolutely reliably so far on Nvidia Pascal (Windows 10/Arch Linux) and Intel Skylake (Arch Linux) so far, except of that async compute segfault which haasn fixed. :)

haasn · 2017-12-10T20:59:42Z

@jeeb I'd take it in as-is since we've hit a stalemate in the bug fixing process. I can't find any more issues (apart from the ones I discovered while re-analysing/rewriting this code for libplacebo); so anything remaining would need investigation from driver devs or improvements to the debugging layers.

One thing I'm sort of wishing we could do is make the use of VkEvents (which is the major addition of this patch) optional as well, but since you can also work around the issues by using --vulkan-async-transfer=no on affected devices it's not that critical.

kevmitch · 2017-12-13T22:08:02Z

Here are my testing results:

Intel Ivy Bridge, mesa 17.2.5, linux 4.7.10. Running --no-config --deband=yes --video-sync=display-resample. Not sure if we care about this platform, since with both revisions, the driver prints WARNING: Ivy Bridge Vulkan support is incomplete and also

../../../src/intel/vulkan/gen7_cmd_buffer.c:273: FINISHME: Implement events on gen7
../../../src/intel/vulkan/gen7_cmd_buffer.c:297: FINISHME: Implement events on gen7

but it actually seems to mostly work in both rev1 and rev2 other than high CPU usage of about 80% of one core.

The average redraw time (as indicated by stats.lua) is increased with rev2 although the fresh draw time is slightly lowered.

vulkan_rev1: 13 ms draw / 3 ms redraw (log, stats)
vulkan_rev2: 12 ms draw / 11 ms redraw (log, stats)

I also see lots of [vo/gpu] Error: texture could not be created. that were not previously there in rev1. Interestingly this no longer appears if I switch my refresh rate down to 24fps. This also seems to go away if i turn off display sync or debanding.

None of this seems to be affected by the various permutations of --vulkan-async-transfer and --vulkan-async-compute .

haasn · 2017-12-13T23:15:00Z

@kevmitch The timers are unreliable with rev2. Can you try using --profile=bench?

kevmitch · 2017-12-15T01:01:39Z

base

rev2 is 3% faster

--no-config --gpu-api=vulkan --audio=no --untimed --video-sync=display-desync --vulkan-swap-mode=immediate --opengl-swapinterval=0 --osd-msg1="FPS: \${estimated-display-fps}" --fs

vulkan-rev2: 370fps log, stats
vulkan-rev1: 360fps log, stats

deband

rev2 is 20% slower

--no-config --gpu-api=vulkan --deband --audio=no --untimed --video-sync=display-desync --vulkan-swap-mode=immediate --opengl-swapinterval=0 --osd-msg1="FPS: \${estimated-display-fps}" --fs

vulkan-rev2: 180fps log, stats
vulkan-rev1: 220fps log, stats

Again, vulkan-async-compute and vulkan-async-transfer seem to have no measureable effect.
I wanted to compare with opengl, but it appears --opengl-swapinterval=0 doesn't actually work in my case as it's stuck to my oddball display fps of 59.68.

jeeb · 2017-12-15T01:11:10Z

OK. Took a general look at this whole thing and then tried to focus on the effects it could have on the other renderers since there was limited touching of generic files included.

Linux+wayland+opengl: builds & works on a X230 (similar Ivy Bridge to @kevmitch). Vulkan builds but as I lack shaderc there's nothing to generate SPIR-V for mesa :) .
Windows+gpu contexts {d3d11,angle,win} with and without dxva2-copy or d3d11va hw decoders: all seems good. Didn't yet build Vulkan as it seems like more patching is required for the Kronos stuff, but will do that after I get some sleep.
Didn't yet test android but highly likely to have not been changed.

Otherwise the biggest thought I got after looking at the code was:

Is bool discard is good enough of a name, or should it be bool discard_texture or something? Additionally, the value gets right away set to a variable called invalidate_target.

Thus, I have very minimal concerns (although I'm still interested in the logic behind the parameter grouping in those functions where the new parameters were added). Additionally ran some static analysis on the current master with vulkan_r2 rebased on top. There are some warnings from vulkan-related files but not sure if those have anything to do with code changed in this PR.

tl;dr Looking pretty good as far as I'm generally concerned.

haasn · 2017-12-15T03:39:26Z

Again, vulkan-async-compute and vulkan-async-transfer seem to have no measureable effect.

From your log, your device only supports a graphics queue, so those options do nothing on your device. Maybe we should make these options tristate (yes, no, auto) and print a warning if the user sets it to yes when the hardware has no support?

The 20% performance loss in rev2+deband is probably connected to the error message spam (“Error: texture could not be created”). Can you investigate this? Which line throws the error, and where does the error value come from? Can you try using --vulkan-debug as well? Since you said it doesn't happen with lower FPS or without DS, my gut feeling tells me we might be exhausting your VRAM?

P.s. Intel supports neither events nor async queues nor implicit image barriers, so I don't expect rev2 and rev1 to be any different performance-wise if everything is behaving correctly.

Edit: I compared the logs (via grep Allocating) and came to the conclusion that the same amount of VRAM is allocated up to the point where the error happens. It must be caused by something else, but what concerns me is that there's no vulkan error logged. (Normally, a failed vulkan call will print out the exact error code. There is no such print-out in this case, so the error source doesn't appear to be from a vulkan driver call)

haasn · 2017-12-15T03:43:22Z

Thus, I have very minimal concerns (although I'm still interested in the logic behind the parameter grouping in those functions where the new parameters were added). Additionally ran some static analysis on the current master with vulkan_r2 rebased on top. There are some warnings from vulkan-related files but not sure if those have anything to do with code changed in this PR.

Reposting my comments from IRC

04:16 <hanna> 22:38 <JEEB> hanna: and basically ra_renderpass_params gets zero-allocated? <- yeah, most of those _params structs are designed such that {0} is the “default”
04:17 <hanna> (except where something is non-optional)
04:17 <hanna> 00:42 <JEEB> hanna: lol would shaderc give me SPIR-V for vulkan on intel? :D <- yes that's the idea
04:19 <hanna> JEEB: I think you can safely ignore all of the MP_TARRAY_APPENDs as false positives
04:43 <hanna> 22:13 <JEEB> hanna: also lol at gl_sc_dispatch_draw getting a new param in the middle of it. is there a reasoning for that positioning (base variables to more specific stuff)? <- 1. it fits neatly (80col), 2. it semantically belongs to the `target`, so it should go next to it anyway

kevmitch · 2017-12-15T06:07:02Z

Which line throws the error

    vo/gpu: Error: texture could not be created.

Thread 11 "mpv/vo" hit Breakpoint 1, ra_tex_resize (ra=0x7fffbc4d0780, log=0x5555574ce020, 
    tex=0x7fffbc5626d0, w=650, h=352, fmt=0x7fffbc4d13e0) at ../video/out/gpu/utils.c:207
207             mp_err(log, "Error: texture could not be created.\n");
(gdb) bt
#0  ra_tex_resize (ra=0x7fffbc4d0780, log=0x5555574ce020, tex=0x7fffbc5626d0, w=650, h=352, 
    fmt=0x7fffbc4d13e0) at ../video/out/gpu/utils.c:207
#1  0x00005555557a6886 in gl_video_render_frame (p=0x7fffbc562270, frame=0x7fffbc6a7b50, fbo=...)
    at ../video/out/gpu/video.c:3067
#2  0x00005555557b8575 in draw_frame (vo=0x5555574c5fe0, frame=0x7fffbc6a7b50) at ../video/out/vo_gpu.c:88
#3  0x00005555557b55f1 in render_frame (vo=0x5555574c5fe0) at ../video/out/vo.c:866
#4  vo_thread (ptr=0x5555574c5fe0) at ../video/out/vo.c:970
#5  0x00007fffec7b4519 in start_thread (arg=0x7fffd8ff9700) at pthread_create.c:456
#6  0x00007ffff2deda4f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

ultimately because video/out/vulkan/ra_vk.c:vk_tex_create:549

    VkResult res = vkGetPhysicalDeviceImageFormatProperties(vk->physd,
            fmt->iformat, tex_vk->type, VK_IMAGE_TILING_OPTIMAL, usage, 0,
            &iprop);
    if (res == VK_ERROR_FORMAT_NOT_SUPPORTED) {
        return NULL;

where fmt->name == "bgra8"

Can you try using --vulkan-debug as well?

Error parsing option vulkan-debug (option not found)
Setting commandline option --vulkan-debug= failed.

Are you talking about this: https://gpuopen.com/using-the-vulkan-validation-layers/ ?

my gut feeling tells me we might be exhausting your VRAM?

how do I measure this?

sl1pkn07 · 2017-12-15T07:11:49Z

how do I measure this?

If you have nvidia, with nvidia-smi, or nvidia-settings

haasn · 2017-12-15T09:32:52Z

Error parsing option vulkan-debug (option not found)

Sorry, the option name is --gpu-debug not --vulkan-debug. (Maybe this should be split up into vulkan and opengl?)

The stack trace helps. Can you paste the output of vulkaninfo?

kevmitch · 2017-12-15T09:56:13Z

vulkaninfo

rev2 --gpu-debug: log, stats

(Maybe this should be split up into vulkan and opengl?)

I think it's fine as one option. It's doing the same high level thing. Does d3d11 have an equivalent?

jeeb · 2017-12-15T10:07:19Z

Just tested and --gpu-debug works with d3d11 as well :) First seeing the GPU leak check, too.

haasn · 2017-12-15T13:10:20Z

@kevmitch The issue in your case is the fact that in mpv we universally try and enable storage image support for our intermediate FBOs, but your device doesn't support storage images on the bgra8 fbo format. The bgra8 texture format is used for the cache FBO because it's the same as your swapchain format. This is different compared to rev2 due to commit 9789bac.

This also explain the performance loss - your redraws are not getting cached as a result, since it fails creating the cache FBO. This should not cause any issues apart from the performance loss and the spammed error message. (Maybe we remember a failure here?)

The proper solution is to expand ra_format in order to allow the ra_tex_resize code to know whether the format is storable or not. This is done in libplacebo, but backporting it to mpv will require some work (partly because of the awful OpenGL texture format semantics).

The next-best half-baked work-around would be to add a flag to ra_tex_resize indicating whether we want to use it as a storage image or not. (The cache FBO is never used as a storage image). But this would just work around your specific issue - it doesn't completely eliminate the bug, since it's still possible we might run into cases of trying to make storable FBOs with a non-storable fbo-format in general, even if we revert the commit 9789bac. The root problem here is the fact that mpv's RA can't express the circumstance where some FBO formats are storable and others are not. In fact, you can probably reproduce a similar bug with OpenGL by picking some obscure fbo-format.

haasn · 2017-12-15T13:11:37Z

Anyway, I wouldn't mind merging this without commit 9789bac and leaving that commit to a later date. That way this at least isn't a regression; i.e. the only bugs related to non-storable FBO formats are also bugs in master.

jeeb · 2017-12-15T13:25:00Z

If we know the limitations of the current setup I do not consider this a deal-breaker, given that my understanding is that something is planned to be done about it (which might of course be incorrect). Better to not shake the pack too much compared to what has already gone through a relative amount of testing.

@kevmitch , what's your opinion?

kevmitch · 2017-12-15T22:53:14Z

I reverted the commit and indeed got a slight improvement over rev1

rev2 deband without 9789bac: 225fps log, stats

There are also no more texture could not be created messages. However, with --gpu-debug I now see a steady stream of vulkan warnings that were not present before reverting 9789bac:

[vo/gpu/vulkan] vk [DS] 10: Source AccessMask 0 [None] must have required access bit 2048 [VK_ACCESS_TRANSFER_READ_BIT]  when layout is VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL, unless the app has previously added a barrier for this transition. (obj 0x7f4f30773940 (VkCommandBuffer), loc 0xa93)

kevmitch · 2017-12-25T00:05:02Z

well shit

airlied · 2017-12-28T06:46:18Z

Just FYI I posted a radv patch to fix the compute bugs on it, should be in master and next stable release.

aufkrawall · 2018-01-07T20:09:28Z

It's indeed working nicely here with Linux 4.15, mesa-git and RX 560.
Also gpu-queue-count 3 + async compute works.

According to render stats, async compute gives a massive performance boost (~4.5ms vs. ~14.5ms). Can that be real?
Edit: To be more specific: AC + queue count > 1.
I already forced GPU into maximum clocks because the automatic clock adjustment of amdgpu doesn't work correctly for mpv.

With or without AC, I can run higher settings than with OGL. Kudos, haasn (and David Airlie ;) )!

aufkrawall · 2018-01-14T14:34:39Z

Ok, I used the more reliable benchmark method described by haasn in his blog (also added vsync off for D3D11). I don't have the concrete numbers anymore, but I checked everything several times, so I think my conclusions should be really reliable for my testcase (scaling down 4k 60fps 8 bit and 4k 50fps 10 bit to 1440p).

On Windows, Vulkan can have huge gains over D3D11 (~12%). This seems especially true with 10 bit content (much > than 12%).
With the Windows driver, async compute can show small gains (~5%) with certain workloads (e.g. cscale=catmull_rom + dscale=ewa_lanczossharp). This is also true with AMD's amdvlk on Linux.
RadV doesn't seem to show any gains by AC. All drivers show a small loss with AC on when the workload doesn't seem optimal (too little graphics queue load?).
However, RadV without AC is also faster than OpenGL when there is enough compute shader load.
With all drivers, a queue count of 2 instead of 1 is a bit beneficial, but mostly with AC when AC is beneficial.
On Windows, Vulkan significantly improves performance with D3D11VA-copy over D3D11, but is not faster than D3D11 + native D3D11VA (I suppose it would be awesome with a D3D11VA interop for Vulkan)
Unlike RadV, amdvlk on Linux Xorg seems to have broken Vsync, I also noticed this in vkquake

You btw. still need mesa-git, Mesa 17.3.2 still hangs system with RadV + mpv.

ghost · 2018-01-14T14:39:04Z

On Windows, Vulkan significantly improves performance with D3D11VA-copy over D3D11, but is not faster than D3D11 + native D3D11VA (I suppose it would be awesome with a D3D11VA interop for Vulkan)

I wonder if it'd be worth to do the hardware copy into Vulkan DR memory...

aufkrawall · 2018-01-14T20:52:54Z

I could also do the same test on a Windows 10 machine with a GTX 1060, also here Vulkan was faster than D3D11.
At least with d3d11va-copy, which I had to use to avoid CPU limitation due to software decoding.
However, with Pascal Async Compute can severely hurt performance when using ewa_lanczos for both cscale and dscale at the same time while it also doesn't show any gains otherwise.

aufkrawall · 2018-01-19T15:58:34Z

RadV now works with Mesa 17.3.3. There is tearing in Xorg windowed, but not fullscreen.
Luckily, Compton vsync seems to "fix" windowed, it looks absolutely smooth to me with interpolation.

haasn force-pushed the vulkan-rev2 branch from dac6360 to eb0db67 Compare September 29, 2017 14:00

haasn force-pushed the vulkan-rev2 branch from eb0db67 to 33973dc Compare September 29, 2017 14:55

haasn force-pushed the vulkan-rev2 branch from f9a99d0 to 584edbc Compare October 7, 2017 19:40

haasn force-pushed the vulkan-rev2 branch from 0a58165 to 9c1f212 Compare October 17, 2017 22:27

haasn force-pushed the vulkan-rev2 branch from 9c1f212 to 3b5a13b Compare October 25, 2017 17:33

haasn force-pushed the vulkan-rev2 branch from 3b5a13b to 4a19ae5 Compare October 28, 2017 14:04

haasn force-pushed the vulkan-rev2 branch from 4a19ae5 to 11a1d28 Compare November 7, 2017 02:49

haasn added 2 commits November 8, 2017 05:52

vo_gpu: vulkan: refactor vk_cmdpool

26f4d2c

1. No more static arrays (deps / callbacks / queues / cmds) 2. Allows safely recording multiple commands at the same time 3. Uses resources optimally by never over-allocating commands

mia-0 merged commit d588bda into mpv-player:master Dec 24, 2017

Vulkan revision 2 #4933

Vulkan revision 2 #4933

Conversation

haasn commented Sep 29, 2017 • edited

haasn commented Sep 29, 2017

haasn commented Sep 30, 2017

haasn commented Oct 7, 2017

haasn commented Oct 9, 2017

haasn commented Oct 16, 2017

haasn commented Oct 16, 2017

haasn commented Oct 25, 2017

aufkrawall commented Oct 28, 2017

haasn commented Oct 28, 2017

aufkrawall commented Oct 28, 2017

haasn commented Oct 30, 2017

Artoriuz commented Oct 30, 2017

AstralStorm commented Nov 4, 2017

haasn commented Nov 4, 2017

sl1pkn07 commented Nov 5, 2017 • edited

AstralStorm commented Nov 5, 2017

haasn commented Nov 5, 2017

AstralStorm commented Nov 5, 2017 • edited

haasn commented Nov 7, 2017

haasn commented Nov 7, 2017

sl1pkn07 commented Nov 7, 2017

haasn commented Dec 9, 2017

DeadSix27 commented Dec 9, 2017

aufkrawall commented Dec 9, 2017

DeadSix27 commented Dec 9, 2017

jeeb commented Dec 10, 2017

aufkrawall commented Dec 10, 2017

haasn commented Dec 10, 2017

kevmitch commented Dec 13, 2017

haasn commented Dec 13, 2017 • edited

kevmitch commented Dec 15, 2017

base

deband

jeeb commented Dec 15, 2017

haasn commented Dec 15, 2017 • edited

haasn commented Dec 15, 2017

kevmitch commented Dec 15, 2017

sl1pkn07 commented Dec 15, 2017

haasn commented Dec 15, 2017

kevmitch commented Dec 15, 2017

jeeb commented Dec 15, 2017

haasn commented Dec 15, 2017

haasn commented Dec 15, 2017

jeeb commented Dec 15, 2017

kevmitch commented Dec 15, 2017

kevmitch commented Dec 25, 2017

airlied commented Dec 28, 2017

aufkrawall commented Jan 7, 2018 • edited

aufkrawall commented Jan 14, 2018 • edited

ghost commented Jan 14, 2018

aufkrawall commented Jan 14, 2018 • edited

aufkrawall commented Jan 19, 2018

haasn commented Sep 29, 2017 •

edited

sl1pkn07 commented Nov 5, 2017 •

edited

AstralStorm commented Nov 5, 2017 •

edited

haasn commented Dec 13, 2017 •

edited

haasn commented Dec 15, 2017 •

edited

aufkrawall commented Jan 7, 2018 •

edited

aufkrawall commented Jan 14, 2018 •

edited

aufkrawall commented Jan 14, 2018 •

edited