GTX 1080 Ti with Resolve Part 2

Just thought I would share some of my findings here.

At least in part, Premiere Pro enhances performance by creating "helper" and index files, to facilitate playback. Which is why there's a delay, when you import clips, and gigabyes of files you never knew you had end up deep in directories on your system disk.

Resolve does not create these invisible proxies. What you see is the actual real-time playback of the file you loaded. If you want better performance in the edit tab, then create Optimized Media, and use it as needed, or just transcode to an intra-frame codec, and use those new master clips in all tabs.

There may be room for enhanced long GOP performance in Resolve, I wouldn't know, but asking it to do what Premiere does is demanding it become a different sort of application.

IMHO it is also the chosen shooting codec.

I shoot on an F5 with XAVC in 4K and have no problems with scrubbing smoothly.
Also my time to playback is under 1/2 sec.

However, if I use native Gopro H264 mp4 files, my system is much less responsive.

About 1 sec for playback and quite laggy on scrubbing.

If I have lots of MP4 I transcode to Pro Res.

It does take a bit more time but it's worth it to me.

My 2c.

At least in part, Premiere Pro enhances performance by creating "helper" and index files, to facilitate playback. Which is why there's a delay, when you import clips, and gigabyes of files you never knew you had end up deep in directories on your system disk.

Resolve does not create these invisible proxies. What you see is the actual real-time playback of the file you loaded. If you want better performance in the edit tab, then create Optimized Media, and use it as needed, or just transcode to an intra-frame codec, and use those new master clips in all tabs.

There may be room for enhanced long GOP performance in Resolve, I wouldn't know, but asking it to do what Premiere does is demanding it become a different sort of application.

This is not true at all. Premiere doesn't create any GBs of video helper files (if any then index file are tiny).
All what Premiere sometimes does is audio cached+waveform cache (which can be turned off) as some audio formats (VBR MP3) are problematic to keep sync. This is 32bit uncompressed audio, so for long source it can be fairly big.
I just loaded GH5 MP4 file, straight into timeline, scrub timeline etc- didn't have to wait for anything and my scratch disks doesn't have any GBs of data- actually Premiere created nothing (except some folder which is empty).
What format have you used to see this behaviour? Which Premiere eversion?

Resolve is crazy poor with handling long GOP formats- this is the answer. It's simply unusable with this timeline response for editing Long GOP formats. Only solution is to use optimised media which is waste of time.

Also- if you think Premiere is good with random seeking for long GOP formats try Edius which is another league. It's all down to quality of of the code behind the application, simple as this. Some things in Resolve are good (like debayering part etc) because this was optimised for years. Support for Long GOP formats has been added, just to be there- code is very poor, which you can see and experience.

