> The VGA stuff will be accessible that way, but for non-x86 platforms, > I figured we'd just disable it and use a graphical console from boot. > Coming from Sun boxes, I'm used to us writing forth code to handle > this from power-on.
It's surely better, and that's what we've been doing so far on linux/ppc, but I've found it occasionally handy to have access to things like VGA text mode. > I agree, so worry not. My last graphics chip didn't support VGA or > even iospace accesses at all. Good :) > My attitude toward VGA is that it is an add-on just to support the > larger userbase of x86 users. Although it's something we're > accounting for from the beginning, it's going to look like an > afterthought, because we're trying to minimize it in every way we can. Excellent. I warmly agree ;) > Given my background, it's going to end up being more flexible than you > need it to be. Excellent. > Already thought of. Stick around and watch the specs. If we forget > something, remind us! Looks like you guys are on the good track then ;) I'll be around. > > In addition, cards like ATI provide a PCI GART which sort-of simulates > > an AGP cards on PCI and PCI-Express. It's fairly handy. The idea is to > > be able to define a linear range of the card's address space that is > > mapped to the system memory via an AGP-like GART table (or IOMMU), thus > > allowing to dynamically bind/unbind portions of system memory into card > > space in a linear way. > > Although nothing is set in stone, there may be grounds for not > supporting AGP. Or if we do, it won't be right away. But there's > still time to debate that issue. Not supporting AGP is a fair choice imho. AGP is just an ugly HW hack that happens to work by mere luck most of the time. The idea of having a remapping table however, is typically useful for the cases where you have _no_ AGP GART. That is PCI and PCI-E typically. With AGP, the table is provided by the host chipset anyway. Any kind of blit to/from memory will require scatter/gather type DMA to handle the fact that user memory is not physically contiguous and having a single big translation table (GART-type) is a simple & efficient way to do it. That is, you dedicate part of the card's own address space to a remapped view of system memory. User applications then, can use the DRM kernel module to "map" and "unmap" things from that GART and/or keep permanently mapped areas like they currently do with AGP, whatever it more efficient. Another way of doing it is to have an "object oriented" organisation of video memory a-la nvidia where a scatter/gather table can be associated with individual "object" descriptors. > Our blit engine can't touch host memory, for security reasons. But I > have specified mechanisms to so all the proper swapping on various > sorts of image upload and download operations. If your cannot do efficient DMAs to/from system memory, you'll have very poor performances with 3D texture uploads/downloads and with modern graphics APIs like EXA. I think the ability for the blitter to blit to/from system memory is critical. I think the "security" issue can be addressed differently. What you could do then is to have the remapping table as described above (that is similar to an AGP GART). That is, open this "window" to system memory that appears to the card like a linear aperture and that goes through a page remapping table. It's up to the software kernel side driver to ensure that only acceptable pages are put in the remapping table. This is what is done for ATI cards today already for PCI and PCI-E (not AGP since in that case the remapping table is provided by the host chipset, but heh, that is pretty much irrelevant). > These things you mention are very important issues, things that not > everyone is aware of, so it's good that you point them out. Thanks ;) > I suspect that there are deeper issues that even I haven't considered, > so please keep them coming. And if they're left out of the prototype, > you can help us to figure that out and make sure they're in there. Sure, I'll try to follow what's going on. Cheers, Ben. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
