hormet and i were unsuccessful in trying to enable dithering on my HP Z Book running Linux. We get 10-bit performance without dithering. Trying to turn on dithering made things worse.
We have three questions (1-4), below.
From your comments to me, I expected the magic number to be different for this computer than for my iMac and MacBook Pro, but you gave hormet the same number as you gave me. Expressing your advice to us as MATLAB code, we have:
wInfo=Screen('GetWindowInfo',window);
switch(wInfo.DisplayCoreId)
case 'AMD',
DCEDisplayEngineVersion=wInfo.GPUMinorType/10;
switch(round(DCEDisplayEngineVersion))
case 6,
displayGPUFamily='Southern Islands';
% Examples:
% AMD Radeon R9 M290X used in MacBook Pro (Retina, 15-inch, Mid 2015)
% AMD Radeon R9 M370X used in iMac (Retina 5K, 27-inch, Late 2014)
ditherCLUT=61696;
case 8,
displayGPUFamily='Sea Islands';
% Used in hp Z Book laptop.
ditherCLUT= 61696;
end
end
Screen('ConfigureDisplay', 'Dithering', screen, ditherCLUT);
The value 61696 works fine on the iMac and MacBook Pro, yielding 11-bit performance. On the HP Z Book, it reduces performance from 10-bits to 7 or 8 bits (in two different tests).
1. Can you confirm that 61696 is correct for the HP Z Book?
-> According to Linux driver code and docs, yes. The matching number is by accident. 61696 is the value to enable dithering to a 8 bit panel on "Southern Islands". On "Sea Islands" it instead enables dithering to a 10 bit panel,ie. the 10 bit panel of that HP zBook.
Well either that, or there are mistakes in the drivers documentation. Or driving the HP Z Book internal flat panel with dithering this way is not possible. The Linux driver would not apply dithering setup to a Laptops internal eDP panel, because this is considered the job of the laptops vendor specific firmware. So our attempt to override this may not be the right thing to do and that's why it fails.
Another number you could try is 59648. This would enable dithering for a native 8 bit panel, which is the wrong thing to do for the laptops 10 bit panel, assuming the driver docs are correct. But then, who knows? Given that you managed to get 11 bpc via dithering from your MacBookPro's 8 bit panel, maybe you can get 11 bpc or more from the zBook's 10 bit panel if it is mistreated as a 8 bit panel? We are in the land of magic numbers here...
For reference, this is the 10 bpc panel dither setup code for the zBooks "Sea Islands" (CIK) gpu:
http://lxr.free-electrons.com/source/drivers/gpu/drm/radeon/cik.c#L8814The constants which are or'ed / added together in that code are defined here:
http://lxr.free-electrons.com/source/drivers/gpu/drm/radeon/cikd.h#L989I simply or'ed the proper constants to get the numbers i told you, so PTB replicates the Linux display drivers behaviour.
As you can see there are many parameters one could tweak for any given display. E.g., add/leave away
FMT_FRAME_RANDOM_ENABLE, FMT_HIGHPASS_RANDOM_ENABLE, or FMT_RGB_RANDOM_ENABLE
for extra entertainment value. It's somewhat of a black art. The gpu also has various temporal dithering modes with even more parameters, or combined spatio-temporal modes. Most of these are never used or even validated by gpu hardware vendors to do the right thing. All the variations will have different effects on different types of display panels, at different refresh rates and pixel densities, for different types of still images or animations, so a panel with a true native high bit depths is still a more deterministic thing that simulated high bit depths. I would use dithering only for high level stimuli with low spatial frequencies for that reason.
This is the code Hormet wrote to set up the Z Book, based on advice from you.
PsychImaging('PrepareConfiguration');
switch nBits
case 8; % do nothing
case 10; PsychImaging('AddTask', 'General', 'EnableNative10BitFramebuffer');
case 11; PsychImaging('AddTask', 'General', 'EnableNative11BitFramebuffer');
case 12; PsychImaging('AddTask', 'General', 'EnableNative16BitFramebuffer', [], 16);
end
PsychImaging('AddTask', 'FinalFormatting', 'DisplayColorCorrection', 'SimpleGamma');
% uncomment this line when using 11 bpc for the first time
% delete([PsychtoolboxConfigDir 'rgb111110remaplut.mat']); % clear cache
[w, wRect] = PsychImaging('OpenWindow', screenNumber, 0.5, []);
if nBits >= 11; Screen('ConfigureDisplay', 'Dithering', screenNumber, 61696); end % 11 bpc via Bit-stealing
PsychColorCorrection('SetEncodingGamma', w, 1/2.50); % your display might have a different gamma
Screen('Flip', w);
2. Must we call "FinalFormatting"? Is the call to "FinalFormatting" just loading an identity gamma? Can I, instead, just use LoadFormattedGammaTable to load identity?
-> No, only if you want PTB to do high precision color/gamma correction via the modes and settings supported by PsychColorCorrection(). The call itself would simply establish an identity gamma "curve", however operating at ~ 23 bpc linear precision (32 bit floating point precision is about ~ 23 bit linear precision in the displayable color range of 0.0 - 1.0).
3. Must we call "PsychColorCorrection"? I'm already doing correction based on my photometry.
-> No. But it's certainly more convenient and faster, and very accurate. That's the recommended way to do gamma correction on > 8 bpc framebuffers.
-> For testing it would be better to leave it out, so you use a identity mapping like when testing on the Macs.
4. Is there some programmatic way to decide when to delete the cache file [PsychtoolboxConfigDir 'rgb111110remaplut.mat'])? Can we delete it every time we call PsychImaging to open a window?
-> You don't need that. It was/is a one time fix. The next PTB beta update will make sure no stale/invalid files are left over.
-> Another thing you could test is if that laptop can drive a conventional 8 bit external panel with 12 or more bits via dithering. The gpu can do 12 bits in the 'EnableNative16BitFramebuffer' mode. So far i thought +2 extra bits would be all you could get via dithering, but after your surprising 11 bit result on your MacBookPro, with +3 extra bits, who knows if there's room for more?
-> Yet another interesting option would be booting Linux on your iMac 2014 Retina 5k, again with the dither settings that gave you 11 bpc under macOS, and see if Linux in EnableNative16BitFramebuffer mode can squeeze out more than 11 bpc.
-> It's a pity Apple no longer support "target display mode" for the iMac 2014 Retina 5k (and probably locks it to Apple products anyway), otherwise you could try the HP zBook with the iMac's 10 bit display.
-mario
Thanks.
Best
Denis