Try Edius with XAVC- timeline response and seeking will shock you It blows any other NLE in this aspect (but for example it's not any good for RAW source).

This is not true at all. Premiere doesn't create any GBs of video helper files (if any then index file are tiny).

Well, in that case, there either have been vast improvements since I last used Premiere or those files, gigabytes of them, were products of my imagination.

And I am indeed familiar Edius, though I don't recall at this point whether it creates proxies or not. However, given our other difference of opinion on Premiere, it's unlikely we would agree on their presence anyway.

This is not true at all. Premiere doesn't create any GBs of video helper files (if any then index file are tiny).

Well, in that case, there either have been vast improvements since I last used Premiere or those files, gigabytes of them, were products of my imagination.

Very possible that it use to do it, but this is not the case anymore for last 2 or 3 versions.

It only creates waveform cache files and sometimes audio cache. It doesn't create (definitely not up-front) and video seeking or proxy etc file. I'm not sure if it does store info about frames when you work and scrub timeline, so next time specific frame can accessed faster, but this is different thing than up-front seeking file.

Edius doesn't create any proxies (can create seek files for MPEG2)- it's all down to great Japanese programming skills behind Edius engine. Edius code is crazy fast and well optimised.

This is not true at all. Premiere doesn't create any GBs of video helper files (if any then index file are tiny).

And I am indeed familiar Edius, though I don't recall at this point whether it creates proxies or not. However, given our other difference of opinion on Premiere, it's unlikely we would agree on their presence anyway.

It's fact which can be checked. It either does it or not. If you not used latest version of Premiere then you can't tell this. You can't be based on experience from few years ago. Few years ago Premiere was crap and I also use to hate it.
It's the same as presenting your Resolve experience from few years ago- totally different app!

Well, if it's simply a factual question, here's part of a FAQ ("FAQ: How to clean media cache files?") offered by Adobe, as of Jan. 2017:

When importing video and audio into Adobe Premiere Pro, it processes versions of these files that it can readily access for faster performance. These are referred to as "media cache" files. These are stored in the Media Cache Files folder. In addition, there is a folder containing a database, which retains links to each of the media cache files. These are referred to as "media cache database" files. They are located in the Media Cache folder.

Note: there is a delay in proper audio and video playback while newly imported media is being processed and cached. A progress bar in the lower right of the application shows the progress of the media cache being processed.

It's enough of an issue, that Adobe created a FAQ to explain how to delete these files, because they take up so much space. And these files wouldn't show up on the scratch disks. On Windows, look here:

Windows: \Users\<username>\AppData\Roaming\Adobe\Common. You may be shocked.

https://forums.adobe.com/thread/2152942

Don't get me wrong: for all I know, Resolve could vastly improve it's playback of GOP formats. I don't claim any expertise on the question. But, with respect to Premiere, there are more than just audio caches, if Adobe employees are to be believed.

What was last version of Premiere which you've tried?

Install trial and check yourself. The only thing which Premiere can create are waveform cache, waveform preview files in case of some audio formats (these can be relatively big) and seeking help files (when you work on your project). It doesn't create any optimised media etc. up front, even for h264 based files.

Don't see the point of convincing you- simply try yourself. Do you use Premiere every day or assume things based on few years old experience?
I use Mac.

The longest is after a cut with the razor tool if we restart the play immediately after: it takes ~ 1s for DR to regenerate the thumbnails on the timeline.

Changing the timeline options accelerates after a cut: no need to regenerate the images.

TL option.jpg

(test with clip GH5 UHD MP4 8 bits and no other problem)

Hi Jean, I tried that and I still get the lag.

Hi Dave,

I posted on liftgamma (please see) : for me this is not normal.
In any case, it is already verified: the GPU is useless for the decoding in Resolve => only for the effects

You have a bottleneck. With my "small" 6850k I do not have the problems you have.

Sorry.

What was last version of Premiere which you've tried?

Install trial and check yourself. The only thing which Premiere can create are waveform cache, waveform preview files in case of some audio formats (these can be relatively big) and seeking help files (when you work on your project). It doesn't create any optimised media etc. up front, even for h264 based files.

Don't see the point of convincing you- simply try yourself. Do you use Premiere every day or assume things based on few years old experience?
I use Mac.

Hi Andrew. I use Premiere everyday on both Mac and Windows, and I can confirm that it creates some sort of Media Cache files, because, at my work, we have limited space and we have to clean the cache files of Premiere and After Effects every couple of days to free some space, and I am talking gigabytes. Actually, I am currently at work on a Windows machine, and the Media Cache Files folder of Premiere is almost 50GB.

And I think you will need to read that thread that John linked to. It is written by one of Adobe staff on their forum and it talks about Media Cache files. From what I understand from this thread, it creates these files for video and audio when you import them the first time so Premiere can access these Media Cache files "for faster performance". This thread also adds that if you delete these files, when you open the project, it will need to recreate the Media Cache files.

Here is the thread: https://forums.adobe.com/thread/2152942

This is not to say that Premiere's method is bad or that Resolve's method is better.

The way Premiere handles it has its pros and cons. You definitely get much better playback with even some of the worst codecs out there, but you lose storage space.

What we all agree to is that Resolve needs better way to handle the playback, especially if it wants to compete in the NLE market, because even with Optimized Media, on some systems, you don't get a playback that matches what you get in Premiere or some other NLEs. This might mean that some of Resolve's code, at least for the Edit page, needs to be changed, but this is not for me to say since I don't have any experience with coding.

It may create 32bit float PCM conformed files for some audio formats like AC3, MP3 (*.cfa files which can be big and you may want to clean them time to time), some seeking help files, waveform peaks, media info files (which are small, Kbytes), but...it doesn't automatically create any proxy video files as such- e.g. uncompressed, or MJPEG or DNxHR etc.
It's very different than Resolve optimised media/smart cache- this can really take space depending on chosen format And yet Premiere scrubbing is miles ahead Resolve, but still behind Edius experience.
Resolve Long GOP formats handling is simply poor. Support for those was added just so it's there without any optimised code, etc. I hope it will change if BM wants to use this flashy "Most advanced editor" advert tag which keeps popping out on creativecow website

Back to Premiere- this lists all Premiere's cache files:

https://screenlight.tv/blog/the-definit ... edia-cache

Only *.cfa audio files are big, others are rather small. There are no video proxy files at all.

It may create 32bit PCM conformed files for some audio formats like AC3, MP3...

there is also another well hidden performance trap related to audio: if applications use a different sample rate for output, than the system audio service and mixer, the signal has to be resampled in a quite computing intensive manner. this was a very nasty issue, when i used lightworks on linux. it can make applications very laggy and unresponsive. you have to change the system sound system settings to use the same sample rate as your NLE to avoid this pitfall and optimize playback.

Only *.cfa audio files are big, others are rather small. There are no video proxy files at all.

This is a direct contradiction of Adobe Tech Support as of January 31, 2017, and other sources insist that all GOP formats generate video cache files, but never mind, it doesn't really matter. The only real issue is whether, for the footage in question, these cache files give Premiere a significant performance playback advantage over Resolve.

You claim they don't, but unfortunately there's no way to test it, because Premiere won't allow work until these cache files are generated (or re-generated, after they're manually deleted). I wonder why?

