HSR vs Tile-Based rendering?
- Thread starter Raqia
- Start date
Dave B(TotalVR)
Regular
huh? 
Dave B(TotalVR)
Regular
Oh I thought he was havinga dig at me there for a mo 
lol
lol Dave B(TotalVR)
Regular
Chalnoth said:
Much longer than what?
When the patent was filed it specifically said for use in 3D graphics so we all spent ages going wow! what is it! where is the card with it in!
Then everyone forgot. I think its going to be used to shift unused areas of silicon arund the chip for load balancing across the whole chip (excluding certain areas probably) on a per clock basis.
For example MSAA requires quite a reasonable amount of die area, if its not being used tho why not use the logic for assisting in geometry transforms or something?
Dave B(TotalVR)
Regular
Oh and www.metagence.com
http://www.metagence.com/Downloads/Factsheets/MetagenceOverview.pdf
Hmm, SOL on finding a link to the patent info tho...
Maybe John or Simon could help there?
http://www.metagence.com/Downloads/Factsheets/MetagenceOverview.pdf
Hmm, SOL on finding a link to the patent info tho...
Maybe John or Simon could help there?
Dave B(TotalVR)
Regular
Well, that was just a specific example of one of many possible situations that could benifit.
But, the MSAA logic upsamples the geometry info amongst other things which invovles multiplications and such, so why not multiply different numbers from elsewhere on the chip and use the results elsewhere on the chip?
I mean, these things can run linux and dsp applications on the same core - functional similarities between linux and the handling of streaming data? on the low level - loads because it breaks down to the use of RISC instructions like MAD MOV MUL and such.
But, the MSAA logic upsamples the geometry info amongst other things which invovles multiplications and such, so why not multiply different numbers from elsewhere on the chip and use the results elsewhere on the chip?
I mean, these things can run linux and dsp applications on the same core - functional similarities between linux and the handling of streaming data? on the low level - loads because it breaks down to the use of RISC instructions like MAD MOV MUL and such.
I really don't see why this logic you're describing is any different than the typical triangle setup logic, other than the possibility that one would want to allow sample positions to not lie in an ordered grid. The real question I would have for you is, can this logic be used efficiently for other purposes in 3D graphics? If not, then there's not much point in generalizing it for a GPU manufacturer.Dave B(TotalVR) said:
Doomtrooper
Veteran
Actually he calls a spade a spade.
Dave B(TotalVR)
Regular
Chalnoth said:
The answer is probably, you're not just feeding the MSAA unit different numbers, your re-structuring it to deal with different tasks. Im sure Simon or John would be able to give you a more definitive answer but I fear they my be reluctant to comment
Well, I understand that part. What I don't understand is how more generalized processing would be useful at that stage in rendering.
If you wanted to make the units completely general, so that they're not necessarily acting on data at that stage in rendering, then you have another problem: that of using too many transistors for a piece of the rendering pipeline that is commonly used in a specific way.
And the other thing is that I'm not convinced that there is a single type of "MSAA unit" that one could identify in each video card that supports MSAA. There are different ways to tackle this sort of a thing.
One way would be to simply allow the triangle setup engine to generate separate information for z data and pixel data. Another way would be to have the triangle setup engine output normal pixel data that then enters this, "MSAA unit," where other z values are calculated for z testing (based upon triangle information that is also carried through).
If you wanted to make the units completely general, so that they're not necessarily acting on data at that stage in rendering, then you have another problem: that of using too many transistors for a piece of the rendering pipeline that is commonly used in a specific way.
And the other thing is that I'm not convinced that there is a single type of "MSAA unit" that one could identify in each video card that supports MSAA. There are different ways to tackle this sort of a thing.
One way would be to simply allow the triangle setup engine to generate separate information for z data and pixel data. Another way would be to have the triangle setup engine output normal pixel data that then enters this, "MSAA unit," where other z values are calculated for z testing (based upon triangle information that is also carried through).
Dave B(TotalVR)
Regular
You look at the picture of a 3D core and see how much space is used by logic specifically for the MSAA. A Metagence core would be able to run the calculations for the MSAA on one thread whilst doing other things on the same logic in another thread. Metagence has the load balancing issue there sorted.
Dave B(TotalVR)
Regular
As I understand MSAA, it upsamples geometry info then renders the scene as if twice as big but 4 pixels at once, if there is no tri boundary in the 4 pixels it renders then it only does the one texture lookup. Ask Dave or somebody for a better explanation though.
Anyway, upsampling all the geometry has gotta be a pretty big task in itself...
Anyway, upsampling all the geometry has gotta be a pretty big task in itself...
