Glteapot misrenders on 16bit color

[nephele]

The viewport is double thw size is needs to be, and is double the ammount to the right as it needs to be. This is with the mesa21 RC

Hrev54979+1

[nephele]

Screenshot

[kallisti5]

can you provide a list of what color spaces work / don't work?

Example:

• 15-bit ??
• 16-bit Doesn't work
• 32-bit ??

[X512]

I reimplemented HGL BDirectWindow rendering and it currently supports only RGBX32/RGBA32 format. For other formats it is not supposed to render anything at all. I missed some color format check and it always render to framebuffer like it is RGBA32 format.

[X512]

How does it work with old Mesa package (version 17)?

[nephele]

Replying to kallisti5:

can you provide a list of what color spaces work / don't work?

Example:

• 15-bit ??
• 16-bit Doesn't work
• 32-bit ??

32bit works, the rest doesn't (but the 8bit, 24bit mode are also broken in other ways for me)

[nephele]

Replying to X512:

How does it work with old Mesa package (version 17)?

For me it works with all color modes, the proportions look correct in every mode (as in contained inside the window)

[kallisti5]

I used BBitmap API calls in the original code to copy image data around. The new softpipe rendering code uses this...

​https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/targets/haiku-softpipe/SoftwareRenderer.cpp#n43

Maybe one of the calculations in RasBuf32 breaks on different colorspaces?

[X512]

Maybe one of the calculations in RasBuf32 breaks on different colorspaces?

Well, it is called RasBuf32, so it is true. But it can be easily adjusted for same source and destination color space that is 8 bit or higher (1, 2, 4 bit color will need adding bit offset because pointer can't point to bits). Maybe color bit count conversion will be needed for non-32 bit framebuffer. After my changes Mesa renders directly to BBitmap instead of using additional 32 bit buffer and copying it to BBitmap.

[cocobean]

Using the VESA driver, I tested GLTeapot with Haiku hrev55145 x86_64 w/Mesa 17.1.10. The GLTeapot is consistently running during this testing.

Note: Using VESA driver, GLTeapot viewport is correct at 32bpp color selection. If I switch to another color setting while GLTeapot remains active:

1. 1024x768 @ 8 bits/pixel - GLTeapot display extends vertically outside of app window borders. GLTeapot menu doesn't display properly when selecting selections. GLTeapot is miscolored.

2. 1024x768 @ 16 bits/pixel - GLTeapot display extends vertically outside of app window borders. GLTeapot menu doesn't display properly when selecting selections. GLTeapot is miscolored.

3. 1024x768 @ 32 bits/pixel - GLTeapot display is within app window borders and GLTeapot menu is displaying downwards normally. No display issues.

[nephele]

this ticket is about mesa21

[cocobean]

As discussed in IRC, I reproduced the bug using the VESA video driver w/Mesa17. Using the Nvidia video driver w/ Mesa 17, the GL viewport works correctly as well as retains the GLTeapot(s) color quality in all screen resolutions and color space selections of 15/16/32 bits/pixel.

Note: 8-bits/pixel is not supported by GLTeapot app. GLTeapot app crashed when I selected 8 bits/pixel using the Nvidia driver. GLTeapot app didn't crash using the VESA driver on the same 8 bits/pixel color selection.

The Intel video driver passed (i.e. Haiku R1B3 x86_64 w/Mesa 17). GLTeapot viewport displayed no issues during 8/16/32 bit/pixel color selections. No GLTeapot app crashes.

Need to validate the Radeon video driver issues further with GLTeapot w/Mesa 17 and Mesa 21.

[cocobean]

Progress... bug seems fixed. See: ​https://discuss.haiku-os.org/t/the-graphics-acceleration-can-of-worms/10515/21

Using the VESA driver, I tested GLTeapot with Haiku hrev55306 x86_64 w/Mesa 21.2.0. The GLTeapot is consistently running during this testing.

Note: Using VESA driver, GLTeapot viewport is correct at 32bpp color selection. If I switch to another color setting while GLTeapot remains active:

1024x768 @ 8 bits/pixel - GLTeapot display is within app window borders and GLTeapot menu is displaying downwards normally. No display issues.

1024x768 @ 16 bits/pixel - GLTeapot display is within app window borders and GLTeapot menu is displaying downwards normally. No display issues.

1024x768 @ 32 bits/pixel - GLTeapot display is within app window borders and GLTeapot menu is displaying downwards normally. No display issues.

[nephele]

How did you determine this? I can't build mesa-21.2.1 or mesa-21.2.0 on haiku.

In file included from ../src/util/u_cpu_detect.h:40,
                 from ../src/util/half_float.h:32,
                 from ../src/util/half_float.c:30:
../src/util/u_thread.h:365:16: error: conflicting types for 'thread_id'
 typedef thrd_t thread_id;
                ^~~~~~~~~

[3dEyes]

It's my patchset fixes build problems and adds support for 8 and 16 bit modes.

[kallisti5]

​https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12597 was opened for this one to merge upstream.

I cleaned the patches up a little and broke them apart.