[WiP] madVR support in MP1 (9 Viewers)

[Sebastiii]

From Tourettes comments, native madVR should be done after all madVR issues goes fixed.
V11 has renderframe commented out.

Actual implementation cause huge GPU/CPU bandwidth and can lead on lower CPU (or not) into some dropped frame or not be able to use all madVR tweak option.

So i will build default full installer without native Renderframe but upload too a version for it and could be nice to have result on this.

Next implementation would be to take information directly from VRAM (GPU) or something to try to have less stress on PCIe bus.

 

[kenwonders]

Please send our thanks to Tourettes (or if you're reading, THANKS).

I don't understand the renderfame functionality, what is the functional difference? (if you don't mind explaining )

 

[Rick164]

It's for AtmoLight if I understood correctly, with Mediaportal non-madVR builds we do only call it when it detects AtmoLight though so no overhead for the regular users but might be different for the madVR builds
Did notice a slightly higher render time with AtmoLight but that has been with EVR as well since the beginning, it depends on the hardware and drivers / implementation.
For comparision later this is the load with EVR under Mediaportal 1.15 + AtmoLight 1.18.0.0 pre-release, not sure if we can measure the pci-e interface load but the bus interface stays at 0%

 

[Sebastiii]

Full installer in first post

 

[Sebastiii]

So please try V97 to see if it's always ok

 

[kenwonders]

using the test dshowhelper for atmolight, although not using it (pure ambibox for this test). Is the 'switch' in place to only use renderframe with atmolight plugin? If not, then good news as it doesn't crash for me after many zaps.

It did however occasionally go slideshow on channel zap, cured by zapping somewhere else (but not pausing). Logs attached if they show anything.

 

[Sebastiii]

using the test dshowhelper for atmolight, although not using it (pure ambibox for this test). Is the 'switch' in place to only use renderframe with atmolight plugin? If not, then good news as it doesn't crash for me after many zaps.

It did however occasionally go slideshow on channel zap, cured by zapping somewhere else (but not pausing). Logs attached if they show anything.

Yes 'dshowhelper for atmolight' has the renderframe in place but grab the frame from c++ only 2 frames

So it's good that it doesn't crash

 

[kenwonders]

You mean, just the first two?

using the test dshowhelper for atmolight, although not using it (pure ambibox for this test). Is the 'switch' in place to only use renderframe with atmolight plugin? If not, then good news as it doesn't crash for me after many zaps.

It did however occasionally go slideshow on channel zap, cured by zapping somewhere else (but not pausing). Logs attached if they show anything.

Yes 'dshowhelper for atmolight' has the renderframe in place but grab the frame from c++ only 2 frames

So it's good that it doesn't crash

Cool, yes still stable now, when do I get the rest of the frames?

 

[Rick164]

Cool, yes still stable now, when do I get the rest of the frames?

They get sacrificed to the GPU gods

Wondering how well smoothing works this way, this means for 24P content we now get 12ish frames to base this on so might get higher rate of color changes depending on the content
Once the test machine works again will do some experimenting but in the meantime made a new build with some improvements done by @wolph lowering the cpu usage when delay is active to near 0%

Need to handle a non-existent case when a device / target doesn't support delays which at the moment none do but would be nice to handle it anyway for in the future.

 

[kenwonders]

I'll check it out, been playing with INO scripts again so want to try my multi atmoduino/atmoduinov2/ambibox protocol receiver