![]() When I want the check the Maxwell GPU in this link:ĭo I see 3 different versions of Maxwell's 1st Gen, 2nd Gen or GM206. Here I read under TESLA M60 FEATURES AND BENEFITS I found this link on your NVIDIA Tesla M60 GPU: If the paid Studio version supports hardware encode/decode, how can I evaluate the impact of this on performance?Ĭbjoex wrote:Perhaps what Dwaine is trying to tell me is that the free version doesn't support hardware encode/decode while Studio does? Or there an obscure setting somewhere that I have overlooked, or is hardware encoding and decoding only supported in the Studio version? Is there a reason why DaVinci Resolve does not support GPU hardware video decode/encode? Also, unlike PowerDirector, in Resolve I can find no option to use hardware encoding or decoding. (In my opinion, Resolve also under-utilises the available CPU resources.)įor comparison, both PowerDirector and Premiere do use the hardware encoding features of this high-end video processing GPU, and in the resource graph on Task Manager these features are clearly being used significantly, for projects with the same source files and the same output video format and comparable effects and transitions. DaVinci Resolve does, however, utilise the CUDA or OpenCL capabilities of the GPU. ![]() I have demonstrated that the software does not utilise either the hardware encoding or the hardware decoding capabilities of the GPU to encode or decode H264 videos. Or you could bundle the IDT and LMT fix into a single DCTL which goes camera log −> ACES2065-1 −> LMT fix −> ACEScct.I'm evaluating DaVinci Resolve on a PC with an NVIDIA M60 GPU. _DEVICE_ float3 transform(int p_Width, int p_Height, int p_X, int p_Y, float p_R, float p_G, float p_B)Īces = LMT_FixHighlightImageArtifacts(aces) #include "ACES_LIB/ACES_CSC/ACES_Conversion.h" Something like the following (untested) code: #include "ACES_LIB/ACES_LMT.h" ![]() ![]() If you are using DCTL, you could put it as the first node in the node tree, as long as it is sandwiched between transforms from the working space to ACES2065-1 and back. It really needs to be applied up front, to fix the image data before you do anything else to it. The artefacts happen in the RRT (or at least begin in the RRT and are hit home by the ODT). It absolutely shouldn’t go after the RRT. I can’t figure out what I’m doing wrong.ĭEVICE float3 transform(int p_Width, int p_Height, int p_X, int p_Y, float p_R, float p_G, float p_B)įloat3 aces = make_float3(p_R, p_G, p_B) Ĭan anyone help me figure out what I’m doing wrong?Ĭould we fit it somewhere else in this DCTL workflow? I tried adding it as the first and last nodes, after and before the RRT and after the IDT. So I’m using your ACES_Sample as a reference, so I could create DCTLs for the transform.įor the IDT/ACES_to_ACEScct, it worked well, just like the OFX.įor the ACEScct_to_ACES/RRT/ODT (rec 709), it didn’t. I’ve been trying to work with ACES inside Resolve’s YRGB mode using DCTLs instead of your ACES OFX plugin, as you recommend.Īt first, I tried exporting DCTLs with the proper transforms from the Plugin, but couldn’t due to a permissions issue (even to the default folder).
0 Comments
Leave a Reply. |