OTOH, the OP might want to determine just what kind of cache files this XAVC-S material is generating, and their size, to help answer this question.

Are we doing a fair comparison here?

Resolve's image processing is 32-bit float. There's no way to lower this.

Premiere, on the other side, has 8 bit as default. When running these tests, is everybody setting the Premiere projects to 32-bit float also?

Besides, Resolve's visual responsiveness is different when viewed on the Timeline viewer in comparison to an external monitor connected to a BMD card like Decklink or Intensity. In the first, I never have the same frame rate of the second.

I am not saying that there's not room for improvement in Resolve. But some tests can be deceiving.

There's another thing in Resolve that impresses me: it does not lose time generating waveform or peak files. You simply touch a media with audio in the Media Page and presto! The waveform appears. Even with long clips. Even over network.

Just a few thoughts on this.

When image data is copied to GPU, it will be processed as 32bit floats on almost all cases because float calculations are what GPU is optimized for and it is also useful for precise color math. This is also the case with Resolve when Lumetri GPU engine is used. Does Premiere lag similarly when using it? Most probably not.

There are two different ways to do color processing on GPU. In fragment shader code and using GPGPU calculations with CUDA or OpenCL instructions. First one is very fast, but not as easy to extend and build into chain of different effects. Plus it is a bit harder to get data back (for saving) from that path as opposed to rendering it on screen. GPGPU way is also very fast, but is more flexible and data oriented so it is usually used for all kinds of calculations where we need to process data and don't necessarily need to show it on screen.

Fragment shader code is very useful for viewer processes where we do something with the image just for view. Like applying gamma correction, LUTs, set exposure etc. The data goes from RAM to GPU where it is processed using CUDA/OpenCL and is then bound to texture memory and rendered on screen (on a rectangular plane) that has an attached fragment shader that does all the additional viewer processing and gets its settings input through different uniforms (variables bound to shader code on runtime).

The image data basically moves like this (when using GPU processing):
- from video file (container) the stream information is extracted;
- packets are read from file and for each packet it is detected if it is a video packet, audio, subtitle, metadata etc;
- if it is a video packet it is sent to decoder;
- decoder takes the packet (that contains raw data and additional stream packet information) and extracts the uncompressed image data;
- uncompressed image data is moved to GPU;
- on GPU the uncompressed image data is manipulated to get it into RGB form, this involves Y'CbCr to RGB conversion with subsampling removal etc;
- image processing is applied on GPU (using CUDA/OpenCL);
- additional viewer processes are applied using shader code and image is rendered on screen using OpenGL

One possible use of media cache/descriptor files is to write down the memory location of different packets and use that information for faster seeking. For example for h264 stream we can write down the offset of each packet from file start and additionally the type of packet (I-frame etc). With this data we can speed up seeking by jumping to closest I-frame and decoding from there to whichever frame we actually wanted to see. Without such index the decoder might have to search the stream for I-frame first (by approximating its location) and then decode up to the frame we actually want to see.

What is important here is that most of decoding is taking place on CPU. The reason for this is that most codecs are not designed to be easily implementable on GPU. There are H264 and Prores decoders for GPU (not hardware implemented that have limited capabilities but CUDA based decoders), but they most certainly are not widespread. For this reason usually decoding is taxing the CPU while GPU is sitting idle. In the future this probably changes though.

