Ramdac question.

[AAlcHemY]

Note that this sample position program used here won't show Quincunx's mix of samples from neighbouring pixels, which is done in the RAMDAC, and this only shows the base sampling points.

( Dave's 5700 preview, page 6, last sentence )

When reading that, it seems that the Ramdac has another function. ( besides the analogue/digital convertion )
I asked further info on Dave, but didn't make me any wiser. :?

Anybody that can give more info on this one? I couldn't find any myself.

Thanks.

 

[Neeyik]

What's there to understand? The RAMDAC simply reads off values within a buffer and then converts said values into a voltage level (assuming VGA connection) - it just so happens that the RAMDAC in that particular product contains a system to allow to blend specified values together.

 

[Xmas]

Actually, the term "in the RAMDAC" is a bit misleading. Historically, the RAMDAC has been a separate chip on the graphics card. The name RAM-DAC stems from the two parts it consists of, a SRAM color lookup table (palette) and three digital to analog converters for every channel.

Today, both parts are integrated into the GPU, and the term "in the RAMDAC" actually denotes anything that happens "after the framebuffer". Because of DVI and external TV-encoders, the on-chip DAC is not always used, but the color/gamma lookup and, on some hardware, AA downsampling, are.

 

[Simon F]

You could just as validly say that the AA functionality lies in the "DAC feed" unit, i.e. the part of the chip that is squirting RGB values at the (RAM)DAC for remapping and conversion to analog. (Of course, if you have an LCD panel with the digital interface, the D to A bit is unused).

 

[Captain Chickenpants]

Hmm, sounds a bit inefficient.
Presumably the AA is sampling pixels from above and below, which means that for each pixel it is fetching data from multiple locations which will be split over multiple pages, causing a lot of page break activity, which will take up some of your memory bandwidth. Add to that the fact that you are doing this for every frame even if the data being displayed has not changed.

Just a thought,

CC

 

[Simon F]

Hmm, sounds a bit inefficient.
Presumably the AA is sampling pixels from above and below, which means that for each pixel it is fetching data from multiple locations which will be split over multiple pages, causing a lot of page break activity, which will take up some of your memory bandwidth. Add to that the fact that you are doing this for every frame even if the data being displayed has not changed.

I'll come and explain in person

 

[arjan de lumens]

Hmm, sounds a bit inefficient.
Presumably the AA is sampling pixels from above and below, which means that for each pixel it is fetching data from multiple locations which will be split over multiple pages, causing a lot of page break activity, which will take up some of your memory bandwidth. Add to that the fact that you are doing this for every frame even if the data being displayed has not changed.

Just a thought,

CC

This problem could be solved in two ways:

• Keep a cache going forward or backward 1 scanline - 8 KBytes should be enough for a 2048-pixel scanline, and would take about 400K transistors, which is cheap these days.
• Rely on the memory controller to overlap page breaks and memory accesses. (DDR SDRAM chips have 4 banks internally, allowing you to burst data to/from one bank at the same time as doing page breaks in the other banks.)

 

[Captain Chickenpants]

Yeah, Simon also pointed out to me that relatively the actual cost of doing it this way is lower for traditional renderers. :?

In my experience HW engineers tend to get grumpy when we start asking for big linestores.

CC

 

[AAlcHemY]

Ok, thanks all, its mutch clearer now. ( little misunderstanding between ramdac - everything after the framebuffer )