Daily transcripts from #opengraphics on irc.freenode.net are located here: http://www.supersecret.org/irc_logs
[01:07] <SecretSquirrel> theosib, around? [01:09] *** voosuz_ is now known as voosuz [01:32] <theosib> I'm here. [01:32] <SecretSquirrel> New version of the mode 0 write pipeline. [01:32] <SecretSquirrel> http://www.supersecret.org/images/VGA_pipe_0.png [01:33] <SecretSquirrel> I'm updating it to encompass the rest of the write modes. [01:33] <theosib> Cool. [01:33] <theosib> Printing [01:34] <SecretSquirrel> How expensing are muxes? [01:34] <theosib> Often, in FPGA's, they're free. [01:35] <SecretSquirrel> That's good. The write pipeline is full of them [01:42] <theosib> Ok, so the rotate rotates which way? [01:42] <SecretSquirrel> Right [01:42] <SecretSquirrel> It's described as a barrel shift right. [01:42] <theosib> That doesn't help me. A little-endian right is a big-endian left. [01:42] <SecretSquirrel> heh [01:43] <SecretSquirrel> bit0->bit7 [01:43] <SecretSquirrel> big endian [01:43] <theosib> Ok, so zero is on the left, right? [01:44] <SecretSquirrel> bah, stupid endians... :) [01:44] <SecretSquirrel> I hope no endians take offense to that. [01:44] <SecretSquirrel> Bit 7 on left, bit 0 on right. [01:45] <theosib> It shouldn't be. [01:45] <SecretSquirrel> bit 0 shifts into bit 7 [01:45] <theosib> X11, for instance, organizes bitmaps on x86 so that bit zero is on the left. [02:43] <SecretSquirrel> http://www.supersecret.org/images/VGA_write_pipe.png [02:52] <SecretSquirrel> hrm, already found an error. Corrected. [02:54] <SecretSquirrel> Ok, I think it is correct now. [02:55] <SecretSquirrel> BTW, it's 300dpi on landscape 11x17 paper. [02:55] <SecretSquirrel> fit's just right on two pages of 8.5x11 in portrait mode. You just have to get out the tape. :) [02:56] <chip> SecretSquirrel: pfft. tape? just use tabloid paper. [03:00] <SecretSquirrel> chip, have to do that at work. [03:00] <SecretSquirrel> I can do E sized plots there. I only have letter and legal at home. [03:08] <theosib> I print it on 8.5x11, but I do it at 1200 DPI to make it readable. [03:13] <theosib> I don't get the 2-4 demux with the and gate. My take on the demux is that only one output is on at a time, but the and gate would require two. [03:14] <theosib> Oh... wait, that's an OR gate. Never mind. :) [03:16] <SecretSquirrel> yup [03:17] <SecretSquirrel> and your right. 2 bits in, 4 lines out. Perhaps I should have labeled it 1-of-4 [03:17] <chip> theosib: any word on the pci spec? [03:18] <SecretSquirrel> I'm pretty sure all the mux selects have the right setup, but I'll need to double check later. After I haven't been staring at it all evening. :) [03:18] <theosib> Not yet, but how much time/effort do you think you can devote? Copies are scarce. [04:10] <chip> 2-3 evenings a week reliably. [04:10] <chip> my summer job starts Monday, and it's a full time deal, plus I have my regular part-time research project. [04:16] <theosib> Patrick, I'm having trouble with... well, you don't have it labeled, but it's the bitmask computing logic. [04:18] <Lord_Icon> ^_^ [05:20] <chip> those are some ginormous diagrams. I need to hook the printer back up to even look at them. [10:24] * el_choya is away: ... regreso al rato [10:24] <Lord_Icon> regreso al rato! [10:25] * el_choya is back (gone 00:01:47) [10:26] <el_choya> Lord_Icon: sorry ,.. I'm in another channel,.. in espa~nol,.. at irc.freenode.net,.. ;) [10:27] <el_choya> and messages seems to apply to all open tab's [10:27] <Lord_Icon> np [10:28] <Lord_Icon> i was just sort of saying stuff [10:28] <Lord_Icon> nothing in particular [10:28] <Lord_Icon> :D [10:30] <el_choya> :) [11:56] <VP> Hi [11:57] <VP> Secret Squirrel: there's an error in the VGA diagram [11:58] <VP> I think the Memory Plane Write Enable register disables writing to individual planes. [11:58] <VP> In your diagram it switches to the read latch instead. All planes get written anyway. [14:41] <SecretSquirrel> VP ugh, you are right. [14:42] <SecretSquirrel> For some reason I was thinking the read latch contained the contents of the location being written to. [14:42] <SecretSquirrel> So selecting it would effectively write the original contents back. [14:42] <VP> check for other places in the pipeline where you made the same assumption [14:42] <SecretSquirrel> I'm not sure how I got that idea... [14:43] <SecretSquirrel> that's the only spot for that particular assumption. :) [14:54] *** sloof3 has left [14:57] <theosib> Something confuses me, then. If I write a single byte, what happens? Nothing? And what if I'm done? How do I flush it? [14:57] <VP> ??? [14:58] <VP> in case you're speaking about VGA, a single 8-bit access from the host results in 32 bits being manipulated by the pipeline (8 bits in each plane) [14:58] <theosib> Since there are no time-stamps, I have no idea how long ago, Squirrel wrote the last thing he wrote. [14:59] <VP> 14 minutes before your first message [14:59] <theosib> Yes, but in email, Patrick implied that each access only caused the pipeline to step by one. [14:59] <theosib> Like, a write does not flow all the way down the pipeline. It just advances it by one. [15:00] <VP> I guess he meant, the next host access can start as soon as the previous access levaes the first pipeline stage [15:01] <theosib> That's fine, but I'm trying to figure out what graphics mode 1 does, and from his diagram, it's a no-op. In email, he said that he could use that to get the pipeline to latch one address for read and write to a different one. [15:02] <theosib> In other words, he's implying that accesses to the pipeline cannot be considered atomic. [15:03] <SecretSquirrel> theosib, not long ago [15:03] <theosib> That is, unless the sense of bitmask is 1=disable. [15:03] <theosib> Then it makes sense. [15:04] <SecretSquirrel> theosib, hang on, let me update the diagram. [15:04] <VP> look carefully at the muxes. some are S&A|~S&B, and some are ~S&A|S&B [15:04] <theosib> Well, I was tired when I did it... [15:08] <theosib> Victor, wanna look at the verilog version of it? Perhaps you can help... [15:09] <VP> sure [15:11] <theosib> Voila. [15:12] <SecretSquirrel> Ok, the diagram has been updated. [15:13] <SecretSquirrel> Thanks for pointing that out Victor. [15:13] <SecretSquirrel> Ok, back to the pipeline and write mode 1 [15:13] <SecretSquirrel> A pipeline write is atomic. [15:13] <SecretSquirrel> There will only ever be one write in progress. [15:14] <theosib> I need to print and examine this one... [15:14] <VP> there can be multiple writes if the read latch is pipelined too, or if a read flushes the pipeline [15:14] <VP> use Eye of Gnome [15:14] <SecretSquirrel> All write mode 1 does is write the contents of the read latch to memory. It ignores the data written by the host. [15:15] <SecretSquirrel> You would have to have very close synchronization between the reads and writes. [15:17] <VP> what's better, reading 512 consecutive bytes or 80 random bytes? [15:17] <SecretSquirrel> From the VGAs point of view, it doesn't matter. [15:17] <VP> I mean the memory controller [15:18] <SecretSquirrel> consecutive, definately. [15:18] <VP> then we should find half a RAM block to load one scanline of the entire font at the start of each scanline [15:19] <VP> and play with the address bits when the font is accessed by the host [15:20] <theosib> I'm still missing something... how does the read latch get a different address from the write address? [15:20] <VP> do we still have a microcontroller to handle PIO access? [15:20] <SecretSquirrel> The read latch is populated during the last memory read operation. [15:20] <VP> the read latch is updated when the host reads. the write pipeline is used when the host writes [15:21] <theosib> This is just two weird. [15:21] <theosib> too? [15:21] <theosib> I'm having a difficult morning. :) [15:22] <SecretSquirrel> Victory, you have to be able to support 8 font maps, and they all reside in memory plane 2. [15:23] <theosib> I assumed, for instance, that the logic ops were there to allow you to combine new pixel bits with old pixel bits at the same address that you're writing to. BUt you're sying that you have to explicitly read it first? [15:23] <SecretSquirrel> Yup. [15:24] <SecretSquirrel> Here is the freeVGA description of writing to VGA memory: http://www.supersecret.org/~mcnamara/freeVGA/www.osdever.net/FreeVGA/vga/vgamem.htm#write [15:25] <VP> / Note, although the bits are organized big-endian, VGA is really [15:25] <VP> / little-endian, where bit-zero is on the left. This is very important [15:25] <VP> / to get correct! [15:25] <VP> (from the VGA Verilog) [15:25] <VP> you got it exactly wrong [15:25] <VP> http://www.osdever.net/FreeVGA/vga/vgaseq.htm [15:25] <theosib> Yeah. I'm saying it's very important to get correct, because I wasn't sure if I had it right. :) [15:26] <theosib> BTW, a lot of this stuff doesn't make sense to me. X11 puts bit zero on the left for x86. [15:26] <VP> X11 doesn't make sense to me :) [15:27] <theosib> It makes perfect sense. If the low-order byte is on the left, then so should the low-order bit. That's the essence of little-endian. [15:27] <SecretSquirrel> In this case since we are working with 8bit values, it doesn't matter whether we represent bit 0 as lefmost or rightmost. [15:27] <VP> endianness is for separately addressable things. bits are not separately addressable on x86 [15:28] <SecretSquirrel> We don't have a low order byte to worry about as we only have one byte. [15:28] <VP> SecretSquirrel: we have to worry about bits in a byte, because on the screen, the pixels _are_ separately addressable [15:29] <theosib> I'm just saying that whoever designed this didn't make it consistent. [15:29] <SecretSquirrel> Yes, but no pixel ever crosses a byte boundary. [15:29] <VP> they do [15:29] <SecretSquirrel> You have 8, 4, 2, or 1 pixels per byte in VGA. [15:30] <VP> in mode 13h, the planes are separately addressable, in some other modes not [15:30] <theosib> Anyhow, so it seems that, based on what you're saying, the only benefit of mode 1 is that it allows you to copy bits 4 times faster. [15:30] <SecretSquirrel> theosib, bingo. :) [15:30] <theosib> VGA makes me choke. [15:31] <SecretSquirrel> VP, the planes are, yes. But the pixels are still 1 pixel per byte. [15:31] <VP> SecretSquirrel: in 4bpp modes, a pixel is spread over 4 planes. when you switch modes, the old content is now spread over 4 pixels [15:32] <theosib> How can you use this to, say, bitblt a huge image one pixel to the left? [15:33] <VP> you can't [15:33] <VP> only 4 pixels [15:33] <SecretSquirrel> VP, yes, but that is delt with at the host level (the splitting of a bit over the four planes). [15:33] <VP> SecretSquirrel: and that's why we have to worry abvout it: our idea of the endianness must agree with the host's [15:33] <SecretSquirrel> 4 in 8bpp mode, 16 in 4bpp mode, 32 in 8bpp mode, etc. [15:35] <SecretSquirrel> I'm not sure I follow, bit0 from the host is connected to bit 0 in the VGA, I don't care if the host puts in on the left and the card puts it on the right. [15:35] <SecretSquirrel> There are still the same bit. [15:35] <VP> see the above Verilog comment [15:36] <theosib> Well, as long as we get it right... :) [15:38] <SecretSquirrel> I still fail to see why bit ordering matters in an 8bit system when (as in Verilog) you are defining a "label" for the bit. [15:40] <SecretSquirrel> I'm wandering off for a bit. Have to clean up the kitchen since the wife is coming home today. [15:40] *** SecretSquirrel is now known as squirrel_away [15:54] <theosib> The bit ordering, technically, doesn't matter. But there's something to be said for consistency and elegance. [15:55] <theosib> elegence? MAN, I need coffee! :) [16:29] <VP> is it possible to tell the memory controller "in the next X ms I will randomly access data in the range Y to Z, please cache it"? [16:30] <VP> at least for some values of (Z-Y) ? [16:39] <theosib> Not exactly, but if you access memory on a certain row, other accesses to the same row will be lower-latency. [16:39] <squirrel_away> How wide are the rows? [16:41] <theosib> Ok, it's kinda complicated. Memory is organized into pairs of 32-bit words. Those pairs are grouped into four sets (8 words), but each set is on a separate memory controller. Typically, a row is 1024 words on a given row. That means one memory row is, basically, 4096 32-bit words. But don't etch that in stone. [16:42] <theosib> Sorry, each PAIR is on a different memory controller. [16:42] <squirrel_away> That's actually good. It means that a text screen would fit in one row. [16:43] <squirrel_away> and the entire VGA memory in 16 rows. [16:43] *** squirrel_away is now known as SecretSquirrel [16:43] <theosib> Pretty much. But from the perspective of the host interface, that lower latency isn't going to help a lot. It's like 4 cycles in the 100Mhz domain. [16:43] <theosib> I mean, it WILL help... [16:44] <SecretSquirrel> Well, the entire VGA memory will fit in 16 rows. [16:44] <SecretSquirrel> That means that when we are doing the conversion to the FB, we won [16:44] <SecretSquirrel> won't take to many penalties for crossing memory rows. [16:46] <SecretSquirrel> I take the view of "always worry about performance". [16:46] <SecretSquirrel> A lot of little things add up and end up makeing for lowsy performance. [16:47] <theosib> The memory controller will try to schedule so as to minimize row misses and keep bursts long. [16:47] <theosib> This is why we like to queue things up in advance in a fifo. [16:47] <SecretSquirrel> Will the FIFO priorities be tunable at runtime? [16:50] <theosib> Possibly... gotta run. [16:50] <SecretSquirrel> later. [19:34] <Lord_Icon> :D [19:55] <SecretSquirrel> theosib, I'm headed out on vacation. I'll be back and Thursday. So when you don't get any response from me for the next four days, thats why. [19:55] <SecretSquirrel> Later all. [22:57] *** chip___ is now known as chip_ _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
