I'm not sure how I ended up sending this only to Daniel, but I have correct this.
On Fri, 18 Mar 2005 00:10:49 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Thursday 17 March 2005 23:04, Timothy Miller wrote: > > On Thu, 17 Mar 2005 22:48:38 -0500, Daniel Phillips wrote: > > > What do you mean by graphics address range? I assume you mean > > > screen coordinates. > > > > No. I mean that drawing surfaces start at linear addresses in the > > graphics memory, and I mean that for protection, you'll have to be > > able to restrict the address ranges that a given application is > > allowed to cause the GPU to access. > > Right. I couldn't parse that because I didn't realize it wasn't going > to be done with handles. > > > > The only additional wrinkle I propose is to upload a privileged set > > > of bounds for scissoring. The card scissors to the intersection of > > > the application's scissor window and the privileged bounds. This > > > lets the application happily scissor away without being able to > > > overwrite anything outside its surface. > > > > Those scissors will differ depending on which of the app's surfaces > > it's attempting to draw to. That is, the max boundaries are an > > attribute of the surface being referred to by a handle. > > Naturally. > > > > We could force reading to respect ownership if we wanted to. But > > > if OGL doesn't care about it, then why should we? > > > > Nothing restricts what you can read from the screen. Ever use xmag? > > OK, we should just define reading as not part of the security model, > until somebody screams about it. > > > Besides, reading the framebuffer is in linear memory, while the > > ownership buffer is rectangular. It would be ugly to try to make the > > host interface respect something that's only designed for the > > rendering pipeline to handle. > > It's not that bad, especially if the internal surface dimensions are > power-of-two. But it is extra, indeed. Maybe this needs to be another > paper feature, or maybe nobody cares. Internal surface dimensions are arbitrary. However, the ownership buffer has to have the same dimensions as the framebuffer. That means they line up both rectangularly and linearly. Still, we don't want to have to burden the host interface with the need to read the ownership buffer before allowing writes to the graphics memory. > > > > As far as wasting bandwidth goes, it won't if it is not turned on. > > > If it is turned on, somebody really wants it, and I can understand > > > why they might. > > > > > > As far as offscreen surfaces goes, why should we provide anything > > > less than the full power of the card to them, including the > > > ownership test? It is just a matter of changing a few pointers and > > > miscellaneous registers, is it not? > > > > That would require creating a proper ownership buffer for any > > off-screen surface you want to draw to. > > No, only if somebody asked for it. I think each surface should come > complete with whatever the application asked for, including zbuffer > etc, and that the driver would sort out what has to be done to switch > between surfaces. The card only has to worry about dereferencing > handles. The driver sets up the handle translation tables. You are right. > > That's a horrible waste of > > memory. Sure, the hardware can do it, but WHY. It's only there for > > window overlapping. > > The ownership buffer is just one of a number of framebuffer-related > resources. Sure, it may be unimportant, but if resources are > virtualized it should just fall out. > > > > Resource handles would be a very good thing. I have been laboring > > > under the assumption that handles would be available. Can we take > > > a look at just how much hardware it needs? I would think, very > > > little. > > > > Instead of one ownership pointer, one destination pointer, one depth > > buffer pointer, and one secondary clipping box, you would need an > > array of each. > > Yes, but what is wrong with that? The card only has to dereference each > handle through memory, a trivial cost compared to the other things > we're doing. Each resource table needs a base address. Is this more > costly than I imagine? What's wrong with it is the extra logic necessary to store them all. Are you suggesting that these resource tables be stored in graphics memory? Even MORE logic to store/fetch that information. There's no way to win here. If you want handle reference to resources, you have to spend logic on it. We're not in the business of spending logic on things that are only useful in 5% of cases. (Although, I'm sure, at user requests, I have done that plenty without realizing it, and it has to end somewhere.) > > I know I've forgotten a number of parameters that > > have to be virtualized. > > Once you drink the resource coolaid, the whole world looks like a > translation table ;-) > > > > > Oh, and in addition, you need to provide indirect > > > > upload/download/access methods for DMA and PIO (unaccelerated) > > > > access to those surfaces as well, also by handle number. > > > > > > I think we ought to have exactly that. These translations are just > > > one-time events, I don't see any performance issue. Maybe I'm > > > missing something, but it seems like just a tiny amount of extra > > > hardware, with big benefits. > > > > The issue is transistor budget. I have provided no way whatsoever to > > have the rendering engine input or output pixels from the host > > interface. > > Wait, I was talking about having the engine translate resource handles > using tables in card memory. I was talking about upload/download of images in a more controlled manner than direct graphics memory access (or simple memory-move DMA). > > ...But if I get too distracted by "future" features, I might forget > > something important for "present" features. > > That's why you have helpers. The object is to get this stuff all nicely > documented and in the wiki, sooner rather than later. You can document stuff, but we need to mark what's practical and what's not. > > > I must ponder the resource handle question. I really assumed it > > > would be part of the initial design. My kneejerk reaction is, we > > > really want this right from the start, if only to keep our PCI > > > traffic from bloating up worse than it is already going to be. > > > > The traffic difference isn't that much. It's the arrays of > > parameters that become an issue. > > Graphics memory addresses are 25 bits, round that up to 32. Texture > handles can be 16 bits, or 8 bits if we want to be clever. Besides > just identifying a texture, we need to know its height and width. (If > we had additional texture formats, we would need to know that too.) > Spelling this all out in the DMA command stream on each texture switch > would be not very nice. Handles solve this tidily, besides having > other benefits like making it easier to move to virtual texture memory > later. Look at it this way: To store the base address for, say, the destination buffer, you need 32 bits in a register somewhere. If you want to go by handle, then you need a place to store 16 of those, which is 512 bits. Now, it won't require 16 times as much logic in the FPGA (maybe only double), but it will bloat up in the ASIC. Mind you, there are parts of this design that are much more bloated than this, but we have priorities here. > > There's a small change it wouldn't actually take up much more logic, > > owing to the architecture of Xilinx FPGAs, although it would > > certainly affect the ASIC (which has more breathing room). > > > > But I am human, and we need to limit my opportunities to err. > > Resource handles would be nice. If it is easy for the FPGA, isn't that > the only real issue? No. :) > (By the way, did you mean this to be off-list? If not, I will repost to > the list.) No, and fixed. Thank you. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
