Page MenuHome

Fix for GPU compositing with no-npot texture support
AbandonedPublic

Authored by Campbell Barton (campbellbarton) on Sep 14 2015, 5:23 PM.

Details

Summary

This fixes viewport compositing, when the requested texture size doesn't match the viewport size. Tested for regular viewport and offscreen rendering.

Its not a very elegant, but is at least is localized in one place.


Note, that I'm not running a graphics card with real missing npot support, I just had to fake it by setting GPUGlobal.npotdisabled = 1; at startup.

Also, OpenGL2.0 from 2005 supports npot, so am wondering how long we should be supporting this for (or if hardware without npot would be capable of GPU compositing).

Diff Detail

Repository
rB Blender
Branch
temp-gl-npot-compo

Event Timeline

Campbell Barton (campbellbarton) retitled this revision from to Fix for GPU compositing with no-npot texture support.

My graphics card has non power of 2 support. It's just being blacklisted (there's a comment in gpu_extensions.c about how certain API chipsets are problematic). I can try disabling the blacklisting and see what happens.

This fix only takes care of mapping for the texture for the final compositing on the screen, however the shaders need calculation fixes as well. All the position reconstruction code in particular relies on the fact that uv coordinates are in the 0-1 range.
This is fixable but adds complexity in the code. In the case of, for instance, depth of field or any algorithm that requires downscaling, this scaling will have to be propagated to downscaled textures as well, and tracking this becomes quite annoying.
I'm a bit sceptical too if we really need to support this. Probably the best would be to just disable compositing for cards not supporting npo2 and remove the card from the blacklist.

This fix only takes care of mapping for the texture for the final compositing on the screen, however the shaders need calculation fixes as well. All the position reconstruction code in particular relies on the fact that uv coordinates are in the 0-1 range.
This is fixable but adds complexity in the code. In the case of, for instance, depth of field or any algorithm that requires downscaling, this scaling will have to be propagated to downscaled textures as well, and tracking this becomes quite annoying.
I'm a bit sceptical too if we really need to support this. Probably the best would be to just disable compositing for cards not supporting npo2 and remove the card from the blacklist.

I disabled blacklisting, and both screenspace AO and opengl preview rendering seem to be working. My gfx card is a AMD Radeon HD 8400/R3.

Can you post full system_info.txt in the task description please?

This is no longer valid since we rely on npot textured now (since the bump to 2.1)