Skip to content

Test gamma at 15bpp and 16bpp #67

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Test gamma at 15bpp and 16bpp #67

wants to merge 2 commits into from

Conversation

JayFoxRox
Copy link
Owner

@JayFoxRox JayFoxRox commented Jan 6, 2020

This actually reveals how the hardware maps 5bit and 6bit colors to 8bit values (sometime before the DAC).
It also confirms that the gamma ramp is done after conversion to 8bpp.

Waiting for hardware recording so I can document the values.

This confirms that 15bpp and 16bpp modes convert 5bit and 6bit values by repeating the MSb in the LSb of the 8bit value:

5bit: ABCDEABCDEABC (where A is the MSb)
6bit: ABCDEFABCDEFAB (where A is the MSb)

You can enable the setting in the gamma ramp generator to showcase this.


Theory behind this test

The gamma ramps are all zero, with a single byte value being 100% brightness.
So if the framebuffer has any byte value, it will lead to 0% brightness, except if that byte has a particular value.

This filter is only enabled for the green and blue channel, so that the text is still visible in red.
Red and blue use the same amount of bits, so we only need one of them (green uses more bits in R5G6B5 mode as humans are more sensitive to it).

The framebuffer then contains gradients in R5G5B5 or R5G6B5 format from left to right with values from 0-31 (red and blue 5-bit value; green in R5G5B5) or 0-63 (green 6-bit value in R5G6B5) and the GPU instructed to output this.

So by "marking" each of the 255 values iteratively we can see which value a pixel has when it is used as input into the gamma ramp.

The first observation is that gamma ramp entries 0 to 255 affect the entire gradient. So the input is 8-bits, regardless of the GPU framebuffer format.
As the gamma ramp entry is 8-bit, we can figure out how a 5-bit or 6-bit value from memory was converted to 8-bit.

So this shows the conversion to 8-bit (aka from 16bpp to 32bpp), and also that the gamma ramp uses 8-bit as input.


The optional code in the second commit just sets up exactly 32 / 64 entries in the gamma ramp to their intended value; the rest is 50% offset to its original value (so black/white turns to gray, gray turns to black/white etc.)

Particularily, the values we set are those that we expect to see from all 5-bit or 6-bit to 8-bit conversion output. The code mimics the conversion that happens in hardware.

So if any bars in the gradient look out of place, then we know that our algorithm for the conversion is wrong. If all of them have the right color, we know that we re-implemented the conversion correctly.

@JayFoxRox JayFoxRox added the unit-test A unit-test (won't be merged) label Jan 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unit-test A unit-test (won't be merged)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant