You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
gfx/gl1: Upload RGUI menu framebuffer directly as RGBA4444
Previously the GL1 driver expanded RGUI's 16bpp framebuffer to 32bpp on
the CPU every frame via conv_rgba4444_argb8888 before uploading it as
BGRA8888. The expansion was a per-pixel loop (with an MMX fast path on
x86) and doubled the GPU upload bandwidth. RGUI already assembles its
framebuffer in RGBA4444; GL has been able to consume that layout
directly via GL_UNSIGNED_SHORT_4_4_4_4 since GL 1.2 (1998).
Add a SUPPORTS_PACKED_PIXELS capability flag, probed once at init from
the GL version (>= 1.2) or the GL_EXT_packed_pixels extension. When
set, the menu draw path keeps RGUI's native 16bpp layout end-to-end:
rows are memcpy'd into a POT-padded staging buffer at half the previous
size and uploaded via (GL_RGBA, GL_UNSIGNED_SHORT_4_4_4_4) with no
swizzle or expansion. The original 32bpp expansion path is preserved
as a fallback for strict GL 1.1 implementations and for the Vita build
(vitaGL packed-pixel paths are unverified).
The new path is endian-safe by construction. RGUI's argb32_to_rgba4444
produces a host-endian uint16_t with R in bits 15..12 and A in bits
3..0; glTexImage2D reads each GL_UNSIGNED_SHORT_4_4_4_4 unit through
the host's native uint16_t interpretation, so the same source bytes
work on LE and BE hosts without a byte swap.
gl1_draw_tex gains a fb_4444 parameter that selects the new upload
format and skips the BGRA-fallback CPU swizzle (the 16bpp path's bytes
already match GL_RGBA channel order). All three existing callers
update accordingly; the content path passes false and is byte-identical
to before.
Removes the misleading "I could not get 444 or 555 to work" FIXME on
the original gl1_draw_tex; this commit is what it asked for.
0 commit comments