When decoding is done, the decoded image data is moved to GPU and "expanded" there. Why? Because it is faster and more logical to move for example the 420 Y'CbCr data to GPU before converting it to RGB due to the fact that 420 subsampled image is only half the size of the same image in RGB form (less data to copy) plus it is faster to do the conversion on GPU anyway. The same applies to Red Raw and similar, where (if possible) the decoding is also done on GPU (there are j2k GPU decoders) and whole debayering routine is also performed on GPU side.

To take it all together, there are some possible bottlenecks that can be avoided but not always and not every time. Decoding speed of video stream packets on CPU is dependent on the codec used and there is not much else an NLE can do but optimize the order of frames requested (no out of order requests please!) or choose a faster decoder. Copying the image data to GPU is usually fast enough, but with 4K and beyond and pure RGBA 12/16bit data (prores4444, exr and dox sequences etc) the connection speed of PCIe port itself can become the limiting factor. Nothing an NLE can do here. Processing logic on the GPU and all the additional things the software performs while doing playback (updating some knobs in viewport maybe) can be the factors that slow down the playback.

There was a discussion about whether there is a major difference in the way node based and layer based softwares process data and if the speed differences come from there. I would argue that node vs layer based is not the reason, the reason is rather the type and amount of processing the application does. Node based approach just fits better with applications that do more heavy lifting, there is no inherent limitation in node based data flow description that should make it slow.

Only *.cfa audio files are big, others are rather small. There are no video proxy files at all.

This is a direct contradiction of Adobe Tech Support as of January 31, 2017, and other sources insist that all GOP formats generate video cache files, but never mind, it doesn't really matter. The only real issue is whether, for the footage in question, these cache files give Premiere a significant performance playback advantage over Resolve.

You claim they don't, but unfortunately there's no way to test it, because Premiere won't allow work until these cache files are generated (or re-generated, after they're manually deleted). I wonder why?

OTOH, the OP might want to determine just what kind of cache files this XAVC-S material is generating, and their size, to help answer this question.

It does make a difference as you are spreading false information.
Where does Adobe say that Premiere generates any kind of video proxy files automatically? Cache files don't automatically= some video proxy file. Where do they say that some easy to decode video format is generated so it can be played instead of main source?
It creates many different type of cache files (all listed in my link), but not a single one is a video file. You have to understand the difference.

Please try it first yourself and show me these huge video proxy files generated by Premiere, because I'm yet to see them and I use Premiere a lot.
Please show me grab, size, what extension are they?
I can show you that when I drag e.g. GH5 h264 MP4 (this is long GOP) footage it creates only .cfa file, .pek file (waveform preview), .ims which stores file properties and .mcdb which also holds some info about source file. Except .cfa all other files are very small. There is no such a thing like video proxy file which is used for playback instead of main source file. You have to render timeline to get such a file, but this is different story.

You mentioned XAVC long GOP:



where is this big/huge video proxy file? In this case it did not even generate .cfa file as audio is PCM.

Also- I didn't have to wait for anything- dragged file and can work with it straight away.

...

To take it all together, there are some possible bottlenecks that can be avoided but not always and not every time. Decoding speed of video stream packets on CPU is dependent on the codec used and there is not much else an NLE can do but optimize the order of frames requested (no out of order requests please!) or choose a faster decoder. Copying the image data to GPU is usually fast enough, but with 4K and beyond and pure RGBA 12/16bit data (prores4444, exr and dox sequences etc) the connection speed of PCIe port itself can become the limiting factor. Nothing an NLE can do here. Processing logic on the GPU and all the additional things the software performs while doing playback (updating some knobs in viewport maybe) can be the factors that slow down the playback.

There was a discussion about whether there is a major difference in the way node based and layer based softwares process data and if the speed differences come from there. I would argue that node vs layer based is not the reason, the reason is rather the type and amount of processing the application does. Node based approach just fits better with applications that do more heavy lifting, there is no inherent limitation in node based data flow description that should make it slow.

Yep, it's all down to the quality of the code

Resolve used to deal only with image sequences which in some cases (like DPX) can be pushed directly to GPU much quicker. That's why DPX works so well, as it skips a lot of intermediate steps. Load directly to GPU, process, display- all on GPU (data doesn't travel much). Adding video codecs complicates Resolve's engine, but this is known issue and all companies have to deal with it some way (old days by generating some optimised media format), ones do it better than others.

