mulu.l cycles on 68030 and 68040

[Thomas Richter]

Originally Posted by Bruce Abbott

I'm a 'bit' confused by this. So when blitting from the graphics card it automatically converts from chunky to planar?

If the source bitmap is chunky, and you call BltBitMap() to a planar destination bitmap, then that is transparently converted, of course. Also vice versa, blitting a planar bitmap into a chunky bitmap performs a conversion from planar to chunky (otherwise, not even icon dragging would work). BltBitMap() says that it blits a bitmap. The function does not state limitations on the type of the bitmap.

Originally Posted by Bruce Abbott

ECS means a maximum of 6 bitplanes can be displayed. How does that work when the source is 8 bit chunky?

No, ECS has a limitation of 6 *displayable* bitplanes, that is not the same. Not every bitmap is supposed to be loaded to the graphics hardware for displaying. I have no problem of allocating an 8-bitplane bitmap on ECS, and blitting to or from it (e.g. as a temporary for processing), and the Os is neither limited by the number of bitplanes - except that the struct Bitmap can hold at most 8 of them. But in general, if you blit an n-bit bitplane into an m-bit bitplane, min(n,m) bitplanes are blitted.

Originally Posted by Bruce Abbott

How do you know that it isn't 'sufficient to saturate the bandwidth of the bus'?

By comparing it to the theoretical bandwidth of the chip ram bus and by measuring against a dummy algorithm that writes long words to chip ram.

[Thomas Richter]

Originally Posted by meynaf

Sorry, i still can't find a single concrete (not theoretical) case where this is sane approach.

P96 migrates bitplanes to graphics RAM if possible. Consider a case where a user created a bitmap in video mode A and wants to blit the result to a window in video mode B. There is absolutely nothing wrong with that.

Originally Posted by meynaf

The video ram should have its start and end longword aligned. It can't be anywhere. Just clip correctly and perform aligned reads.

Because long word alignment does not fix the problem. A long word is 4 chunky pixels. But to convert with 32 chunky pixels at a time to write one planar long word at a time, you need to pull in 32 bytes at a time, so 8 longwords, and thus you need 8-longword alignment. Despite, WriteChunkyPixel8() from graphics goes through the same function - it essentially creates a transient bitmap with the source as the array - and its specification says nothing about "aligment" or "restrictions". It would be a violation of the interface.


Looks like we are back again to the "specification vs. code" discussion. The specification does not grant you alignment guarantees, nor that you can access "out of bounds" of the source. Thus, the code cannot perform them.

[meynaf]

Originally Posted by Thomas Richter

P96 migrates bitplanes to graphics RAM if possible. Consider a case where a user created a bitmap in video mode A and wants to blit the result to a window in video mode B. There is absolutely nothing wrong with that.

Different number of colors and/or different palette, leading to completely bogus image. Is that 'nothing wrong' ?

Originally Posted by Thomas Richter

Because long word alignment does not fix the problem. A long word is 4 chunky pixels. But to convert with 32 chunky pixels at a time to write one planar long word at a time, you need to pull in 32 bytes at a time, so 8 longwords, and thus you need 8-longword alignment. Despite, WriteChunkyPixel8() from graphics goes through the same function - it essentially creates a transient bitmap with the source as the array - and its specification says nothing about "aligment" or "restrictions". It would be a violation of the interface.


Looks like we are back again to the "specification vs. code" discussion. The specification does not grant you alignment guarantees, nor that you can access "out of bounds" of the source. Thus, the code cannot perform them.

You can still be a little pragmatic and check if there exists any case where that matters in real life. Making complex, unwieldy code just to respect some incomplete spec isn't the best decision.

[AestheticDebris]

Originally Posted by meynaf

Different number of colors and/or different palette, leading to completely bogus image. Is that 'nothing wrong' ?

You need to look at the problem while wearing OS-coloured spectacles.

It's a library function for copying images. So that is what it does. It's up to the programmer who is using it to decide whether losing a bunch of colour depth information is what they wanted or not, the OS function is just there to do what is asked of it.

[Thomas Richter]

Originally Posted by meynaf

You can still be a little pragmatic and check if there exists any case where that matters in real life. Making complex, unwieldy code just to respect some incomplete spec isn't the best decision.

The specs are not incomplete. Implementing something that expects more than what the specs demand is just an interface violation - quite simple. Just because it makes some algorithms "inconvenient" does not justify to make the life of the caller "more inconvenient" because the function could have some unforeseen "sideffects" if it makes out of bounds accesses.

[meynaf]

Originally Posted by AestheticDebris

You need to look at the problem while wearing OS-coloured spectacles.

It's a library function for copying images. So that is what it does. It's up to the programmer who is using it to decide whether losing a bunch of colour depth information is what they wanted or not, the OS function is just there to do what is asked of it.

That still looks weird. What happens if there is true color at one side and not at the other ?

Originally Posted by Thomas Richter

The specs are not incomplete. Implementing something that expects more than what the specs demand is just an interface violation - quite simple. Just because it makes some algorithms "inconvenient" does not justify to make the life of the caller "more inconvenient" because the function could have some unforeseen "sideffects" if it makes out of bounds accesses.

By the time the documentation was made, there was nothing such as chunky pixels to handle. And nonexisting side effects need not be avoided.

