[madshi]

Originally Posted by Gser

I've noticed that using Dscalers reference idct results in a lot sharper and detailed picture while the ones in ffmpeg result in a much softer picture.

Can you please post screenshots that show this difference? Ideally also a small video sample? Thanks!

Originally Posted by cyberbeing

You've mentioned this before about PCIe RAM. What exactly is PCIe RAM and where is it being allocated, as it certainly doesn't seem to be going into System RAM or GPU RAM?

Microsoft mentions it here:

http://msdn.microsoft.com/en-us/libr...=VS.85%29.aspx

It's called "AGP memory" there, but we're using PCIe instead of AGP these days. So I've now called it "PCIe RAM". Here's a good description I found of what it exactly is:

> AGP memory is just a chunk of regular system memory
> -- the memory on the motherboard -- that's given
> special treatment. It's marked as WC (write-combining)
> by the CPU which allows for fast writes but slow reads.
> It's also mapped by the AGP GART ("Graphics Address
> Remapping Table"), which means that the video card
> can read directly from it relatively quickly. But not as
> quickly as local video memory.
> It's basically a compromise between regular system
> memory and local video memory. Because the CPU can
> write to it quickly and the GPU can read from it
> relatively quickly, it's a natural home for
> D3DUSAGE_DYNAMIC resources.

Originally Posted by cyberbeing

Assuming madVR is reporting GPU + PCIe RAM, is there any reason that combined number should be kept below GPU RAM capacity?

Nope. I didn't think of AGP/PCIe memory at all, when implementing that RAM consumption stuff in v0.79. I'll try to revise the logic to only count true GPU RAM usage and to disregard PCIe memory. That should help getting the madVR reported numbers nearer to what the other tools are reporting.

The only thing that counts is GPU RAM. Ok, I don't know if PCIe memory is limited, too. Maybe it is, I don't think it's specified anywhere. So we can only make sure that GPU RAM is not over used.

Originally Posted by cyberbeing

This also has me curious if madVR in any way confirms that 16bit/32bit FP textures are being stored properly by the GPU?

What makes you think they would not be properly stored? Never heard yet of drivers refusing the allocate the exact format I'm asking them for.

Originally Posted by cyberbeing

It doesn't crash now which is a success, but I still need to set all scaling to Bilinear and disable the 3DLUT for it to be usable without delayed/dropped frames on 1440x1080i30 16:9 video.

Could you add an option under Trade Quality for Performance for something like 'Use Bilinear and Shaders Only when Deinterlacing or 60fps+ framerates' to temporarily set these options when deinterlacing is active and/or just high framerate content in general? That's the only practical way I could see to keep deinterlacing enabled in madVR.

I'm planning to implement some kind of profiles some time in the future. For now I don't want to make the settings dialogs overly complicated by making some of the options only apply to this or that. What you're asking does make some sense. But next thing on your list would then be to also switch to Bilinear with native 60p content. So the proper solution will be something else, sometime in the future. For now you'll have to live with the way things are.

Originally Posted by cyberbeing

Another thing I note is performance is much much slower (3-6ms deint vs 0.15-0.25ms deint) if Inverse Telecine enabled in the NVCPL. Since madVR doesn't seem to support decimation like VMR (?)

Huh? DXVA2 itself does not support decimation. Neither VMR, nor EVR nor madVR can do it. Don't be confused by soft-telecined content, which decoders output untouched (weaved). Such content may look like decimated, but it's not really.

Originally Posted by cyberbeing

I guess everybody should disable that setting? No change in quality as far as I can tell using madVR, just slower.

It all depends on the content. With native video content, the IVTC option will do nothing but waste GPU power. With soft-telecined movie content, same. But with hard-telecined movie content, the IVTC option should definitely improve image quality. So I wouldn't turn it off.

Originally Posted by cyberbeing

As for queue sizes for deinterlacing
Absolute minimum: 8CPU/6GPU (below this results in massive dropped frames)
Absolute maximum: 32CPU/24GPU
Requirement 1: Inverse Telecine is disabled in NVCPL
Requirement 2: CPU Queue is at least +2 greater than GPU queue (in order to keep the CPU queue fluctuations above GPU queues)

Interesting. So you can actually use 32CPU/24GPU? That's probably with SD content, though?