Re: XAA2 namespace?
On Tue, 6 Apr 2004, Mark Vojkovich wrote: I saw changes coming to the X world that I didn't like and started moving away from it a while ago. Pardon that public reply folks. I mistakenly replied to the list rather than just to Alan like I intended. If you don't mind answering anyway... Are these undesirable changes related to XFree86 or to X in general ? If they relate to X in general, what are they ? -- Andrew C. Aitchison Cambridge [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Wed, 7 Apr 2004, Andrew C Aitchison wrote: On Tue, 6 Apr 2004, Mark Vojkovich wrote: I saw changes coming to the X world that I didn't like and started moving away from it a while ago. Pardon that public reply folks. I mistakenly replied to the list rather than just to Alan like I intended. If you don't mind answering anyway... Are these undesirable changes related to XFree86 or to X in general ? If they relate to X in general, what are they ? It started when Keith and Jim decided to pressure the XFree86 project on behalf of Linux distributions who felt that the XFree86 project wasn't acting in line with their business plans. There are companies who make money from bundling up software that they didn't write, yet don't feel that what they've gotten will allow them to compete with Microsoft the way they'd like. After seeing the courses of action that those parties have decided to take, I realized that it would become more and more unlikely that I'd be happy working in such an environment. This is my hobby. I don't do it for any religious or political reasons. When it become for aggravating than fun, it's time to move to another hobby. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
Mark, What's the current status of the new xaa ?? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, 6 Apr 2004, Alan Hourihane wrote: Mark, What's the current status of the new xaa ?? Not much has changed. I've been busy with work and lately haven't been too motivated to work on it anyhow. I don't even work on X stuff at NVIDIA anymore. I saw changes coming to the X world that I didn't like and started moving away from it a while ago. I work on embedded stuff now. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
Pardon that public reply folks. I mistakenly replied to the list rather than just to Alan like I intended. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
On Wed, 2004-03-03 at 03:59, Mark Vojkovich wrote: Even with Sync() passing the particular surface which is necessitating the sync, I would expect all drivers to be syncing the whole chip without caring what the surface was. Most hardware allow you to do checkpointing in the command stream so you can tell how far along the execution is, but a Sync can happen at any time. Are you really going to be checkpointing EVERY 2D operation? That's where a driver callback to mark the end of a batch of rendering to (and from?) a surface might come in handy? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
Mark Vojkovich wrote: On Tue, 2 Mar 2004, Sottek, Matthew J wrote: It's currently global because the hardware I work on doesn't have to fall back to software very often. Bookkeeping on a per- surface basis is a simple modification and one I will add. This precludes using XAA2 with hardware that doesn't support concurrent SW and HW access to the framebuffer, but that's OK since that stuff is old and we're trying to move forward here. HW that sucks can use the old XAA. It shouldn't preclude this from working. You just need the call to look like sync(xaa_surface_t *surface) and let old hardware sync the whole engine regardless of the input. It helps those who can use it and is the same as what you have now for everyone else. I don't understand your reasoning. The difference with per-surface as opposed to global sync state is that you don't have to sync when CPU rendering to a surface that has no previously unsynced GPU rendering. The point of this is to ALLOW concurrent CPU and GPU rendering into video ram except in the case where both want to render to the same surface. There are old hardware that allow no concurrent CPU and GPU rendering at all. Even with Sync() passing the particular surface which is necessitating the sync, I would expect all drivers to be syncing the whole chip without caring what the surface was. Most hardware allow you to do checkpointing in the command stream so you can tell how far along the execution is, but a Sync can happen at any time. Are you really going to be checkpointing EVERY 2D operation? Not every operation, but every few operations. For example, the Radeon 3D driver has a checkpoint at the end of each DMA buffer. It's more coarse grained than every operation, but it's much finer grained than having to wait for the engine to idle. I still contend that it would be a benefit to know how many rects associated with the same state are going to be sent (even if you send those in multiple batches for array size limitations) this allows a driver to batch things up as it sees fit. I don't know the amount of data coming. The old XAA (and cfb for that matter) allocated the pathelogical case: number of rects times number of clip rects. It doesn't know how many there are until it's done computing them, but it knows the upper bounds. I have seen this be over 8 Meg! The new XAA has a preallocated scratch space (currently a #define for the size). When the scratch buffer is full, it flushes it out to the driver. If XAA is configured to run with minimal memory, the maximum batch size will be small. That sounds reasonable. That's basically how the 3D drivers work. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
Ummm... which other models are you refering to? I'm told that Windows does it globally. Windows Direct Draw does per surface Locking which is a similar thing to what we are discussing, and yes, many drivers DO checkpoint very often. Direct Draw isn't a perfect analogy because it is the application that often wants to render to the surface with the CPU so there are many clients running in parallel. That compounds the impact of waiting too long for your sync. Having per-surface syncing may mean you end up syncing more often. Eg. Render with HW to one surface then to another, then if you render to SW to both of those surfaces, two syncs happen. Doing it globally would have resulted in only one sync call. The driver has to take a little responsibility for knowing when it is out of sync. A global syncing driver would need to handle that second sync without any hardware interaction. The penalty is just the added indirect function call. This common scenario would be improved with per-surface sync: Put Image - offscreen_surface1 ... offscreen_surface1 - FB ... Put Image - offscreen_surface1 The offscreen surface cannot be written until after the blit is finished so a sync is needed. However on a busy system there are lots of other blits going on during the ... so global syncing before the 2nd Put is bad on 2 accounts. 1) You waited longer than you needed to, you only needed to wait for the blit that referenced offscreen1. 2) You idled the hardware while the 2nd put is happening. Now the graphics engine is idle instead of crunching data in parallel. Does the possible improved concurrency outweigh the additional overhead of making an indirect call to check the sync status everytime? It is Hard to tell. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
It's the best we can do. I'm not going to compute the clips in two passes: one to find out how many rects there end up being, and one to store the rects. At least you would be able to indicate the last one which would serve the same purpose. Or an optional flush call to the driver. A batching driver could queue stuff up until a flush. A flush would happen after a set of operations that originated as a single complex drawing operation. XAA doesn't care about surface particulars. It asks the driver if it could stick this pixmap in videoram for it because the migration logic says it should go in videoram. The driver can refuse or can accept by returning an XAASurface for it. XAA passes that surface back to you in the SetupFor function. To XAA, it's just a device independent structure. The driver has private storage in the XAASurface. Sounds reasonable. How does X tell the driver what the surface will be used for? A RENDER surface could have different alignment or tiling properties than a 2d only surface. That information would be needed at allocation time. There's no such thing as a RENDER surface. Pictures are merely X-drawables with extra state associated with them. Any drawable can eventually be used as a picture. You will need to keep that in mind just as you do now. This has pretty serious implications. Currently the memory manager uses rectangular memory which presumably has pitch etc characteristics that are usable by the stretch blit/alpha blend components of a chip. That makes it reasonable (although probably not ideal) to assume that any offscreen surface can be used for RENDER purposes. Moving to a surface based infrastructure would allow a driver to more carfully choose surface parameters... always choosing the worst case alignment,pitch, etc characteristics seems like a problem. This may be a RENDER problem and not just an Xaa problem, but it seems like there really needs to be prior indication that a surface is being used as a RENDER source or target such that the memory manager can make appropriate choices. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
Mark Vojkovich wrote: Ummm... which other models are you refering to? I'm told that Windows does it globally. Having per-surface syncing may mean you end up syncing more often. Eg. Render with HW to one surface then to another, then if you render to SW to both of those surfaces, two syncs happen. Doing it globally would have resulted in only one sync call. Unless you can truely checkpoint every rendering operation, anything other than global syncing is going to result in more sync calls. The more I think about going away from global syncing, the more this sounds like a bad idea. It may result in more sync calls, but it should also result in less time spent waiting in each call. If you HW render to surface A, then B, then need to SW render to surface A, you don't need to wait for the HW to finish with surface B. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
On Wed, 3 Mar 2004, Sottek, Matthew J wrote: Ummm... which other models are you refering to? I'm told that Windows does it globally. Windows Direct Draw does per surface Locking which is a similar thing to what we are discussing, and yes, many drivers DO checkpoint very often. Well, I'll add per surface locking then. You'll get passed a surface when you are asked to sync. Drivers that don't support per-surface synchronization, which I expect to be the majority, will have to do more work to keep from doing redundant syncs. They'll essentially have to keep track of whether or not they rendered anything since the last time Sync was called. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
On Wed, 3 Mar 2004, Sottek, Matthew J wrote: Your rectangle array design would only send an array of rectangles that come from the spans of a larger polygon? Maybe the driver can attempt to fix it there. The array only contains parts of a larger single rendering request. But note that XFillRectangles is a single request. All the rectangles passed down in that request will show up in the array. A single XFillRectangle may still be multiple rectangles due to clipping, and complex primitives like filled arcs will end up as many rectangles regardless. The only time XAA will break these up into multiple Subsequent requests is when XAA's internal buffer isn't big enough to buffer all the pieces. The driver can buffer these requests, even across different surfaces, for as long as it likes as long as it sends them to the hardware before the BlockHandler exists. Up until that point you can send it to the hardware based on whatever criteria you like: after a certain amount of data has been placed in the DMA buffer, after an approximate amount of pixels have been asked to be filled, etc... The nv driver buffers all requests until the block handler or until after a primitive of a certain size is encountered. The goal being to buffer as much as possible but to limit latency by limiting the buffering to small primitives. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
On Mon, 2004-03-01 at 18:58 -0800, Mark Vojkovich wrote: On Mon, 1 Mar 2004, Sottek, Matthew J wrote: Will there be open discussion of what makes up Xaa? I know you have already have a working design but rather than accept major changes wholesale can we discuss the finer points before they become defacto-accepted. -Matt It depends what you'd like to discuss. I already have a working implementation. It does not preclude usage of the old XAA. A driver can use either one. Nobody has to touch old drivers if they don't want to. Anything you can post here? Would an XAA2 driver be more easily usable in other scenarios than XFree86, eg SkyOs etc? The goals of XAA2 are: 1) Smaller. It's currently about one fifth the XAA size. There was too much benchmark rigging in XAA. It's not justified. 2) Following from #1, all of the optimizations for hardware with MMIO interfaces has been removed. XAA spent alot of code on CPU/GPU interleaving. Command buffer-based engines don't care about this. XAA2 will be slower in x11perf on MMIO engines but about the same as XAA for command buffer engines. 3) No assumptions about offscreen memory usage. Leave it entirely up to the driver. I'll provide a sample linear heap manager. You can use whatever you want. 4) Messy stuff like the triple-bits and rgb-equal in XAA will not be supported except as a complete fallback to software at GC validation time. There is no per-primitive GC validation like there was in XAA because apps just don't work that way. They trash validation so much that it needs to be lightweight. Mark. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Vojkovich Sent: Monday, March 01, 2004 4:19 PM To: [EMAIL PROTECTED] Subject: XAA2 namespace? The current XAA has functions starting with XAA and header files starting with xaa. To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards Xaa for the functions and header files. Any concerns? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- Torgeir Veimo [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
Is the Nvidia closed source driver based on a early version off Xaa2? Mark Vojkovich wrote: On Mon, 1 Mar 2004, Sottek, Matthew J wrote: Will there be open discussion of what makes up Xaa? I know you have already have a working design but rather than accept major changes wholesale can we discuss the finer points before they become defacto-accepted. -Matt It depends what you'd like to discuss. I already have a working implementation. It does not preclude usage of the old XAA. A driver can use either one. Nobody has to touch old drivers if they don't want to. The goals of XAA2 are: 1) Smaller. It's currently about one fifth the XAA size. There was too much benchmark rigging in XAA. It's not justified. 2) Following from #1, all of the optimizations for hardware with MMIO interfaces has been removed. XAA spent alot of code on CPU/GPU interleaving. Command buffer-based engines don't care about this. XAA2 will be slower in x11perf on MMIO engines but about the same as XAA for command buffer engines. 3) No assumptions about offscreen memory usage. Leave it entirely up to the driver. I'll provide a sample linear heap manager. You can use whatever you want. 4) Messy stuff like the triple-bits and rgb-equal in XAA will not be supported except as a complete fallback to software at GC validation time. There is no per-primitive GC validation like there was in XAA because apps just don't work that way. They trash validation so much that it needs to be lightweight. Mark. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Vojkovich Sent: Monday, March 01, 2004 4:19 PM To: [EMAIL PROTECTED] Subject: XAA2 namespace? The current XAA has functions starting with XAA and header files starting with xaa. To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards Xaa for the functions and header files. Any concerns? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
Will there be open discussion of what makes up Xaa? I know
you have already have a working design but rather than accept
major changes wholesale can we discuss the finer points before
they become defacto-accepted.
-Matt
It depends what you'd like to discuss. I already have a
working implementation. It does not preclude usage of the
old XAA. A driver can use either one. Nobody has to
touch old drivers if they don't want to.
I'd like to discuss the design details. Why don't you send the
relevant parts of the header to the list for discussion before
you commit it? Lets face it, once the code is committed there
is not going to be as much room for change. If Xaa is being
replaced then it seems fitting that everyone have a chance to
review and comment on the design before it is committed.
1) Smaller. It's currently about one fifth the XAA size. There
was too much benchmark rigging in XAA. It's not justified.
Smaller is good, but can you give an example of benchmark
rigging?
3) No assumptions about offscreen memory usage. Leave it entirely
up to the driver. I'll provide a sample linear heap manager.
You can use whatever you want.
So is the new design surface based? i.e. blits are coordinates
relative to a surface (off-screen or on-screen). If so, this is
good. The rectangular memory single surface Xaa is not a very
good match for modern hardware.
Also, I would like to make sure that the new design has a much
improved syncing mechanism. Syncing should be, at a minimum,
on a per-surface basis. Perhaps even a bounded region of a
surface is justified. As GUI's become more media rich the
amount of data coming from the CPU to the graphics engine is
increasing. This means more puts and consequently lots of syncing
for many hardware types. The current global sync design waits
too long and forces idle time unnecessarily. Other driver models
abandoned the single sync a long time back.
I think we should also address the setup for...subsequent
design concept. Seems like most designs would be better fit
with a single entry point that provides all the information,
perhaps with an n option to indicate how many such calls are
expected with the same setup data. Command engines could then
batch commands together, or a driver could send a batch of
commands to a kernel driver. In my opinion it is more useful to
know how many similar commands are being sent (or at least know
when the last one is sent) than the current method.
Currently:
setup_for_foo()
while(i--) {
subsequent_foo()
}
could be
while(i--) {
do_foo(i);
}
or alternatively (if you can't know how many until you are done)
while(i--) {
do_foo();
}
last_foo();
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
--- Sottek, Matthew J [EMAIL PROTECTED] wrote: Will there be open discussion of what makes up Xaa? I know you have already have a working design but rather than accept major changes wholesale can we discuss the finer points before they become defacto-accepted. -Matt It depends what you'd like to discuss. I already have a working implementation. It does not preclude usage of the old XAA. A driver can use either one. Nobody has to touch old drivers if they don't want to. I'd like to discuss the design details. Why don't you send the relevant parts of the header to the list for discussion before you commit it? Lets face it, once the code is committed there is not going to be as much room for change. If Xaa is being replaced then it seems fitting that everyone have a chance to review and comment on the design before it is committed. good alpha channel support would be nice too, although that might require some other changes. Alex [snip] __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, 2 Mar 2004, [ISO-8859-1] Frank Gießler wrote: Mark Vojkovich wrote: We don't care what the filenames are except for the header files. The only reason why we care about header files is that a driver might include support for both and may need both include paths. There's only one exported header file. I'd like to name it Xaa.h to match the namespace. Is it really going to be relevant on case-unaware systems? Which ones are those BTW? There is already xaa.h. Having Xaa.h included at the same time is a no-op for OS/2, for which there are already binaries for 4.4.0 available (I would therefore consider this a well supported platform). Well, then I guess I could call the header file xaa2.h Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, 2 Mar 2004, Knut J Bjuland wrote: Is the Nvidia closed source driver based on a early version off Xaa2? The NVIDIA binary driver has a stripped-down and slightly hacked up version of XAA2 in it. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, Mar 02, 2004 at 10:57:04AM -0800, Mark Vojkovich wrote: On Tue, 2 Mar 2004, [ISO-8859-1] Frank Gießler wrote: Mark Vojkovich wrote: We don't care what the filenames are except for the header files. The only reason why we care about header files is that a driver might include support for both and may need both include paths. There's only one exported header file. I'd like to name it Xaa.h to match the namespace. Is it really going to be relevant on case-unaware systems? Which ones are those BTW? There is already xaa.h. Having Xaa.h included at the same time is a no-op for OS/2, for which there are already binaries for 4.4.0 available (I would therefore consider this a well supported platform). Well, then I guess I could call the header file xaa2.h Not to be too picky, but won't this be the third version of XAA, not the second? David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, 2 Mar 2004, David Dawes wrote: On Tue, Mar 02, 2004 at 10:57:04AM -0800, Mark Vojkovich wrote: On Tue, 2 Mar 2004, [ISO-8859-1] Frank Gießler wrote: Mark Vojkovich wrote: We don't care what the filenames are except for the header files. The only reason why we care about header files is that a driver might include support for both and may need both include paths. There's only one exported header file. I'd like to name it Xaa.h to match the namespace. Is it really going to be relevant on case-unaware systems? Which ones are those BTW? There is already xaa.h. Having Xaa.h included at the same time is a no-op for OS/2, for which there are already binaries for 4.4.0 available (I would therefore consider this a well supported platform). Well, then I guess I could call the header file xaa2.h Not to be too picky, but won't this be the third version of XAA, not the second? Yes, it's actually the third. Harm's was the first. I think we even advertised XFree86 4.x's XAA as 2.0. Would you prefer xaa3.h ? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, 2004-03-02 at 21:06, Mark Vojkovich wrote: On Tue, 2 Mar 2004, David Dawes wrote: On Tue, Mar 02, 2004 at 10:57:04AM -0800, Mark Vojkovich wrote: Well, then I guess I could call the header file xaa2.h Not to be too picky, but won't this be the third version of XAA, not the second? Yes, it's actually the third. Harm's was the first. I think we even advertised XFree86 4.x's XAA as 2.0. Would you prefer xaa3.h ? As everyone knows, counting starts at 0, so xaa2 in fact denotes the third XAA. :) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
On Tue, 2 Mar 2004, Sottek, Matthew J wrote: It's currently global because the hardware I work on doesn't have to fall back to software very often. Bookkeeping on a per- surface basis is a simple modification and one I will add. This precludes using XAA2 with hardware that doesn't support concurrent SW and HW access to the framebuffer, but that's OK since that stuff is old and we're trying to move forward here. HW that sucks can use the old XAA. It shouldn't preclude this from working. You just need the call to look like sync(xaa_surface_t *surface) and let old hardware sync the whole engine regardless of the input. It helps those who can use it and is the same as what you have now for everyone else. I don't understand your reasoning. The difference with per-surface as opposed to global sync state is that you don't have to sync when CPU rendering to a surface that has no previously unsynced GPU rendering. The point of this is to ALLOW concurrent CPU and GPU rendering into video ram except in the case where both want to render to the same surface. There are old hardware that allow no concurrent CPU and GPU rendering at all. Even with Sync() passing the particular surface which is necessitating the sync, I would expect all drivers to be syncing the whole chip without caring what the surface was. Most hardware allow you to do checkpointing in the command stream so you can tell how far along the execution is, but a Sync can happen at any time. Are you really going to be checkpointing EVERY 2D operation? I still contend that it would be a benefit to know how many rects associated with the same state are going to be sent (even if you send those in multiple batches for array size limitations) this allows a driver to batch things up as it sees fit. I don't know the amount of data coming. The old XAA (and cfb for that matter) allocated the pathelogical case: number of rects times number of clip rects. It doesn't know how many there are until it's done computing them, but it knows the upper bounds. I have seen this be over 8 Meg! The new XAA has a preallocated scratch space (currently a #define for the size). When the scratch buffer is full, it flushes it out to the driver. If XAA is configured to run with minimal memory, the maximum batch size will be small. Currently a driver cannot batch things efficiently because there is no way to know when the end of the batch should happen. An array of rects is a good start but not a complete solution. It's the best we can do. I'm not going to compute the clips in two passes: one to find out how many rects there end up being, and one to store the rects. I also have some questions regarding the memory management. Who is responsible for system memory surfaces (and any migration to/from video memory)? System memory pixmaps are handled by fb as always. XAA2 holds the migration logic. Who is responsible for populating surfaces? Does X get a virtual address (or offset from base), width, height, pitch and populate the surface itself or does the driver have to handle cpu_to_screen to do it? What about unknown surface types? (compressed?) XAA doesn't care about surface particulars. It asks the driver if it could stick this pixmap in videoram for it because the migration logic says it should go in videoram. The driver can refuse or can accept by returning an XAASurface for it. XAA passes that surface back to you in the SetupFor function. To XAA, it's just a device independent structure. The driver has private storage in the XAASurface. How does X tell the driver what the surface will be used for? A RENDER surface could have different alignment or tiling properties than a 2d only surface. That information would be needed at allocation time. There's no such thing as a RENDER surface. Pictures are merely X-drawables with extra state associated with them. Any drawable can eventually be used as a picture. You will need to keep that in mind just as you do now. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
On Tue, 2 Mar 2004, Sottek, Matthew J wrote: Also, I would like to make sure that the new design has a much improved syncing mechanism. Syncing should be, at a minimum, on a per-surface basis. Perhaps even a bounded region of a surface is justified. As GUI's become more media rich the amount of data coming from the CPU to the graphics engine is increasing. This means more puts and consequently lots of syncing for many hardware types. The current global sync design waits too long and forces idle time unnecessarily. Other driver models abandoned the single sync a long time back. Ummm... which other models are you refering to? I'm told that Windows does it globally. Having per-surface syncing may mean you end up syncing more often. Eg. Render with HW to one surface then to another, then if you render to SW to both of those surfaces, two syncs happen. Doing it globally would have resulted in only one sync call. Unless you can truely checkpoint every rendering operation, anything other than global syncing is going to result in more sync calls. The more I think about going away from global syncing, the more this sounds like a bad idea. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Mon, Mar 01, 2004 at 04:19:21PM -0800, Mark Vojkovich wrote: The current XAA has functions starting with XAA and header files starting with xaa. To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards Xaa for the functions and header files. Any concerns? That'll be bad for those case-insensitive systems. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Mon, Mar 01, 2004 at 04:19:21PM -0800, Mark Vojkovich wrote: The current XAA has functions starting with XAA and header files starting with xaa. To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards Xaa for the functions and header files. Any concerns? So, based on the case problem... I'd go with Xaa_Line.c instead of the current xaaLine.c and you can still use Xaa() for the functions. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
Will there be open discussion of what makes up Xaa? I know you have already have a working design but rather than accept major changes wholesale can we discuss the finer points before they become defacto-accepted. -Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Vojkovich Sent: Monday, March 01, 2004 4:19 PM To: [EMAIL PROTECTED] Subject: XAA2 namespace? The current XAA has functions starting with XAA and header files starting with xaa. To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards Xaa for the functions and header files. Any concerns? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
On Mon, 1 Mar 2004, Sottek, Matthew J wrote: Will there be open discussion of what makes up Xaa? I know you have already have a working design but rather than accept major changes wholesale can we discuss the finer points before they become defacto-accepted. -Matt It depends what you'd like to discuss. I already have a working implementation. It does not preclude usage of the old XAA. A driver can use either one. Nobody has to touch old drivers if they don't want to. The goals of XAA2 are: 1) Smaller. It's currently about one fifth the XAA size. There was too much benchmark rigging in XAA. It's not justified. 2) Following from #1, all of the optimizations for hardware with MMIO interfaces has been removed. XAA spent alot of code on CPU/GPU interleaving. Command buffer-based engines don't care about this. XAA2 will be slower in x11perf on MMIO engines but about the same as XAA for command buffer engines. 3) No assumptions about offscreen memory usage. Leave it entirely up to the driver. I'll provide a sample linear heap manager. You can use whatever you want. 4) Messy stuff like the triple-bits and rgb-equal in XAA will not be supported except as a complete fallback to software at GC validation time. There is no per-primitive GC validation like there was in XAA because apps just don't work that way. They trash validation so much that it needs to be lightweight. Mark. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Vojkovich Sent: Monday, March 01, 2004 4:19 PM To: [EMAIL PROTECTED] Subject: XAA2 namespace? The current XAA has functions starting with XAA and header files starting with xaa. To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards Xaa for the functions and header files. Any concerns? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