For NLE 32bit float is not always needed at all, as you may only do cut editing or simple corrections etc. In such a case you don't need 32bit float at all- it can only slow down software.
FCP X also uses 32bit float by default as far as I know and it also miles ahead of Resolve.
That's why Edius timeline is so fast- they don't use GPU much at all. It's mainly CPU coded and very well coded, so timeline response is very good (and with 10bit project they also use 32bit float now).

GPU is not good for use as decoder as its power lies in hugely parallelised operations. For most codecs this is impossible to achieve, so GPU power is not well suited for these needs. That's why there are special/dedicated chips for decoding/encoding h264 etc inside GPUs.

It may create 32bit float PCM conformed files for some audio formats like AC3, MP3 (*.cfa files which can be big and you may want to clean them time to time), some seeking help files, waveform peaks, media info files (which are small, Kbytes), but...it doesn't automatically create any proxy video files as such- e.g. uncompressed, or MJPEG or DNxHR etc.
It's very different than Resolve optimised media/smart cache- this can really take space depending on chosen format And yet Premiere scrubbing is miles ahead Resolve, but still behind Edius experience.
Resolve Long GOP formats handling is simply poor. Support for those was added just so it's there without any optimised code, etc. I hope it will change if BM wants to use this flashy "Most advanced editor" advert tag which keeps popping out on creativecow website

Back to Premiere- this lists all Premiere's cache files:

https://screenlight.tv/blog/the-definit ... edia-cache

Only *.cfa audio files are big, others are rather small. There are no video proxy files at all.

Sorry I didn't make myself clear here. Of course, I didn't mean that Premiere creates proxy files. It wouldn't make sense since there is a whole proxy workflow. All I meant is that, and I am quoting the Adobe Forums thread here, "it processes versions of [the video and audio] files that it can readily access for faster performance." I am not sure exactly what is the nature of the processing it does, or what it stores (since I am not an engineer), but, according to them, it helps Premiere work faster.

However, you are right about the file sizes. When I checked it yesterday, I only looked at the size of the whole media cache folder. Today I checked the file sizes, and the biggest ones are the *.cfa files along with some of the *.prmdc2 mentioned in the article you linked to.

Again, this is not to say that you can compare Resolve to Premiere. Definitely Premiere works better for me when it comes to editing. In my experience, even Optimized Media don't always fix the problem. I found that caching works better, but it's of course more time consuming than optimized media, since you have to do it every time you add a clip to the timeline. The best practice so far that really improves Resolve's performance, in my workflow at least, is to create proxies using something like DNxHD 36 8-bit. Check this other thread for more info: http://forum.blackmagicdesign.com/viewtopic.php?f=21&t=57747

Now regarding the 32-bit processing that Adelson mentioned here

Are we doing a fair comparison here?

Resolve's image processing is 32-bit float. There's no way to lower this.

Premiere, on the other side, has 8 bit as default. When running these tests, is everybody setting the Premiere projects to 32-bit float also?

I tried setting Premiere to 32-bit to test it. The only way I managed to find that is supposed to be doing that is to check Maximum Bit Depth in the Sequence Settings. Now, I am not sure if that actually changes Premiere to 32-bit processing for all the media or it is something that is specifically for the 32-bit effects.

Anyway, if this actually changes Premiere to 32-bit, it didn't make a difference in the playback speed using the same test scene I mentioned in my other thread. This means that either this is not actually switching Premiere to 32-bit, or that, even in 32-bit, Premiere can handle the media and play it back smoothly, at least on such a small scene like the one I used.

Maximum Bit Depth in the Sequence Settings should switch Premiere to high precision mode (it should be 32bit float but not all effects support it). If it's 32bit float or e.g. just 16bit for NLE makes not much of a difference. You have to do very specific operations to saturate its possibilities and in NLE most of the time you actually cutting. You can also always work in "fast mode" and enable 32bit float for export. Resolve rather needs 32bit float all the time (maybe not for editing section) as its main purpose is grading, so sometimes heavy math/adjustments. It's not east to make all cases working most efficiently as some operations need very different things. That's why making Resolve best NLE and best grading tool is not as easy as adding editing tab

Creating proxies (DNxHD 36) etc is time consuming process and we all want to avoid these things. It's one of the way to deal with the problem, but old fashion and slow one.

As I mentioned- if you receive 2h of XAVC source files, by the time you have proxies created someone may by half way of editing if he can work with native files. It does make a huge difference in crazy money orientated world

