On 7/12/06, Patrick McNamara <[EMAIL PROTECTED]> wrote:
Each instruction takes four pixel clocks, or put another way, we clock out four pixels per instruction, correct?
Yeah, at this point, we're pushing out 128 bits per clock.
Is there a valid video mode that would require a back porch less than four pixel clocks wide? How about eight? Better yet, how about an odd pixel width for the back porch, front porch, or either blanking interval?
I've never seen anything less than 8, and certainly nothing odd.
Given that the maximum count is 2048, that will set the maximum usable resolution at 2048x2048. Dual link DVI maxes at 2048x1536 which fits ok in that. Max frequency is 330Mhz which means we need to be able to have and instruction rate of 82.5MIPS with zero wasted cycles.
Actually, that makes is 8192x2048. If you want more, you just make a slightly longer program. You can get any size you want.
For a given instruction what is the skew between instruction execution and flag assertion? Will the pixel data have an equal skew? In other words, will the vsync and hsync pulse edges align with the pixel pulse edges. Does it even matter as long as it is within the timing constraints?
It matters, especially for de. And I'm just delaying the syncs in a shift register to keep them lined up.
I assume that we can be fetching a new scanline while we are outputting the current one? In other words, the following code would not corrupt the pixel data (I'm not worried about the syncs here. FETCH 640 ;Fetch a scanline. The data is not completely valid for about 320 instruction cycles DELAY 640 ;We will delay a full scanline just to make sure the data is ready FETCH 640 ;Now, start the 2nd scaline fetch. SEND 640 ;Start output of the first scanline
There's a fifo that's supposed to get hooked up to this that keeps everything in order. It might be good to send out a reset signal every frame to the fifo just to make sure we never get junk data in there. Anyhow, the sample program fetches one scanline early, which is critical, since memory latency is not predictable.
If we cannot do the above, the I don't see how you could ever output progressive scan frames. The horizontal blank is well less than half a scanline in time. For 640x480x60 it is 6.6us or about 26% of a scanline. And we cannot do the following FETCH 640 DELAY 640 SEND 320 FETCH 640 SEND 320 as that would glitch the pixel stream. Either that or I misunderstood the purpose of the SEND operation and how pixel data is clocked out.
Look at the sample program. Notice how at scanline -1, it fetches scanline 0, and it also special-cases the last scanline by not fetching.
I'm also unclear on the purpose of the cursor control flags. I was reading back through the earlier threads and still can't see where they fit in. To know when to turn them on or off would require knowing things about where the program was in the frame buffer vs where the cursor was. That would require test and branch to be included in the controllers instruction set.
They're counters being fed to a separate block. I'll check that into SVN, but I also posted it to the list. The cursor block shifts the cursor data to 1-pixel boundaries and overlays it on the video stream. The cursor overlay is a seperate pipeline, and the cursor counters are just a convenience; I could infer them from the syncs.
In 32bpp mode, a 256 bit memory word represents 4 pixels which is what we clock out per instruction.
128. 256 bits is 8 pixels. We use half a memory word per cycle in 32-bit mode.
In the worst case (1bpp), that same memory represents 256 pixels which is what we clock out per instruction,
I'm not planning support for 1-bit, and in fact, I'm probably going to rip the 8 and 16 out for OGA, since the engine doesn't support anything other than 32.
unless you have a variable output rate so that we still only output 4 pixels per instruction meaning the actual data throughput is a factor of 32 less. Also, how do we output a horizontal resolution not divisible by four? The following come to mind. The same problem occurs for any sync timing that is not evenly divisible by four either.
Eight. But you're right. What I was thinking of doing is ensuring the dequeue occurs at the end of the scanline no matter what or making instruction bit 24 a force-dequeue flag. If we were scanning out 8-bit pixels (32 per memory word), we might want to stop in the middle. BTW, I've encountered plenty of video controllers that had a granularity of 8.
854x480 -- Wide screen 480p 1365/66x768 -- Wide XGA, 768 line format
I don't know how most video controllers would be that specific. I bet the monitors are designed to handle some padding on the right. We should research this.
I hope I'm not just being dense this evening. If I am, please apply the bat of enlightenment. :) I sat down and started pondering a general purpose "display" program. Within some timing limitations I have a sneaking suspicion that it is possible to write a single program to display progressive frames and a single program to display interlaced frames. The modeline interpreter would simply need to tweak a set of fixed locations to effectively "program" the timing parameters in and reload the program. I think, think mind you, that it is possible to write a unified video controller routine for both progressive and interlaced frames using the same ideas.
Well, there's no need to try to be TOO general about it. Let's make one progressive template (with some checks for corner cases), one for interlaced (with a check for optional serration pulses and 1/2 scanlines), and anything else we need to do. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