[Thomas Richter]

Originally Posted by meynaf

That still looks weird. What happens if there is true color at one side and not at the other ?

It uses a color-lookup or inverse color-lookup. Thus, blitting indexed to direct color causes a lookup into the color map (which still exists in the true color view port) and substitutes each index into the color that is loaded in the color map of the true-color screen. Blitting from true color to chunky causes an inverse color lookup, finding a color value in the palette that fits to the screen color, and using that as an index. There, of course, the chance exist that no such color exists. Without that logic, even some workbench programs would not work on true color screens, for example the locale prefs would not.

Originally Posted by meynaf

By the time the documentation was made, there was nothing such as chunky pixels to handle. And nonexisting side effects need not be avoided.

But memory limits existed, and there is no alignment constraint for planar bitmaps either. For AGA, there are some constraints, but that's why AllocBitMap() has the BMF_DISPLAYABLE flag, namely to ensure that the bitmap is suitably aligned to be loaded into the hardware. However, there is no documented requirement in the blitter functions (unlike the viewport functions) that such a constraint needs to be satisfied.

[meynaf]

Originally Posted by Thomas Richter

It uses a color-lookup or inverse color-lookup. Thus, blitting indexed to direct color causes a lookup into the color map (which still exists in the true color view port) and substitutes each index into the color that is loaded in the color map of the true-color screen. Blitting from true color to chunky causes an inverse color lookup, finding a color value in the palette that fits to the screen color, and using that as an index. There, of course, the chance exist that no such color exists. Without that logic, even some workbench programs would not work on true color screens, for example the locale prefs would not.

But this wasn't specified in the specs to start with...

Originally Posted by Thomas Richter

But memory limits existed, and there is no alignment constraint for planar bitmaps either. For AGA, there are some constraints, but that's why AllocBitMap() has the BMF_DISPLAYABLE flag, namely to ensure that the bitmap is suitably aligned to be loaded into the hardware. However, there is no documented requirement in the blitter functions (unlike the viewport functions) that such a constraint needs to be satisfied.

Going over an allocated memory area isn't the same as going over a whole memory range. I mean, software can locate its bitmaps where it wants, but the hardware has its own requirements. If no hardware exists with a real risk of misbehavior in case of slightly outside memory accesses, it's pointless.

[AestheticDebris]

Originally Posted by meynaf

But this wasn't specified in the specs to start with...

Yeah, but that's the classic problem with OS design. An API was specified with certain current hardware limitations in mind (such as a palettized display). Later true colour hardware comes along and just works in a fundamentally different way.

But applications have been written to the old API with it's old assumptions, so support for new hardware has to do the best it can. The specifications might not say it needs to handle the situation in a specific way, but implicitly it does for existing software to still function as you'd expect.

[Thomas Richter]

Originally Posted by meynaf

But this wasn't specified in the specs to start with...

So what do you suggest? Let old applications crash or render nothing on high-color screens? Or let applications crash because they don't satisfy new alignment constraints we're making up 30 years later because it simplifies one algorithm? We don't have the luxury in Amiga Land to request new revisions from software authors, or hardware vendors, just because it is "more convenient" in some place of the Os or the graphics stack.

Originally Posted by meynaf

Going over an allocated memory area isn't the same as going over a whole memory range. I mean, software can locate its bitmaps where it wants, but the hardware has its own requirements. If no hardware exists with a real risk of misbehavior in case of slightly outside memory accesses, it's pointless.

How do I know that no such hardware exists? It is not so unusual that for some designs the hardware registers sit directly close to the video RAM. The CyberVision3D is such an example. The principle is very simple: Touch only the bytes that were given to you.

[meynaf]

Originally Posted by Thomas Richter

So what do you suggest? Let old applications crash or render nothing on high-color screens? Or let applications crash because they don't satisfy new alignment constraints we're making up 30 years later because it simplifies one algorithm? We don't have the luxury in Amiga Land to request new revisions from software authors, or hardware vendors, just because it is "more convenient" in some place of the Os or the graphics stack.

I didn't suggest anything. Especially not changing bitmap alignment in memory. Just use the video memory's own alignment properties.

Originally Posted by Thomas Richter

How do I know that no such hardware exists? It is not so unusual that for some designs the hardware registers sit directly close to the video RAM. The CyberVision3D is such an example. The principle is very simple: Touch only the bytes that were given to you.

They sit next to an area that's round in size. A property you could use.
Many hardware registers just don't care about being read, either.

[Bruce Abbott]

Originally Posted by Thomas Richter

If the source bitmap is chunky, and you call BltBitMap() to a planar destination bitmap, then that is transparently converted, of course. Also vice versa, blitting a planar bitmap into a chunky bitmap performs a conversion from planar to chunky

Ah yes, I get it now. The bitmap will be chunky in graphics card memory, planar otherwise. But as far as the system or application is concerned it's always planar, and it will put the bitplanes in ChipRAM because it expects to use the blitter.

By comparing it to the theoretical bandwidth of the chip ram bus and by measuring against a dummy algorithm that writes long words to chip ram.

The bandwidth will depend on the screen mode in use. I guess when the graphics card image is being displayed the Amiga's bitplane DMA is turned off?

I'm curious know how much difference it made. What machine did you test it on, and what results did you get for your blitbitmap code vs writing longwords?