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 - if the GLTeapot is consistently running (not restarted) during display color setting modifcations (i.e. when user is switching display color settings while the app is running).

If you start GLTeapot after you switch to 16bpp, here are the results:

Note:

1. The Intel video driver passed (i.e. Haiku R1B3 x86_64 w/Mesa 17). GLTeapot viewport displayed no issues.

2. The Nvidia video driver passed (i.e. Haiku R1B3 x86_64 w/Mesa 17). GLTeapot viewport displayed no issues.

3. The VESA video driver passed (i.e. Haiku R1B3 x86_64 w/Mesa 17). GLTeapot viewport displayed no issues.

NOTE: I was told the bug was seen with the radeon_hd video driver at the 16bpp color setting. I reproduced the bug switching the display color settings (i.e. 32bpp to 16bpp) using the VESA driver while keeping the GLTeapot consistently active (i.e. not restarting it during color setting changes).

[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.