<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">> You missed a couple steps there. That's at 60fps, and three colors per<br>
> pixel at one byte each.<br>
<br>
Indeed. I knew I was missing something, but just couldn't put my finger<br>
on it. Obvious in hindsight.<br>
<br>
> but youre still talking about ~190MB/s, on a bus that can<br>
> only theoretically hit 133MB/s.<br>
<br>
Indeed.<br>
<br>
> Now the UI is not going to be full motion video, so it won't need<br>
> anything like that kind of bandwidth,<br>
<br>
But the UI is still 1920x1080x24x60 (perhaps /2) isn't it? There's no<br>
bandwidth savings for still images are there? Isn't every pixel of that<br>
1920x1080x12 sent 60 times a second regardless of whether it's changed<br>
or not?<br>
<br></blockquote><div><br></div><div>Graphics systems typically use a framebuffer that gets filled and the actual display is updated from there. Sure the screen refreshes at 60fps or more... but the system only sends data to the framebuffer as needed. In fact, most 2d accelerated graphics cards (just about every card these days) don't even require that the system send an entire frame but instead allow just changed frames to be sent. (this is the difference between safe mode/VGA mode graphics and normal).</div>
<div><br></div><div>Mythtv used to be able to run in a framebuffer without using x-windows at all. Instead the UI and the video would be sent directly to the video card. </div><div><br></div><div>I may be a bit off on the technical details... but you get the point, rarely is the entire frame of information sent to the card for every vertical refresh... video comes closest, but still doesn't come close to requiring that much data across the pci bus (as I understand it).</div>
</div>