* 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