Thanks Andre (or andres? O:-). I often make this mistake, confusing polish and polished. :-/

You still need additional hardware in order to support them. And o.s. support too.

There's no point in making a 32-bit display mode (although a 4 byte-plane Blitter mode will exist for per-pixel alpha-blending) since it would take more bandwidth but yield no more color depth.  There's also no point in making a 2 byte-plane mode since the Blitter might need additional hardware to deal with that situation.

If the Blitter supports 32 bits chunky, it's still far away from the traditional bitplanes. So you need additional hardware again.

The point is that we'll likely be able to reuse some of the register mapping with byte-planes that were used with bit-planes.

You can do the same with chunky modes. You still do it for 8 bits chunky and for the 3 byteplane modes, which are quite different from the usual bitplanes.

The future will not need to hold much more of the PC-style chunky modes since they waste bandwidth and chip resources simply because they can, and they are slightly easier to use.

I don't agree. Bitplanes/byteplanes wast space and bandwidth too, especially using DDR-2 memory were, once started, a burst must be completed.

With bitplanes you raise the granularity to 128 bits / pixels, which is A LOT.
With byteplanes it's better, but it is still 16 pixels (x3 in terms of bandwidth and space).

16 and 32 (and 24 too) bits chunky modes are much more compact and have a better granularity (8, 4 and 5 respectively).

So, at same depth, a chunky mode is always and absolutely preferable in terms of space and bandwidth.

Another thing which is related is latency. Since bitplanes and byteplanes require to load all data before start using them, the output requires greater latency compared to chunky modes, where a single load carries already usable data.

But we already discussed about these things.

With careful planning, the existing design will scale up to better FPGAs with minimal modification.  The design is meant to be optimal without having to be extensible at all.  This will make design costs lower over time.   Now do you see what we are trying to do?

I think that you are making again the same mistakes.

Anyway, that's my opinion. ;)

Actually I do not see Bitplanes as negative as you.
First of all, supporting Bitplanes in the chipset is no problem at all.
The Blitter logic is small, and takes little chip space.
If you want to enhance your chipset to e.g support Byteplanes, or Pixels of XXX Bytes then you can do this without any need to remove the Bitplane logic.

Lets say for example your Bitplane Blitter needs 1000 LE.
What is this compared to a 55,000 LE FPGA?
And what is this compared to a 1,000,000 LE ASIC?

Is there a need to remove the Bitplane support from future chipsets?
No its really not!

Regarding the need of several Blitts.
If you want this need could also quite easily be removed.

The AMIGA did always support interleaved Bitplanes.
With interleaved Bitplanes you can do as many Planes as you want using a single Blit.

With a tiny little enhancement to the AMIGA Blitter you could also do such a Blit using a single Plane mask.
Another possible improvement would be to add a FIFO to the Blitter allowing it to accept several jobs in a row. This is also not difficult and would free the CPU from waiting between Blits.

Cheers
Gunnar

Lets go into detail here. Its always better to discuss these things using real technical numbers.

Maybe you can give us an example of how much latency this is in your opinion.

Please explain us why 3 Byteplane have more latency than for example a 32bit Chunky mode - and how much more.

Cheers

With a 24 bits chunky mode it starts to output the pixels just after the first burst.

With a 3 byteplane mode it needs to fetch all 3 128 bits data, combine them (suppose that it take zero cycles), and it starts to output the pixels after the third burst.

So the 3 byteplane has at least tripled the latency compared to the 24 bits chunky.

The same happens with the Blitter and the CPU: once completed a burst, with chunky modes you already have usable data.

Another thing that I forgot before is the fact that 16, 24 and 32 bits chunky modes stay in contiguous memory blocks, so fetching a row doesn't require to send commands to the memory controller to start a burst into another memory address, whereas bitplanes and byteplanes need to do this.

I'm not a memory interface expert, but may be this can require additional cycles, so increasing latency and wasting bandwidth too.

Remember that the byteplanes are a display mode.  The Amiga chipset required the screen and sprites to all be a multiple of 16 pixels across anyway.

If you're referring to the Blitter's latency, it simply takes 3 passes at the same data chunk with the job queue overhead built into the new hardware whether through the Bopper or through job queue registers on the Blitter itself.

Today all DRAM memory has many waitstates.
And this is by desing this way.
Therefore from the time when you start your burst request
until the time when the data from the memory will arrive, there will be many cycles past.

Our NATAMI has a very low latency (compared to a PC) but nevertheless about 26 cycles will have passed until the data will arrive.

By design the memory controller will use this time and send out continously new bursts request. This means the DMA engine will shoot out a full rain of DMA request, long before the first data words will arrive back.

Cesare Di Mauro wrote:

I'm not a memory interface expert, but may be this can require additional cycles, so increasing latency and wasting bandwidth too.

Todays memory works differently.
You have pages and banks and memory chips can hold several banks open in parallel without a drawback.

You can savely trust those which are memory experts - there are no problems with using Byteplanes.

@Gunnar

Even though you can have multiple pages open, but there are only so many you can have open.  And the more you have open for the display, the less you can have open for other things.

Now based on your post, I assume you know a way to instead use those reserved gaps, not for banks switching activities, but instead you know a way to further increase the troughput for pure sequential access?

Is this what you wanted to propose?

Without offending anyone.
DDR memory controllers and their implementations in FPGA's is a very interesting topic but unless you know something about this topic, any advice how to improve the NATAMI memory design, might not be as helpful as you think.

I think its more fruitful to discuss about topics where people have more background knowledge.
 

Yes, Paula has a state machine.
Now which feature do you talk about?
What is your question exactly.
IS there something you would w=change or not change and why?

