Recent content by sireric

This was a good class in 2007 that posted all the notes: https://graphics.stanford.edu/wikis/cs448-07-spring/ Also, classic computer architecture books (computer architecture, Hennessy and Patterson; Parallel computer architecture, Culler) are all good, fundamental books on computer...

No, the L1/VC and L2 have their own network of busses (~384 GB/s) to communicate, which allows the L2 to broadcast their respective datas to the L1's. The L1s are tied to SIMD cores, while the L2's are tied to memory channel. The L2s and other heavy hitters (raster backends mainly) are tied...

Gotta get some popcorn!

No, it's centralized and gets data from multiple RS.

L1 is distributed by identical between SIMDs (each gets the same copy, so only one makes external requests). L2 is not distributed among SIMDs -- It's unified and available to all equally and fully.

I'm probably going to take a break from answering all (or most) questions at this point and checking every few hours. I'll still try to kick in when something obvious and easy (yes, I'm lazy) hits (I'll try to check daily). but I think that I've answered a lot of questions. And I'm starting to...

There's two aspects to consider. One is DX10 -- Today, there are but a few DX10 apps, and most of those don't really make use of that much DX10. But we built a chip to work on that, and that comes at a significant cost. So, a lot of the chip, today, stands idle when running games. As for...

Assuming the same engine speed, an 925~950 DDR3 is about the same real BW as a 1GHZ DDR4 (taking latency and various factors into effect). So, going from 825 MHz memory to 1 GHz or higher will make some difference, but it's on the order of 10~15% at most. And that would be only in high...

It's a mix -- With good compression or with enough BW, it pushes back to the engine. With poor compression or low BW, it's a bandwidth hog. Consequently, both BW and "Fillrate" contribute to the overall performance.

Certainly the field of "GPGPU" has been around for sometime and keeps on expanding. While not there when R600 was being conceived, it did influence it in some aspects, such as the read/write cache, precision requirements, different kinds of shader types, etc... A lot of the burden is still...

I actually checked on that a few weeks ago. There aren't that many settings, due to the controller being used (so no driver changes possible on number of different settings). I think we might want to improve that in the future.

I think that there's a driver update coming down to drop down 2D fan speed. Also, make sure that the cards aren't right on top of each other -- There is required spacing between the cards (I think we even ship spacers with cards). Otherwise, one is too hot. Great PC form factors :-(

Conceptually yes. However, DX10 has some restrictive items associated with fetching outside the 4K range (clear clamp rules on <0 and > 4093). As well, direct access to those registers only gives the need for 12b addressing. I'd have to check if we allow indirect addressing outside of the 4K...

There's a lot more reasons to do a smaller vector size for VS/GS. But historically and with current apps, there's been either little VS branching or even draw sizes; or the apps have been dominated by pixel processing (with large vertex:pixel ratios), and so vertex performance wasn't a big...

I have not looked at HLSL -- From a HW perspective, either can be selected. But perhaps a heuristic picks, at the compiler level. I haven't checked. Yep. Good question. I think it's likely. Should be available through CTM.