Maximum Bit Depth in the Sequence Settings should switch Premiere to high precision mode (I think it's 32bit float). If it's 32bit float or e.g. just 16bit for NLE makes not much of a difference. You have to do crazy operations to saturate its possibilities and in NLE most of the time you actually cutting. You can also always work in "fast mode" and enable 32bit float for export. Resolve rather needs 32bit float all the time (maybe not for editing section) as its main purpose is grading, so sometimes heavy math/adjustments. It's not east to make all cases working most efficiently as some operations need very different things. That's why making Resolve best NLE and best grading tool is not as easy as adding editing tab

Creating proxies (DNxHD 36) etc is time consuming process and we all want to avoid these things. It's one of the way to deal with the problem, but old fashion and slow one.

As I mentioned- if you receive 2h of XAVC source files, by the time you have proxies created someone may by half way of editing if he can work with native files. It does make a huge difference in crazy money orientated world

I agree. Resolve of course still needs more work to improve its editing abilities. Not only on the performance and playback side, but even things like the UI needs major improvements, at least in my opinion. For instance, a simple thing like making a specific panel full screen is missing from Resolve. I personally use that feature a lot in Premiere when working.

Regarding the proxies, I, personally, prefer creating them if I have the time, even when using Premiere. Of course Premiere's difference in performance between using proxies and using original files is not as huge as it is in the case of Resolve (at least not if you are working with HD files), but when I do it, I always notice a slight difference.

However, I totally agree that you don't always have the time to create them. I work a lot with news TV channels and news websites, and there is no way I can tell a reporter to give me an hour or so to create proxies for the media files. They would probably shoot me in the head and hang my body at the entrance as a warning for any future video editor who might think of making a similar request

I personally would love to see Resolve go all the way and be a better NLE, just for the mere fact that it is available in Linux which is my preferred OS. I respect Blackmagic for not using the annoying lazy response that there is not a market for NLEs among Linux users.

For quick editing for news etc Edius is unbeatable and for HD you can work on decent laptop (no even need for desktop machine).
It supports smart-rendering for many formats, so when you have e.g. XDCAM HD source and need to export the same it will copy all original data and re-encoded only needed parts. This can speed up exports to no-time (if you have mainly cut editing)- even no time for tea Premiere also does it now- not sure how well it works. Edius had it already years ago.

For quick editing for news etc Edius is unbeatable and for HD you can work on decent laptop (no even need for desktop machine).
It supports smart-rendering for many formats, so when you have e.g. XDCAM HD source and need to export the same it will copy all original data and re-encoded only needed parts. This can speed up exports to no-time (if you have mainly cut editing)- even no time for tea Premiere also does it now- not sure how well it works. Edius had it already years ago.

I know about Edius, but I can't use it at work, because they are using Premiere. Never tried the smart rendering, though.

For cut editing it can save you a lot of time on exports. Also- it avoids generations, so you don't loose quality (of course if you have some effect on top of whole video it won't work and Premiere will force re-encoding).

Smart rendering should be de rigueur for every editor. Nothing worse than having to RE-RENDER footage when all you have done is cuts. However, even if you have applied transitions, titles, etc., that require rendering, the NLE should only render those portions of the clip as needed and leave the rest of the clip untouched. That is what smart rendering is all about.

Of course, the list of codecs supported for smart rendering varies between NLE and tends to grow with each new update. IIRC, Premiere didn't support SR until CS6, and the list of codecs was pretty small.

Yes, the OP announces an editing problem for a XAVC-S UHD and tells us that even a GTX 1080ti did not solve its latency problem after a simple cut.

English is not my native language, in a few simple words:
What is Smart rendering going to solve its problem for a XAVC-S source?
And:
How to make Smart rendering if the source and the result are not the same?

(Sorry, but I did not quite understand what Smart rendering is for you in this case)

Thank you in advance for your answers.

Well- read answers more carefully.
Smart rendering is very useful and powerful in some cases.
If you receive e.g. XDCAM HD footage and your job is do some cut editing and give back XDCAM HD then smart rendering is a huge plus. You quickly do your cuts, etc and export back to XDCAM HD. If you done only cut editing+some fads etc than e.g. 95% of your final export is 1:1 coy of the source and only parts which are changed need re-encoding to XDCMA HD. Export time will be very fast (as it's just a copy task).
I've done such a things for some home DVDs. 2h footage which needed few scenes to be replaced. Not only I preserved original quality but it took me overall only about few min for 2h source (+few minutes burning new DVD).
Quick editing for news etc can benefit hugely from such a feature.

This has not much to do with original problem of XAVC being slow- that's a Resolve issue, but this is one of the features which modern NLE should have (when we talk about and compare NLEs).