Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by ynajjarine | Hacker News Reader

Parent Full thread

ynajjarine·

[flagged]

View on HN

I bet there's some way to make the GPU do the color conversion. It's not like it's doing much otherwise...

It looks like copying from EFB to XFB can do an RBG to YUV conversion automatically.

Last I checked, the 60fps frame buffer conversion resulted in the system idling at 18% CPU. Certainly not ideal. I'd love to optimize this further.

Presumably Wii has AltiVec that you could use to accelerate the conversion? Did you happen to look into the code the compiler generates for your loop around rgbrgb16toycbycr?

This solution’s COU cost can be significantly improved by using memory protection. You protect the frame buffer from writes. The first time it is written, you take a fault, and start refreshing every 60 Hz and leave it writeable. After some number of refreshes, you protect it again, the idea being is that the UI may now be quiescent. I do this in my Palm OS port for the same reason.

I'm intrigued by this technique! Will look into it, thanks for the tip!

sample impl is in rePalm sources, but i described basically all there is to it :)

saves a lot of CPU

This would work for an idle screen but I can't imagine this would be very efficient for real use, unless the hardware cursor is put in some other framebuffer (I assume it's not otherwise the author would have probably mentioned it?)

on computer timescales, humans are basically motionless, as long as there is motion, you do the 60Hz update, occasionally you take a page fault too, not a high cost compared to a screenfull of colorpsace conversion. But when display is not changing you save a lot of cpu power.

But also Wii has the gpu abilities to trivially support hardware cursor

Reply on news.ycombinator.com