| Mixed Planar/chunky Mode, How Does It Work? | page 1 2 3
|
|---|
|
|---|
Thomas Richter
Germany
| |
Posts 695
12 Mar 2010 18:42
| Topic says it - I've seen this in the FAQ, question is now
how this graphics mode organizes the data.Thanks,
Thomas
| |
Chris S
United Kingdom
| |
Posts 13
12 Mar 2010 18:56
| At a guess probably three planes of 8-bit chunky data, one each for R,G,B.
| |
Gunnar von Boehn
Germany
| | (Natami Team Member)
Posts 3727
13 Mar 2010 05:48
| Chris S wrote:
|
At a guess probably three planes of 8-bit chunky data, one each for R,G,B.
|
This is correct
| |
Thomas Richter
Germany
| |
Posts 695
13 Mar 2010 11:20
| Gunnar von Boehn wrote:
|
Chris S wrote:
|
At a guess probably three planes of 8-bit chunky data, one each for R,G,B.
|
This is correct
|
Thus, three color lookup tables, one for red, one for green, one for blue, indexed by three planes, right?How's the YUV mode working, specifically how do you mix Y, U and V into RGB? There are several ways for that (Rec. 601, Rec. 709,...). How does that combine with HAM? (The latter would be pretty interesting, and - funny enough - coincides with Miner's original plans for HAM.). Thanks,
Thomas
| |
One Thousand
USA
| | (Natami Team Member)
Posts 716
13 Mar 2010 14:53
| No, no LUTs. It is just regular 24bit RGB but arranged differently: 3 planes of bytes, one plane for each channel.
I am also interested in the YUV mode(s), but I do not know much about those plans either. But we were also wanting that or similar for textures in the hardware. I am a fan of separating brightness from color. Thomas H or Gunnar, please tell. :)
| |
Thomas Hirsch
Germany
| | (Natami Team Member)
Posts 233
13 Mar 2010 17:30
| Thomas R.,
we did not fully test the new modes till now. We'll tell you when we are about to do this.The 24bit planar mode is ment how 1k said. There are 8bit each channel and no LUT. Disadvantage in this mode is that all (blitter) operations need to be started three times. But the major advantage is that this mode doesn't waste the extra 8bit like a 32bit PC graphic mode. I can tell more when the eval board is running stable enough to conduct more experiments. AFAIK Miner's original plans for HAM were to set a luminance value and alter the hue/chrominance in the following pixels. But I might be mistaken. If you want you can explain me some more details... I think we are going to have some discussions about the pixel/data/color format later on ... and I would highly appreciate your input.
| |
Gabriele Budelacci
Italy
| |
Posts 92
13 Mar 2010 22:27
| Thomas Hirsch wrote:
|
There are 8bit each channel and no LUT. Disadvantage in this mode is that all (blitter) operations need to be started three times. But the major advantage is that this mode doesn't waste the extra 8bit like a 32bit PC graphic mode.
|
Interesting! For years Amiga users are limited by planar graphics (bitplanes) and now... again limited by another type of planar graphic system (byteplanes?).
In 1980 planar mode has sense, because RAM costs! Today, RAM price is more more lower, so I think it's possible to 'discard' extra 8bit, but with advantages for coding performance.
My hope is you provide a full chunky mode too, else another type of 'chunky2planar' routines are needed!
NB: I think is needed to update info presents in 'Concept' page: Supported Pixelformats: Planar 1-8 Planes, HAM 6/8, 8bit Chunky, 16bit Hicolor, 32bit Truecolor.
-- 24 bit is not mentioned --
Regards
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 2089
13 Mar 2010 23:29
| wait a sec the DDR RAM does burst wouldn't it make more sense to have compacted data?
Since we would effectively take 3*8bits yet if we use those other 8 for something else?
24bit out 32 leaves 8 this could be well a part of the next colour or transparency for all i care.(yes, this could mean 4 colours reading 96bit)well i need some sleep right now, had a long day.
| |
Thomas Hirsch
Germany
| | (Natami Team Member)
Posts 233
13 Mar 2010 23:50
| @Gabriele
The word "planar" is not a synonym for "bad thing". It is just a name which describes its functionality. If you judge things by its cool name it might not be good to do this here.The colors in this mode are already 'chunky' - so you can write chunky2chunky routines. But it's nonsense. This mode provides the best performance for 24bit is the easiest way to code - so we give it a try.
| |
Thomas Hirsch
Germany
| | (Natami Team Member)
Posts 233
13 Mar 2010 23:55
| @Marcel
Fetching every color by its own channel is the compactest form in regard of burst. So every color can burst by its own and no "sorting" logic is needed. But this does not mean that this is the only new pixel format we want to add. But we need a point to start.
| |
Chris S
United Kingdom
| |
Posts 13
14 Mar 2010 03:02
| Have you put much thought into what demo coders could do with these new modes? Also a three plane YUV mode may be interesting/useful to have, with optional scaling on the chroma component. Should be good for video maybe?
| |
Thomas Richter
Germany
| |
Posts 695
14 Mar 2010 06:26
| Thomas Hirsch wrote:
|
Thomas R.,
we did not fully test the new modes till now. We'll tell you when we are about to do this.
The 24bit planar mode is ment how 1k said. There are 8bit each channel and no LUT. Disadvantage in this mode is that all (blitter) operations need to be started three times. But the major advantage is that this mode doesn't waste the extra 8bit like a 32bit PC graphic mode.
I can tell more when the eval board is running stable enough to conduct more experiments.
AFAIK Miner's original plans for HAM were to set a luminance value and alter the hue/chrominance in the following pixels. But I might be mistaken. If you want you can explain me some more details...
I think we are going to have some discussions about the pixel/data/color format later on ... and I would highly appreciate your input.
|
Hi Thomas,well, I would mostly opt for "keep it simple". Unless you're really short of bandwidth, I'm not sure the truecolor planar mode is worth it. YUV, specifically if you want to be compatible to some kind of video standard, would require an external conversion from the luma/chroma signal to RGB. Otherwise, just for a neat HAM-mode, it would be sufficient to do something very simple as in the JPEG 2000 RCT (shifts and adds, neat for hardware), but again, I'm not clear whether that is actually needed. As far as I know, Miner's plans for the HAM were originally a YUV type of HAM mode where you could hold two of either the chroma or the luma signal, and modify exactly one of them - that is, exactly as HAM is today, but with YUV as components instead of RGB. See above - this mode might be neat - but HAM was mostly designed to save bandwidth. This is no longer an issue, thus it might not be needed anymore. The forth "pixel" for the 32bit mode could be used in a smart way for alpha-blending if the new blitter would contain support for it, i.e. use the forth pixel to blend BOBs onto the screen. That would be a pretty useful feature. HAM is - IMHO - no longer. Unfortunately, this type of blending is probably a bit complicated and hardware intensive (i.e. multipliers to compute the color mixture). Greetings,
Thomas
| |
Gunnar von Boehn
Germany
| | (Natami Team Member)
Posts 3727
14 Mar 2010 07:01
| You can do ALPHA blendng with the 3-Byte Hybrid Chunky moe also. The 24bit Hybrid mode is optimal in regards of bandwidth usage.
Its not that we are short on bandwidth.
Just like any Race Manufacturer tries to reduce weight on its cars its clever to optimize bandwidth. The 24bit mode reduces "car-weight" be 25%.
Image your sport car having the same horse power but 25% less weight.
| |
Gunnar von Boehn
Germany
| | (Natami Team Member)
Posts 3727
14 Mar 2010 07:06
| Gabriele Budelacci wrote:
|
Today, RAM price is more more lower, so I think it's possible to 'discard' extra 8bit, but with advantages for coding performance.
|
Yes, the 32bit mode has in fact an advantage if you decide to render the whole game using ONLY the CPU! The AMIGA-Blitter does render over 10 times faster than the CPU.
AMIGA was laways designed for BLITTER rendering.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 2089
14 Mar 2010 07:07
| Gunnar that was why i mentioned fetching 4 colour channels in one foul swoop.
since that still means when you make a burst of 128bit is you have 96bits of colour channels then you have 4 channels.
Besides on some rare occations you only need to update a single colour channel, now that saves another 200 percent if implemented correctly. ;) (8 bit instead of the the 3*8bit)
| |
Team Chaos Leader
USA
| | (Natami Team Member)
Posts 1199
14 Mar 2010 08:20
| Gabriele Budelacci wrote:
|
My hope is you provide a full chunky mode too, else another type of 'chunky2planar' routines are needed!
|
Don't worry Gabriele, I am with you! I am campaigning for a 32-bit per pixel gfx mode to be added in the future. With your help I am sure that we will succeed :)
| |
Gunnar von Boehn
Germany
| | (Natami Team Member)
Posts 3727
14 Mar 2010 12:08
| Marcel Verdaasdonk wrote:
|
Gunnar that was why i mentioned fetching 4 colour channels in one foul swoop.
since that still means when you make a burst of 128bit is you have 96bits of colour channels then you have 4 channels.
|
If you don't use 24bit mode but 32bit per pixel mode
then the Video DMA needs to fecth 33% extra (wasted)
and also the Blitter needs always to copy 33% extra (wasted) This means you would loose 33% GFX performance....
| |
Claudio Wieland
Germany
| | (Natami Team Member)
Posts 364
14 Mar 2010 14:19
| Don't you mean 25% ? Because if you had to render 6 planes instead of 3, your speed would go down to 3/6 = 50% . With 4 planes the speed would go down to 3/4 = 75% . ;-) Cheers
| |
Gunnar von Boehn
Germany
| | (Natami Team Member)
Posts 3727
14 Mar 2010 14:27
| Claudio Wieland wrote:
|
Don't you mean 25% ?
|
Is four 33% more than three or is three 25% less than four?
| |
Claudio Wieland
Germany
| | (Natami Team Member)
Posts 364
14 Mar 2010 14:35
| I asked because I wondered about the term "lose". If I drive 60km/h and slow down to 30km/h , I lose 50% speed. If I slow down to 6km/h I lose 90% speed. The way you say it it sounds as if you lost 1000% speed by going down to 6km/h from 60km/h. That sounds strange to me ;) .
| |
|
Do you have questions about the Natami?