fry@brauer.harvard.edu (DSF2) (03/26/90)
Reading through Apple Direct, I was thrilled to see that some level of multiprocessing is afforded by the new 8/24 GC accelerated graphics card. If a program calls a QuickDraw routine, the GC's AMD 29000 is given responsibility for executing it. The 29000 tells the CPU that the routine has already finished (which is a lie) and the CPU goes on to the next instructions while the 29000 performs the QD routine. Should the CPU encounter another QD instruction before the 29000 finishes, it will wait for the 29000. My worry is what level of compatibility is required from a program to make this work. Certainly Apple has always warned us that we should user their routines to do QuickDraw, but for some applications this is just too slow. What happens if you try to do this with the GC installed? For instance, suppose a program calls EraseRect (substitute your favorite QD trap here) in an offscreen PixMap and then tries to access a pixel directly as an offset from the baseAddr immediately afterwards. We assume the 29000 hasn't yet finished, so the PixMap won't be in the state the program expects it to be. Or, more likely, a program will try to set the value of a pixel. Is there some handshaking going on that will prevent a program from doing this? I imagine that would be very simple if the PixMap were on the GC's onboard DRAM, but what if the PixMap is in the main memory? If this really is a problem, is there a way for a program to know a GC is installed? At least then it could assume the board is fast enough that it's not necessary to go behind QuickDraw's back. David Fry fry@huma1.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
paul@taniwha.UUCP (Paul Campbell) (03/27/90)
In article <2344@husc6.harvard.edu> fry@brauer.harvard.edu (DSF2) writes: >For instance, suppose a program calls EraseRect (substitute >your favorite QD trap here) in an offscreen PixMap and then tries to >access a pixel directly as an offset from the baseAddr immediately >afterwards. We assume the 29000 hasn't yet finished, so the >PixMap won't be in the state the program expects it to be. >Or, more likely, a program will try to set the value of a >pixel. > >Is there some handshaking going on that will prevent a program >from doing this? I imagine that would be very simple if the >PixMap were on the GC's onboard DRAM, but what if the PixMap >is in the main memory? The answer is that there is nothing to prevent an application from doing this - if they break the rules. Rules? you ask, what rules? Apple was very smart, they announced how to do this a year ago when they released the 32-bit QD documentation - but didn't draw atttention to it. The description for the "GetPixBaseAddr" routine sais: "GetPixBaseAddr waits until all drawing to the PixMap is completed and returns a 32-bit pointer to the beginning of its pixels ..." As an accelerator designer (you can see why I was reading between the lines back then) I would like to stress that this is VERY important. One of the best ways to get more QD performance out of the system is to overlap QD operations with application processing (otherwise perceived QD acceleration is ultimately limited to how fast applications can run) - ideally an app should be able to keep an accelerator stoked to the point that it never has to wait for display. Paul Campbell SuperMac -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P Remember 1990? that was the year the US government funded a Communist election victory in Nicaragua and claimed it a victory for Capitalism.
kent@sunfs3.camex.uucp (Kent Borg) (03/28/90)
In article <2344@husc6.harvard.edu> fry@brauer.harvard.edu (DSF2) writes: > >Reading through Apple Direct, I was thrilled to see that some >level of multiprocessing is afforded by the new 8/24 GC accelerated >graphics card. If a program calls a QuickDraw routine, >the GC's AMD 29000 is given responsibility for executing it. >The 29000 tells the CPU that the routine has already finished >(which is a lie) and the CPU goes on to the next instructions >while the 29000 performs the QD routine. Should the >CPU encounter another QD instruction before the 29000 finishes, >it will wait for the 29000. > >My worry is what level of compatibility is required from a >program to make this work. Certainly Apple has always warned >us that we should user their routines to do QuickDraw, but >for some applications this is just too slow. What happens if >you try to do this with the GC installed? Apple has thought of that--at least for new code. Get the notes on 32-Bit QuickDraw. They now have explicit support for off-screen graphics. One of the calls says: "GetPixBaseAddr waits until all drawing to the PixMap is completed..." What about compatibility with old code? I suspect that the 29000 only operates on the GC card memory. Any QuickDraw outside of it will be old fashioned. From the spec sheet: Optional Macintosh Display Card DRAM Expansion Kit: Lets users add on-board dynamic RAM (DRAM) to boost the performance of applications that use off-screen bitmaps and other graphics techniques. I think it is a good idea to start using these new gworlds. The other calls are: NewGWorld, LockPixels, UnlockPixels, AllowPurgePixels, NoPurgePixels, GetPixelsState, SetPixelsState, GetGWorldDevice, UpdateGWorld, DisposeGWorld, and SetGWorld. Slight catch: Folks with II's, IIx's, IIcx's, and hacked SE/30's might run the 8-24 GC card without 32-Bit QuickDraw. Off-screen graphic worlds might not be there. These would seem like strange people who buy a fancy video card but don't use the matching fancy software, but we still don't want to crash on them. -- Kent Borg lloyd!kent@husc6.harvard.edu or ...!husc6!lloyd!kent MacNet: kentborg H:(617) 776-6899 W:(617)426-3577 "So simple minded. Kindergarten level with no content, but it's beautifully landscaped, and the architecture is interesting." -my mother on Epcot Center