* This needs to be refactored to use the program interface query API so
we can get the location of uniform blocks and set them
* We also need to copy over sampler uniform values (getting away with it
for now as we're generally replacing the pixel shader, so there aren't
any samplers used in the cases I've tested).
* Instead of using FetchTexture we store the internal format in the texture
data in the driver, so it's available for use.
* This fixes some issues with the overlay textures
* There was a problem where a value of 1.0 would show up as 'clipping' if
the range meant that it was transformed to something like 1.0000000432f
so we use FLT_EPSILON as a slight fudge factor.
* Same implementation as D3D11 essentially
* Split out the texture sampling from texdisplay.frag into its own file so
it can be reused. Also removed the discard;s from the texture sample
functions and moved them up into the texture display function.
* Several places were using HGRAM_PIXELS_PER_TILE*HGRAM_PIXELS_PER_TILE
instead of HGRAM_PIXELS_PER_TILE*HGRAM_TILES_PER_BLOCK and calculating
blocks as too large. This meant histogram/minmax would miscalculate the
number of blocks needed and fail to read properly from > 2048 textures
* Technically CopySubresourceRegion should only be called for matching
types, but the handling won't change (we'll just mark dest resource as
dirty), so this fires when programs are being a bit naughty for no use.
* This is the proper fix for 87bcde1c which is also more explicit about
what is going wrong. Thanks to the anonymous user who mentioned that they
clicked auto-fit before hitting the range histogram crash, which got me
on the right path to track down the exception!
* The debug text used to render at swapchain dimensions, but that could
make it unreadable if the window was significantly different, so apply a
scaling factor to account for it.
* I was a little conflicted about this, as the resources present in logs
should be determinable - if a function marks it as referenced then the
serialised version of that function should expect the resource to be
present, and if it's not then there's a bug and we can't properly replay.
* However I am tempted to say that instead of likely crashing due to an
invalid NULL pointer suddenly appearing somewhere, we should instead try
to continue even if a resource isn't available.
baldurk