dale@boing.UUCP (Dale Luck) (12/19/90)
Newsgroups: comp.sys.amiga.tech Subject: Re: Retargetable graphics. Temporary Stop-gaps. Summary: Expires: References: <12437@life.ai.mit.edu> <16612@cbmvax.commodore.com> <7307@sugar.hackercorp.com> Sender: Reply-To: dale@boing.UUCP (Dale Luck) Followup-To: Distribution: Organization: Boing, Milpitas, Ca. Keywords: rtg,iff,24bit,video hardware In article <7307@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >The BitBlt routines will, of course, have to emulate the blitter. Since the >68020 has the horsepower to beat the blitter (according to Henry Spencer, who >is a pretty reliable source) that's not such a great hardship. The 68020 does not have the horsepower to beat the blitter given the 16 bit bus and the memory access technology. And even if they were the same, the 020 would need to be at least twice as fast as the blitter to get the same effective throughput on a 1 bitplane system. If you realize that many operations require both actual raster operations as well as non-raster operations, then the fact that the blitter runs in parallel to the cpu sometimes makes the operations instantaneous. (No time at all) The blitter is able to shift two sources, mask one of those sources,and then combine this with a third source do zero detection, all in a way to use 100% of the available memory bandwidth. At the same time it keeps track of 4 address registers, incrementing to the next memory locations and checking for end of line and rectangle conditions. Applying modules when necessary. Amd no empty memory cycles. A cycle to the blitter is 280nsec. To do the equivalent operation in the cpu would take several instructions. Two come anywhere near this would require a minimum of a 32 bit data bus as well as timing on the bus that matches the blitters own speed. > >At least any such RTG interface should provide the same basic interface as >graphics.library. Why even consider anything else? The basic graphics.library is a very complex interface that includes some very amiga specific concepts such as Sprites- Real and virtual, copper lists, blitter objects-(beam synced and normal), animation objects, multiple viewports, changing resolutions, colormaps all 'multitasking' the monitor. And finally an 8 bit per color allocation in the RastPort. We can sort of get around this be creating a pen lookup table, so that it actually uses another 32 bit location to fetch the actual pen number. But only 8 bytes were allocated for minterms. Minterms per bitplane do not always make sense in a chunky mode display. Things like these implementation details need to be hid a bit. > Dale Luck -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
glmwc@marlin.jcu.edu.au (Matt Crowd) (12/19/90)
In article <925@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >in a way to use 100% of the available memory bandwidth. At the same time it >keeps track of 4 address registers, incrementing to the next memory locations >and checking for end of line and rectangle conditions. Applying modules when >necessary. Amd no empty memory cycles. This is correct is it? My reading of the Amiga System Programmers Guide was that the blitter was assigned either odd/even (can't remember which) and that was all it could use. I was not impressed at the thought of empty memory cycles, so I am hopeful that the Abacus book is wrong again, or at least badly written. >Dale Luck >-- >Dale Luck GfxBase/Boing, Inc. >{uunet!cbmvax|pyramid}!amiga!boing!dale -- Matt Crowd Amiga Man Email Address glmwc@marlin.jcu.edu.au
renagade@galadriel.cm.deakin.oz.au (Mark Kuzmycz) (12/20/90)
>This is correct is it? My reading of the Amiga System Programmers >Guide was that the blitter was assigned either odd/even (can't >remember which) and that was all it could use. I was not impressed >at the thought of empty memory cycles, so I am hopeful that the >Abacus book is wrong again, or at least badly written. Actually Abacus states that the blitter can use both all memory cycles if the programmer so chooses but the blitter should use only the odd cycles to allow the processer to run at full speed when using chip ram or in A500 fast ram at c000. Mark.
peter@sugar.hackercorp.com (Peter da Silva) (12/20/90)
In article <925@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: > >At least any such RTG interface should provide the same basic interface as > >graphics.library. Why even consider anything else? > The basic graphics.library is a very complex interface that includes some > very amiga specific concepts such as Sprites- Real and virtual, copper lists, > blitter objects-(beam synced and normal), animation objects, > multiple viewports, changing resolutions, colormaps all 'multitasking' the > monitor. Ick. Yes, I see the problem. Well, at the very least the calls to the RTG should try to map closely to the calls in the graphics.library (maybe have an extended RastPort structure with extra colors and so on). I think the Sprites, copper lists, and so on can be left out. But the higher level routines should remain the same. You want to keep the door open to opening Intuition windows on a second head. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (12/21/90)
In article <925@boing.UUCP> dale@boing.UUCP (Dale Luck) writes:
The 68020 does not have the horsepower to beat the blitter given the 16 bit
bus and the memory access technology.
Hmm - there could be something in the Amiga to cause this to be true,
but it isn't for Suns.
A cycle to the blitter is 280nsec. To do the equivalent operation in the cpu
would take several instructions.
The blitter can make thing the blit happen as fast as memory can deal
with it. All it takes for the 68020 to do that is for all the
instructions to land in cache. If the Amiga gives the blitter twice
the memory bandwidth of the CPU, then the 68020 can't keep up on that
hardware - it can't push things through memory fast enough. This will
be different on the 3000, though.
<mike
--jimm@amiga.UUCP (Jim Mackraz) (12/21/90)
(Peter da Silva) writes: )(Dale Luck) writes: ) )> The basic graphics.library is a very complex interface that includes some )> very amiga specific concepts such as Sprites- Real and virtual, copper lists, )> blitter objects-(beam synced and normal), animation objects, )> multiple viewports, changing resolutions, colormaps all 'multitasking' the )> monitor. ) )Ick. Yes, I see the problem. Well, at the very least the calls to the RTG )should try to map closely to the calls in the graphics.library (maybe have )an extended RastPort structure with extra colors and so on). I think the )Sprites, copper lists, and so on can be left out. But the higher level )routines should remain the same. You want to keep the door open to opening )Intuition windows on a second head. Which "higher level" routines, OpenScreen(), with NewScreen>Modes set to weird values which programs change on the fly and call RethinkDisplay()? Clearly, it will be hard to pick "routines" or even "features" that you can retarget reliably. My suggestion is that this problem rather be addressed by thinking in terms of "levels of compatibility". Dale already proved with A2024 mode that many basic Amiga concepts can be eliminated (sprites, WaitTOF(), colors,...) and still retain excellent compatibility with the class of programs that run on the Workbench screen: "graphically vanilla" applications. Graphics has a rendering model, with simple things like SetAPen() and Move/Draw; harder things, like BltBitMapRastPort() and bitplane oriented raster images; plus a display engine, with RethinkDisplay(), screen-positions, colors--and this is the very engine you want to "retarget" away from; and some oddities like sprites and beam-sync blits. I believe that it is possible to port the simple "workbench class" applications someday, but that will indeed be quite a while (layers and Intuition have to be ported, first). But I don't think that this "emulation" will necessarily be the best way to write device-independent applications. For one thing, suppose the "retargeting" supports graphics of varying resolution. The "retargeted graphics library" knows how to scale things (poof, through magic). How do applications support clicking on graphics objects? The input model has to be emulated, and tranformed, as well. I think that well-established graphics standards have a more planned set of capabilities for inquiring graphics capabilities, defining and picking graphics segments, and managing colors. (Hopefully, better on-screen font support, and an integrated printing model, too.) Input notwithstanding, as a simple example consider displaying a 24-bit picture. It should be a simple and straightforward bit of procedural standardization, in order to make such display device-independent. But clearly, it could not be performed at all by a "retargeted graphics.library". All known Amiga graphics operations of image display count on bitplanes, the Amiga palette, maybe HAM, and specific (and often vile) information about the relatinoships among display mode, resolution, and depth. Just check your favorite slideshow with a picture saved in productivity interlace mode, to see. I feel that device-independent graphics for the Amiga for new applications is high-priority. Porting the Workbench (nee "retargetable graphics") is secondary. Considering that there are hardware tricks to get a new display controller to share a monitor with the Workbench, even to overlay Intuition windows on the controller's native modes, I suspect that these solutions will precede retargetable graphics. Even a standard for slide-show display would have great value now, and perhaps it can be stacked on top of the 24-bit ILBM standardization effort, or you can sign up the hardware vendors afresh. C= probably has to speak with a device-independent graphics standard, and I agree with Dale's earlier advice that it be some well-established standard, but I don't know which one I would pick if tasked. I know that C= has tossed TIGA around a lot (on the agenda (again?) for European DevCon). Interesting question: if every device had TIGA, could you use it to write the simple device-independent slideshow for 24-bit ILBM's? How about for anims? Maybe in addition to the established "true graphics" standard, some standard for amiga-specific constructs like "display 24-bit anim" be proposed in addition. Such a thing could be implemented as a per-graphics-card ilbm device maybe, or even as a protocol for commands to a rexx port, as far slideshows go. Very high level. I would also recommend not getting *too* ambitious, because the "native implementation" of any bitchen device-independent graphics will probably be pig slow on an A500; and since that's what C= tends to sell, most software will have to focus (first, at least) on native modes to have a market. Upscale-style graphics standards on the Amiga are probably a chicken-and-egg problem. I don't see the pitfalls of myriad graphics cards being the main reason we don't see workstation software for the Amiga. Autocad seems to get by with the device-specific application driver concept... jimm -- --- opinions expressed herein are my own. --- "... Because they can." - profound punchline to joke about dogs
dale@boing.UUCP (Dale Luck) (12/22/90)
In article (Mike (My Watch Has Windows) Meyer) writes: >In article <925@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >Hmm - there could be something in the Amiga to cause this to be true, >but it isn't for Suns. The only suns I know of with 16 bit buses are sun2's. The Amiga Blitter is certainly faster than that. In X11 for the Amiga I can show that the Amiga Blitter is just as fast as a 020@15mhz on a 32 bit bus by comparing speeds of operations of a sun3/50 versus a STANDARD A2000. > >The blitter can make thing the blit happen as fast as memory can deal >with it. All it takes for the 68020 to do that is for all the >instructions to land in cache. Are you implying that just because instructions land in the 020's cache that they no longer take time to execute? I believe all the cache does is act as a fast memory with access time of 2 clock cycles instead of 3 or more for outside memory. If the Amiga gives the blitter twice >the memory bandwidth of the CPU, then the 68020 can't keep up on that >hardware - it can't push things through memory fast enough. This will >be different on the 3000, though. I believe the 020 is still held to 4 clock cycles to chip memory. If the memory access is 32 bits however, and the address is on a 4 byte boundary then it can get 32 bits at once. So this does even it out the speed differential a bit. This also means that it may have less contention for the same chip memory as the blitter since the blitter would have to do two memory accesses for every one of the 020. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/22/90)
[In response to jimm's article] The standards out of ISO & ANSI X3X3 (GKS, GKS3D, PHIGS, PHIGS+,...) address the full range of issues you mention, specifically for instance the full range of multiple display devices, each having it's own private input devices, each with its own set of forward and inverse transformations for both input and output, each with its own resolution and color capabilities, etc. As the Amiga moves more and more into the high end graphics for which these standards were designed, less and less of the functionality in the standards would be unusable on the Amiga. The ones with which I am familiar also have a way of asking the display driver "can you do/can you emulate/must I do" questions, that would cover the cases of sprites/copper lists and so on that exist on one display but not another, as well as "standard escapes" for getting at hardware capabilities not a part of the standard. Rather than go with an "industry 'standard'", I'd guess Commodore would be well advised to have one of the real graphics heavies take a break from development, sit down for some number of months with these international standards, and try to identify parts that the Amiga would _not_ find useful. I suspect it would be a small list indeed. To the other question of pokey performance on the A500, it is long ago time for Commodore to stop selling a configuration so minimal that every attempt to do software improvements is blocked by hardware limitations. It is plain dumb in today's market to sell a machine with under 2Mbytes of memory, for example, when the A500's limited memory is harming not only Commodore but also 3rd party software development. Developers must design to the base model, since so many machines stay at that base "forever"; setting the base too low is the virtual equivalent of grinding one's heel into the back of the prone developer's neck; s/he finds it hard to work in that position. Putting this kind of a limitation on the software that can be written for the base machine eventually puts a limit on the market to which all your machines can aspire; limited software availability == limited hardware sales, and the first "limited" doesn't only mean "few in number" but also "lesser in capability". We've been running into this time and again in comp.sys.amiga.games in the last couple of weeks; some of the best development discussions alive go on the what was meant to be a noise group, though they sure are noisy enough! I hope someone from C= has been listening and passing on the lessons there. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
jap@convex.cl.msu.edu (Joe Porkka) (12/23/90)
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >[In response to jimm's article] >Rather than go with an "industry 'standard'", I'd guess Commodore would >be well advised to have one of the real graphics heavies take a break Good Idea >To the other question of pokey performance on the A500, it is long ago >time for Commodore to stop selling a configuration so minimal that every >attempt to do software improvements is blocked by hardware limitations. >It is plain dumb in today's market to sell a machine with under 2Mbytes >of memory, for example, when the A500's limited memory is harming not >only Commodore but also 3rd party software development. Well, no. It is a good thing to have a low end machine that can run much of the same software as the high end. Low end -> many more people can buy it, which in turn helps finance CBM. If your applicationmust have oodles of memory, a 68040, 100meg harddisk, etc, etc, etc, then you should say so in the advertisments. So instead of CBM excluding a bunch of people from the Amiga market in general (including all current owners of <A2000), individual software products would. For example, how many people of consider running WordPerfect 5.x on an original IBMPC? one without a diskdrive (hard or floppy - that thing will use a cassette tape you know). Well, since WP does not come on tape I guess you couldn't. Even outfitted with two floppies, WP would be unbearably slow. However, the newest 33Mhz 486 boxes are still IBMPC compatible.
peter@sugar.hackercorp.com (Peter da Silva) (12/24/90)
In article <MWM.90Dec20153932@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > In article <925@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: > The 68020 does not have the horsepower to beat the blitter given the 16 bit > bus and the memory access technology. > Hmm - there could be something in the Amiga to cause this to be true, > but it isn't for Suns. The Suns don't have a 16 bit bus, do they? They're pure-32bit machines... at least for all the Suns with 68020s or above in them. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (12/24/90)
In article <6301@amiga.UUCP> jimm@amiga.UUCP (Jim Mackraz) writes: > Which "higher level" routines, OpenScreen(), with NewScreen>Modes set > to weird values which programs change on the fly and call RethinkDisplay()? OpenScreen would open on an appropriate device. If you want to open a 24 bit screen, you would call OpenScreen with the appropriate bits set. Programs that call OpenScreen without that sort of magic would just get regular Amiga screens on the regular display device. To get a Workbench on the 24-bit screen you'd have to run a program that opened a second workbench screen with that magic set. I *hope* there are no programs that clobber the workbench screen modes. > I believe that it is possible to port the simple "workbench class" > applications someday, but that will indeed be quite a while (layers > and Intuition have to be ported, first). I think this should be made a *very* high priority. > For one thing, suppose the "retargeting" supports graphics of varying > resolution. The "retargeted graphics library" knows how to scale things > (poof, through magic). How do applications support clicking on graphics > objects? The input model has to be emulated, and tranformed, as well. Yep. I never said it'd be easy. I don't see how it could be so damn hard, though. As you say, the A2024 proves otherwise. It's been done once... > Input notwithstanding, as a simple example consider displaying a > 24-bit picture. It should be a simple and straightforward bit of > procedural standardization, in order to make such display > device-independent. > But clearly, it could not be performed at all by a "retargeted > graphics.library". No, you'd need a display program that knows about the new modes. But you should be able to open a workbench screen onto that display if you need to get extra room. > I feel that device-independent graphics for the Amiga for new applications > is high-priority. Porting the Workbench (nee "retargetable graphics") > is secondary. I don't see that these should be seen as different goals: the first must be a way-station to the second. > Upscale-style graphics standards on the Amiga are probably a > chicken-and-egg problem. I don't see the pitfalls of myriad > graphics cards being the main reason we don't see workstation > software for the Amiga. Autocad seems to get by with the > device-specific application driver concept... (choke) Yes, but AutoCad has a much larger market. The number of SVGA cards out there from a single vendor probably beats the total number of high-resolution cards for the Amiga for all vendors, *including* ECS Amigas in that total. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/24/90)
In article <6301@amiga.UUCP> jimm@amiga.UUCP (Jim Mackraz) writes: [...] >I believe that it is possible to port the simple "workbench class" >applications someday, but that will indeed be quite a while (layers >and Intuition have to be ported, first). >But I don't think that this "emulation" will necessarily be the best way >to write device-independent applications. >For one thing, suppose the "retargeting" supports graphics of varying >resolution. The "retargeted graphics library" knows how to scale things >(poof, through magic). How do applications support clicking on graphics >objects? The input model has to be emulated, and tranformed, as well. I know this isn't answering the question you asked, but it is a little goodie that might prove of use. In a SIGGRAPH tutorial he taught some years ago, Alvy Ray Smith described the original paintpot graphics program, which he had developed (at New York Institute of Technology, I think). Back in the days before swappable screens or very fast graphics, they'd solved the problem of having a full screen drawing surface by running a two headed system with the command menus on one, monochrome screen, while the picture was on the other, color screen. (Actually, this is enough like the system being proposed here to deserve a lot closer look, if anyone has the source material.) Anyway, the problem of swapping the cursor's "attention" from the control screen to the drawing screen needed solving. They chose a double width digitizing tablet (pre "mouse" days; they had "pucks"), and used a gestural language; if you went "significantly" left off the edge of the control screen with the cursor, your cursor showed up on the graphics screen. If you went significantly right off the edge of the graphics screen, your cursor showed up on the control screen. Behind the scenes, of course, a new input "inverse" transform was shifted into place going to the control screen or the graphics screen, since there is no given that the two screens had the same resolution, but the mouse motions should feel the same on each. Also, the "pick" list for the control screen menu items had to be disabled for the same locations on the graphics screen. For the Amiga, the mouse works well as a replacement for the double wide digitizing tablet, and, in the case where the 24 bit screen contains object, rather than pixel, -oriented entities, a new "pick" list (and possibly a whole new routine: menus and dimension arrows don't "pick" the same way) could be swapped in while on the high res screen, to solve the "clicking on an item" problem. It's an approach that worked in the past. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
peter@sugar.hackercorp.com (Peter da Silva) (12/25/90)
In article <1990Dec24.090341.2297@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > if you went "significantly" left off the edge > of the control screen with the cursor, your cursor showed up on the graphics > screen. If you went significantly right off the edge of the graphics screen, > your cursor showed up on the control screen. That sounds very similar to what double-headed Macs do: they just treat the total are of both screens as a single "Gray Area". I don't know how they handle resolution changes. That's the sort of model I'd like to see on the Amiga. For scaling, you'd have to have a preferences-set mouse speed for each screen. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
daveh@cbmvax.commodore.com (Dave Haynie) (01/03/91)
In article <927@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >In article (Mike (My Watch Has Windows) Meyer) writes: >>The blitter can make thing the blit happen as fast as memory can deal >>with it. All it takes for the 68020 to do that is for all the >>instructions to land in cache. >Are you implying that just because instructions land in the 020's cache >that they no longer take time to execute? I believe all the cache does >is act as a fast memory with access time of 2 clock cycles instead of 3 or >more for outside memory. Let's not confuse 68020 and 68030. With the '020, cache hits are certainly going to be noticed -- data and instruction fetches happen on the same internal bus. On the '030, the I and D buses are only in common on the memory side of each internal cache, so if all the instructions come from cache, you do get an overlap of cycles that does hide most of the I cache fetches. I don't think this is quite as effective as what you get on some of the more advanced Harvard machines like the 68040, but it's definitely there. >I believe the 020 is still held to 4 clock cycles to chip memory. On the 3000, the '030 access to Chip RAM is the same speed, four 7.16MHz clocks, minimum. >If the memory access is 32 bits however, and the address is on a 4 byte >boundary then it can get 32 bits at once. So this does even it out the speed >differential a bit. Sure, you can probably do some things faster. But anything that can be done as or nearly as well by the blitter should still be done by the blitter, at least assuming there's something useful out of Chip RAM for the '030 to do at the same time. >Dale Luck GfxBase/Boing, Inc. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley