Hrm, now I'm pretty sure I'm being dense. I can't even do math properly. You are correct, there are 8 pixels per 256bit memory word. 8 bits per byte x 4 bytes per pixel * 8 pixels does in fact equal 256 bits. Imagine that. :) ----- Original Message ---- > From: Timothy Miller <[EMAIL PROTECTED]> > To: Patrick McNamara <[EMAIL PROTECTED]> > Cc: Open Graphics Project List <[email protected]> > Sent: Thursday, July 13, 2006 5:55:09 AM > Subject: Re: Questions about the video controller... > > 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. That would be video controller instruction clock, not pixel clock, correct? Pixel clock is effectively instruction clock time four, yes? > >> 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. > Good enough. Does anybody have a reference they could point to for the expected timing values for value video modes? >> >> 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. Yeah, that whole math thing again. More comments on longer programs below. > >> 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. > What this means is that the output to the display device will be delayed some time T from the percieved execution time of the video controller. This may sound like stating the obvious since we all know that logic is not instantaneous, but I was thinking more along the lines of T possibly being one or multiple pixel clocks, even perhaps multiple instruction clocks. This really shouldn't matter but I figured it was worth stateing. >> >> 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. And that is what I was getting at. We have to fetch one scanline early, meaning that we have to be able to start the fetch of scanline n+1 right before we start outputting scanline n. I think it may be that there is a bug in the original example that made things confusing. vactive: FETCH [+v,-h,-d] #1 ; last 4 pixels of hsync <--- Should this be #640? NOOP [+v,+h,-d] #2 ; back porch SEND [+v,+h,-d] #640 ; active period, but vblank NOOP [+v,+h,-d,ret] #2 ; front porch If the answer to the above question is yes, then we are in agreement and I was understanding things correctly as that would start the fetch of the next line of pixel data prior to displaying the current one. > >> 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. > That part of it I get. My question is this: Do we continue clocking out valid pixel data even when we are not executing a send instruction? If the answer is no, the we cannot send 8192 pixels per line since we would have to break it up into two send instructions and two fetch instructions. Since you would have to interleve them you would have a four pixel clock period when we were not clocking out valid pixels out, but the display device was expecting them. Not that an 8192x2048 display is exactly small or anything. :) If we do continue outputting the contents of the pixel fifo for commands other than send, we need to take that into account in the programs. >> >> 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. I'll have to go dig into the cursor overlay code. I guess my question was "When would we want to set these flags in a video controller program?" And given that the "when" might change from frame to frame, "How would we detect that we were at the correct point to assert the flags?" Right now, it appears to me that those flags will never be used in video controller program. > >> 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. That is something we need to be aware of then. If the frame buffer is always 32bpp then any interaction with that frame buffer will have to be translated on the fly. I'm specifically thinking about VGA and VESA modes here, but the problem would exist for X running in something other than 32bpp as well. This also limits the output devices we can support. I know it's probably unusual to run across a display that is not capable of accepting 24bit color input, but in the embedded space when you may be using lower end LCD panels that is something we need to factor in. I certainly don't have a problem with using fixed 32bpp internally, we just need to make sure that we can still output to any device we could ever conceivable want to talk to. > >> 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. > Browsing through all various resolutions I could find on the net the two above were the only ones that I could find that were not evenly divisible by eight, so perhaps it is not a big issue. Going back to an earlier question, are all the various sync timings going to be visible by eight? >> >> 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. As another piece of information, here is some of the more common timing parameters we will need: http://www.xfree86.org/3.3.6/Config7.html Patrick M _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
