| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
FASTER 3D GRAPHICS
I've heard it said before that the way the VIC chip addresses memory (8x8 cells) makes it slower fo rendering graphics because of the extra calculations needed. So what way would you have had the Commodore engineers design an alternative addressing mode so that 3D graphics could be calculated quicker? I would realy appreciate your ideas on this. |
|
... 185 posts hidden. Click here to view all posts....
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Hey, I got the problem with that static RAM sorted out :)
I guess the next step for me is to decide what featues will make it into the redesign of the video cct and then actually start the redesign. So it will probably be a while before I have anything more to post. |
| |
Death Demon
Account closed
Registered: Feb 2005
Posts: 68 |
I'm going through this trying to figure out exactly what you want to do. The question posed is really simple enough, but the responses thus far are confusing to me.
1) Do you want to come up with a memory controller for the VIC chip that manages memory transfers better?
2) What memory chips are you using? Are you able to use more than one?
3) Can you do front/back buffer rendering?
Things you should consider:
1) Memory chips have different latencies associated with addressing different segments of memory. Figure out what those crossover points are and map them to the application you are doing. For instance, it may make sense to address memory in "tiles" versus lines or columns in order to avoid page flips.
2) Using multiple memories may aid in that you can map alternating lines and use the LSB of the line number to indicate which memory you are reading from. This also helps with tile mode rendering or any other mode. It allows you to hide memory accesses for one RAM while you are processing the request from the other RAM.
3) Try to avoid full frame blits. It's best to use a pointer that changes to point at the new frame once it's ready for display. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Hey Death,
Q1: What I'm designing is a simple PAL (possibly NTSC later) graphics cct that will have it's own RAM. The idea is to have the VIC II still running as normal. The two ccts will be synced so that the raster will be at the same point weather being generated by my cct or the VIC II. The programmer can switch between VIC II (default) or my graphics cct. The main idea is to have a graphics cct in a C64 were the user would not even have to be aware of it's existence. I want this cct to be transparent to the user (no additional video cables, no extra switches or anything).
Q2: At the moment I'm just using an 8k static RAM but this is only for trialing my current design. When my design progresses there will be a very large amount of RAM for the graphics cct (It will be necessary for the graphic modes). The idea I'm thinking about for RAM is to be able to bank in 8k sections of graphics RAM (which there will be a lot of) to the 6510. Alright I'll try to explain this as best as I can. I'm thinking of designing the cct so the programmer can, for each 8k block (banked into the 6510) choose too either "Read C64 RAM / Write C64 RAM" (normal operation), "Read C64 RAM/ Write Graphics RAM", "Read Graphics RAM / Write Graphics RAM" or "Read Graphics RAM / Write C64 RAM". OK that might not have made sense, basically you can change weather the 6510 will read from it's C64 RAM or the graphics RAM and if it will write to C64 RAM or to the Graphics RAM. You could even write to both C64 RAM and Graphics RAM at the same time if you wanted to. Anyway thats what of got in mind, it will be very flexible for the programmer.
Q3: What is front/back buffer rendering?
Point 1: Could you go into a bit more detail with the tiles thing. Is it common for graphics ccts to use this method? Is the size of the tiles normally defined by the programmer or set in hardware?
Point 2: Do you mean so that something like a graphics processor can be accessing more then one RAM at a time?
Point 3: With the blitter thing, I agree with what you say but I dont think there was a lot of demand for a blitter, how important do you think having the blitter is?
If you havent noticed I dont know much about 3D graphics or rendering so sometimes I will need some stuff (even simple stuff) explained to me. Also I want to keep this cct very basic, I dont want this to be one of them projects that never get finished because the person doing it got to carried away and set themselves an unachievable goal (thats why Im making no promises with the specs).
Thanks Death, please keep the suggestions coming.
P.S. I've started work on the color cct, It may take me a while to complete this part of the cct since I probably won't have much spare time for a while.
|
| |
Death Demon
Account closed
Registered: Feb 2005
Posts: 68 |
The questions you're asking can't necessarily just be answered with a right or wrong answer. Mostly, it depends on your specific requirements. So I can give you some pointers for general system architecture with some caveats so that you can make an intelligent choice as to whether or not that particular application makes sense for your use or not.
If you are using an on-die 8K SRAM, then you should be able to access data per clock regardless of the address. There's really no speedup associated with paying attention to banks. You may want to look at the total number of available ports on the RAM, though. For instance, a dual ported RAM will allow write and read access on the same clock. A multi ported RAM can allow multiple addresses to be read or written on the same clock. The area increase is minimal. I'm not sure what your particular application has available though. If this is an ASIC you are designing, it should be easy enough to use whichever RAM you want.
Also, since you're using an internal SRAM, I don't see any real need to worry about how the addressing is lined up. As long as you make sure you are dealing with contiguous chunks, there's really not going to be an issue here. No slick addressing scheme is going to provide you any tricks. If you're dual ported, you may want to make sure that you have things set up so that your 8K blocks aren't in danger of being written while being read (write-thru hazard).
For the last question:
Q3) Front/back buffers are essentially two copies of the screen. You render to the back buffer while displaying the front buffer. This gives you one extra frame to render the scene. Once it's done, you flip a bit so that the back buffer "becomes" the front buffer and vice versa. Not sure if this application would be of use to you since I think you want something that's completely compatible with the C64 VIC.
1) Tile mode rendering is really a trick to help optimize the utilization of external RAMS. You set up your "tiles" in footprints that correspond either to texture formats or your rasterizer's output swath configuration as well as the bank layout for your external DRAMs. It doesn't apply to SRAMs. The goal with a tile mode design is to make sure that your rendering to memory and pulling from memory is done in a tile that fits into the fastest accessible block of memory. DRAMs have latency penalties for page faults. You're trying to avoid those. Again, none of this applies to static RAMs.
2) Yes. Most modern graphics will access multiple RAMs. You spread the frame buffer across these multiple RAMs so that you can pull X lines out of ram A up until a page fault, then start accessing lines X+Z from ram A which causes a page fault. While you're waiting for the page fault to complete, you start accessing Y lines ot of ram B up until the page fault at which point ram A should be ready. This is for optimizing external DRAM accesses, but if you are using internal RAMs, it could allow you to use single ported RAMs in which you could be rasterizing the next ten lines to RAM B while reading the first 10 lines to display out of RAM A.
3) Could be entirely unimportant. Dunno. Sprites should be done with blits though. Anything that's an "overlay", so to speak, should be done with blits. That's going to be a fairly optimal way of managing them. Should be much faster then the way C64 originally handled them. Been a long time, but I seem to remember a lot of latency around the actual drawing of the sprite. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Death,
I'm not planning on using Dual Port RAM and at the moment the design has been done in discrete logic (and a couple of GALS) on bread boards (very messy and quite large) and also in a CPLD, at some time in the future I will probably have to look at going to an FPGA or something. I would like to use SRAM but I havent looked at prices or availability yet so that could change. The Ram doesn't need to be fast as this cct is low performance, it only needs to run at 8Mhz (although I may change that latter but even then the dot clock will still be 8Mhz). The cct is similar to the VIC II cct and will have a very similar output (same sync signals, same boarder area, same resolution etc) but I'm planning to have 256 colors available and a new way of formatting the screen so that 3D graphics can be rendered a little bit quicker, also I'm planning on having the graphics cct able to do things like clear portions of memory fast (in C64 terms anyway). Like the VIC II, the cct will only need to access RAM for half every clock cycle, this will allow me to use the other half of the cycle to do the clearing and stuff like that (as long as the 6510 isn't using that same half of the cycle which it will sometimes, but no more then 1 out of 8 pixel clock cycles anyway). Even if I don't use the other half of the cycle I can use the cycles above and below the boarders for these things since the cct doesn't need to access RAM at that time. Another thing that seems to be in demand is for the hardware to be able to fill graphics as they are being drawn.
As for buffers, my idea is to have a pointer that points to the start of where the cct will get the screen data from in RAM. In other words you can get your screen data from anywhere in RAM just by changing the pointer (so you could build up 1 or more screens in RAM while displaying a completely different one). Is this the same as using buffers?
I should point out that none of these ideas are set in concrete.
|
| |
Death Demon
Account closed
Registered: Feb 2005
Posts: 68 |
That's what buffering the frame is, correct. Double buffering is the name given to using two buffers. Triple uses three, and so on. Front buffer is the one that's being displayed on screen, back buffer is the one that's being written to.
Your best bet is to go with what you got. It sounds like you've thought the system through. You can build it and start to see some drawbacks, things you would like to have done better. If you could model the system in C (write a software representation of what you're doing), then you could simulate the graphics engine to see if it will behave the way you think it will.
Using the SRAM has the benifit that you don't have to consider refresh cycles. Timing will be a bit more friendly as well. They are going to be more expensive, but you're just doing this as a project and not something you're going to sell millions of, so that's OK.
Good luck! |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Hey, thanks Death,
A Question about solid filling, I was discussing this with someone on CBM Hackers and I asked about objects that are only partly on the screen and they suggested having larger area in memory then the area actually being displayed e.g. screen in memory could by 512x256 and the actual screen displayed would only 320x200. Allowing the hardware to fill the objects that only appear partly on screen. What do you think of this idea? and is method commonly used? I dont know much about how 3D images a calculated and drawn but there does seem to be demand for hardware filling.
|
| |
White Flame
Registered: Sep 2002
Posts: 136 |
No matter what virtual bitmap size you use (assuming you're not having 8GB of framebuffer RAM), you'll always hit cases where it's too small to include what you want to draw especially with perspective 3d renderers. You either need to clip before rasterizing, or have full-precision signed coords in the rasterizer that don't do writes when offscreen (slow but simpler). |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
You got a good point there. Can you explain to me what coords are? I'm guessing that there some kind of marker for where to start and stop filling? |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
coords = coordinates, (x,y) values, etc
So instead of the rasterizer calculating screen ram addresses to fill between, it would keep x,y coordinates of the segments it needs to fill. As it draws the raster line segments that make up the polygons, it needs to check what parts of that segment of the polygon is actually onscreen, and only draw that.
This would require that the video processor have larger registers in the rasterizer, and that it would loop through and try to draw every segment of a polygon even if it's fully offscreen. But like I said, this could be easy to implement in hardware, and you wouldn't have to write a software clipper. But another 'but' would be that you still have to do near-plane clipping for 3d, so if you're already doing that, you might as well just do full view frustum clipping, and have the simpler onscreen-only rasterizer in hardware. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 20 - Next |