Now, how does what you said relate to 3x8 being better than chunky?  Really?  Simplify it and make it relevant.

You can line up the requests for chunky to keep the flow going nicely too.  The nice thing about display logic, for the most part, is you can plan way ahead.  With chunky, you only have one stream to deal with.  Planar, you have to deal with multiples.

And besides, you do not want to saturate the bus with only display.  Then you'd have nothing else. 

I think many other will disagree with your opinion.
I think we all have the same opinion about 16bit chunky.
So this is easy.

32bit chunky does increase bandwidth requirements by 33%.
Which means it slows your system down by 33%.

24bit chunky does not exits as mode.
24bit can NEVER be chunky because neither a Blitter nor a CPU can write 24bit properly in a single access.

What you call 24bit chunky needs 3 bytes each 1 Byte the same way as the 3xByteplane mode will need it.

Both modes have the same optimal bandwidth requirement.
Both modes have different advantages.
- Your proposal is clearly more difficult to address.
+ Your is sequential so while it needs 3 byte accesses to write they have a good chance to fall in 1 or 2 cachelines. While the Hybrid mode will always fall in 3 lines. For bobs this make no real difference but for drawing vertical lines this might be a little advantage.
- The Hybrid mode has the advantage that you can have the different planes easily in different resolutions. This allows optimal display of video modes which use color planes in lower resolutions.
- The Hybrid mode has the advantage that you can easily update the planes one by one. This is ideal if you work with images which come with individually compressed byte planes. This makes decompressing those images or decompression video streams work optimal in this mode. Here the layout of the Hybrid mode is optimal lcoally for the CPU cache.

In short both modes have pluses and minuses.
I can see a lot of nice features of the Hybrid mode which make it quite useful in many ways.

There is nothing wrong with not beeing an expert in a certain area.
But it starts to get funny if a lot of "advice" is given
or comments are posted like facts like "chunky is simpler".

The story would look totally different if people would ask, instead giving advice about topic which they lack deep expert knowledge.
   
 

One Thousand wrote:

With chunky, you only have one stream to deal with.     Planar, you have to deal with multiples.

 
Well, lets look at this in detail, maybe the result will surprise some people here.
 
To display a good resolution you need to shoot out a bunch of requests. If you do not do this you will not have enough video bandwith.
 
For the sake of argument lets compare 3x8 with 1x32 mode.
Lets say for your desired resolution you need 6 request in flight for 24bit. This means for each of the 3 byteplanes you need to have 2 requests in flight in parallel.
 
Your 32bit screen has a 33% higher DMA requirement,
which means for the same resolution this 1 plane
needs to have not 6 but 8 memory bursts in flight in parallel.
 
Does your 32bit screen look simpler?
Only if you do not care how a memory interface works.
Because in reality this one plane needs 33% more requests in flight than the 3 plane mode.
 
 
The math is very simple.
The 32bit chunky mode is wasting bandwidht.
The 32bit chunky mode needs 33% more buffers and 33% more requests in flight cmopared to the Hybrid mode.
 
The 32bit mode is clearly simpler for the CPU if you really want to draw each and every pixel one by one with the CPU.
This goes without saying.
If course the CPU is to slow to do any fullscreen single pixel drawing anyway - so you would not go far with this at least not if you want to do something in good resolution in real time....
 
If you do not care about real time then having to write 3 bytes for the the Hybrid mode should normally not be a drawback.
And the Hybrid mode has some clear advantages in certain video modes.
 
The 32bit mode makes sense as display mode - just for backward compatibilty reasons.
 

What I meant by "multiple streams" was "multiple distinct streams" because of the jumping around that is inherent in planar.  My bad for not clarifying that well enough.  But . . .

That was nice of you to use 32bit chunky.  However, you ought to remember that I am more for a nice 16bit chunky.

So in other words, go with a nice 16bit chunky screen with brightness/color separated colorspace, right?  It has less DMA requirement, less memory space, and it is one nice stream without jumping around as well as a more efficient use of bits.  :)

---

By the way, I do not think people are saying drop the 3x8 mode, which you are for.  What they are saying is they want the chunky modes.  Why not have both?  You may want one mode for one reason, or another mode for another reason.  Just recently you gave a big spill about how well FPGAs are growing and that we have space.

Thomas Richter would could propoably say its bad that people exposed the information about those mode and about framebuffer layout before ... therefore we now have to support them..
 

But the interesting part of supporting in my opinion comes when you support them not only for display but also with all HW acceleration as rendering targets.
And here begins the part where you want to discuss if you need or want this.

I wonder if providing full HW acceleration or 3D acceleration for all those different modes makes the best sense.
 
For future games 16bit looks more and more limited (not to say it starts to sucks)
So the first question is: Does it make sense to support this mode with the 3D core at all?

If the overhead of rendering the pixels not so high that the saving some bits in display memory becomes a bad tradeoff?
 
I agree with Sam here that we should not spread ourselves too thin.

If we advertise one of the new mode as "recommended mode" and provide for this one  "strong HW acceleration" then this makes probably more sense than to provide 5 modes with only halve working acceleration for each of them.
 
But maybe I'm to cautious here?

--

Another thought about Tami, if she was the tile-based, deferred renderer we last talked about, the tile is in full color res all the time.  Could there not be a separate writing unit that is smart enough to dump out and rearrange according to the desired screenmode?

--

Curious:  Why can there not be a packed 24bit chunky mode?  Wouldn't you only need a little padding at end of the screen or maybe line, instead of the alpha padding on every 32bits?  Just find a nice LCM to match up?  Perhaps I am missing something.