| About the Memory | page 1 2 3
|
|---|
|
|---|
SID Hervé
France
| |
Posts 663
19 May 2012 21:36
| Hello If I understood correctly, the Natami has a single type of memory (DDR2) which is divided into two types : chip and fast. I guess this adds some delay. If it is the case, is it possible, at the hardware level, to add a memory access without going through the separation? Thank you.
| |
Thomas Richter
Germany
| | (MX-Board Owner)
Posts 1425
19 May 2012 22:34
| SID Hervé wrote:
|
If I understood correctly, the Natami has a single type of memory (DDR2) which is divided into two types : chip and fast. I guess this adds some delay.
|
Why should it? It is just a matter how the addresses are decoded and routed to the memory chips.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3974
19 May 2012 22:40
| To quote from the matrix
EXTERNAL LINK
It is something i honestly think applies here too.
It are just 'registers' who make the division this adds latency which already is less then that of the memory access and thus can be neglected for it is hidden in the memory access latency.there is no spoon.
| |
SID Hervé
France
| |
Posts 663
20 May 2012 00:14
| Thomas Richter wrote:
|
Why should it? It is just a matter how the addresses are decoded and routed to the memory chips.
|
This is precisely the problem.
So minimal it is, an operation at the hardware level should consume time. And a set of operations repeated consumes more time.
Maybe we could do without having to juggle between the chip and fast memories. This could simplify programming and reduce all the operations by introducing this unified memory (sorry, I did not find any other name).
NB: I did not say to remove the chip and fast memories otherwise goodbye to compatibility.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3974
20 May 2012 07:52
| there is no division at hardware level SID there is one memory to software there are two spaces that are variable in size that is set upon boot time AFAIK.(in the future this might be dynamic)
| |
SID Hervé
France
| |
Posts 663
20 May 2012 11:06
| I understood that when Thomas Richter introduced the decoding and routing, chip and fast memories are virtual. So it is no longer a hardware problem.
But it may be appropriate to move away from the topic. I guess these two types of memory can also be characterized by their priorities assigned to them in the DMA. So delays are deliberately introduced.
Would it be interesting to also consider the physical memory as a single with a high priority?
| |
Pawel K.
Poland
| |
Posts 53
20 May 2012 11:23
| making two memory modules, each with it's own controller would use FPGA logic and would also increase board cost performance gains would probably be close to zero % so it's not worth it...
| |
SID Hervé
France
| |
Posts 663
20 May 2012 12:27
| For this reason the use of one memory (DDR2) with one controller and the allocation of address ranges to create virtual types is more judicious. But from the viewpoint of programming, could we do without this separation?
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3974
20 May 2012 12:37
| it is not a real separation it is for the chipset to inform till here and no further.
This has nothing to do with the CPU nor anything besides the chipset.
| |
SID Hervé
France
| |
Posts 663
20 May 2012 13:08
| Yes, I already understood. This is no longer a hardware problem, but now, it's a software problem.
The data type determines the memory to use. Could we free themselves of this condition?
| |
Matt Hey
USA
| |
Posts 727
20 May 2012 15:17
| @SID Hervé
The CPU has access to all of the addressable memory. It's only the custom chips that are limited to access of chip memory. 2 memory paths can be 2x as fast when reading memory. The custom chips can read from one path while the CPU reads from another. Some gfx boards duplicated the same data in gfx memory to get 2x the read performance. The down side of having 2 paths is added complexity and having to move memory to the correct location for the needed processor to access it.The memory priority has no effect on the performance of individual memory allocations. It only affects the order of memory granted to memory allocations. Memory is prioritized when it is added to the free list as I recall.
| |
SID Hervé
France
| |
Posts 663
20 May 2012 16:28
| Thank you for the clarification.
When writing a code, it is necessary to reserve memory, one request for the fast and one request for the chip.
Why not combine these two request into a single?
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3974
20 May 2012 17:34
| SID could you care to explain the difference?
| |
Matt Hey
USA
| |
Posts 727
20 May 2012 18:00
| SID Hervé wrote:
|
When writing a code, it is necessary to reserve memory, one request for the fast and one request for the chip.
|
No. There is only 1 memory request with a flag for the type (attributes) of memory. MEMF_CHIP = chip memory for custom chips
MEMF_ANY = any memory will do (don't need chip memory) MEMF_FAST should generally not be used as some Amigas do not have fast memory and chip memory can't be used if fast memory runs out. SID Hervé wrote:
|
Why not combine these two request into a single?
|
There is only 1 request and no wasted memory in the case of the Amiga. It would be possible to unify the 2 types of memory (chip and fast) into 1 and there is logical arguments to do so or not. I doubt any speed difference would be noticeable either way.
| |
Břrge Nřst
Norway
| |
Posts 53
20 May 2012 19:51
| Pawel K. wrote:
|
making two memory modules, each with it's own controller would use FPGA logic and would also increase board cost
performance gains would probably be close to zero % so it's not worth it...
|
Now, this is not on-topic, but IIRC you're out of memory bandwidth when running 32bit 1080p. Correct me if I'm wrong.
| |
Samuel D Crow
USA
| | (Natami Team)
Posts 1295
20 May 2012 20:03
| Børge Nøst wrote:
| | Now, this is not on-topic, but IIRC you're out of memory bandwidth when running 32bit 1080p. Correct me if I'm wrong. |
That's why we're expecting the blitter to convert everything into 24-bit byte-planar mode for the final display. 25% less bandwidth requirements.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3974
20 May 2012 20:15
| 1080P at 32b does not place us out of bandwidth but it is not far from it, as Samuel said converting everything to 24b requires less bandwidth besides that IMHO in film there is not real need for a alpha channel in the final product. back to topic it is a single memory space physically only division is made for the chipset the CPU is not aware of this division itself for that part there is the software who is. I hope that was confusing enough for now.
| |
SID Hervé
France
| |
Posts 663
20 May 2012 20:22
| Matt Hey wrote:
|
No. There is only 1 memory request with a flag for the type (attributes) of memory.
MEMF_CHIP = chip memory for custom chips
MEMF_ANY = any memory will do (don't need chip memory)
MEMF_FAST should generally not be used as some Amigas do not have fast memory and chip memory can't be used if fast memory runs out.
|
Take for example a code that uses a database. All or part of this database must be loaded into a memory and its contents must be displayed.Would it be a mistake to reserve memory chip for the display and any other memory to load the database? wrote:
|
I doubt any speed difference would be noticeable either way.
|
I agree to the hardware side, but not for the software part.NB: Again, I'm sorry but my network access has been unstable since a few days. I always try to locate the problem. I'm not sure of its origin.
| |
Matt Hey
USA
| |
Posts 727
20 May 2012 20:58
| SID Hervé wrote:
|
Take for example a code that uses a database. All or part of this database must be loaded into a memory and its contents must be displayed.
Would it be a mistake to reserve memory chip for the display and any other memory to load the database?
|
The database would be allocated with MEMF_ANY. The display is usually allocated by the OS when opening a window and/or screen. An OS conforming application would only need to worry about passing data to the OS that is used by the custom chips like bitmaps/images, sound samples, 3D vertexes/textures, etc. as documented. Memory attributes can be specified with hunk flags in the executable besides dynamic allocations.SID Hervé wrote:
|
Matt Hey wrote:
|
I doubt any speed difference would be noticeable either way.
|
I agree to the hardware side, but not for the software part.
|
1 memory type:
The slow down is after running out of memory bandwidth as talked about with big 32 bit gfx displays.
2 memory types:
The slow down is from copying memory with the CPU from 1 memory type to another.
The latter is probably preferable if the HD/storage can DMA into any type of memory. I don't see how software can cause a slow down unless the memory copying routines are slow. Dynamic memory allocations would not be significantly slower either way.
| |
SID Hervé
France
| |
Posts 663
20 May 2012 22:39
| I am sorry, I forgot to indicate that the database contains text, images and sounds. What about for displaying images. Their data must be loaded into Chip memory chip. This memory is allocated through a request with the flag "MEMF_CHIP". So finally, two requests are needed.
| |
|
Do you have questions about the Natami?