Original Post
Greetings,
I'm implementing my own multi-threaded tile-based software rasterizer, and I've come across an interesting issue with handling tiles. According to this article, the Larrabee rasterizer works by dividing the screen buffer into 128x128 tiles (or sometimes 64x64). How do you handle the edges of the screen when normal screen resolutions aren't powers of two?
The solution is that you obviously have to have tiles that aren't power of two for the edges. But take 800x600 as an example, I'd end up having a 32x128 tile on the right edge of the screen. Would you simply use that skewed tile as the edge and not worry about it?
I guess the alternative could be to merge that into the adjacent tile, so then I'd be looking at having 144x128 on the right side. I'm not sure which is better.
I guess Larrabee does its inner tile calculates on 16x16 pixel mini-tiles. In that case, even if they did use some 32x128 tiles, they would still be multiples of 16 so the vector code wouldn't break.
Maybe this isn't even a big deal. I'm just trying to understand the best way to tackle this problem. What do you guys think?
I'm implementing my own multi-threaded tile-based software rasterizer, and I've come across an interesting issue with handling tiles. According to this article, the Larrabee rasterizer works by dividing the screen buffer into 128x128 tiles (or sometimes 64x64). How do you handle the edges of the screen when normal screen resolutions aren't powers of two?
The solution is that you obviously have to have tiles that aren't power of two for the edges. But take 800x600 as an example, I'd end up having a 32x128 tile on the right edge of the screen. Would you simply use that skewed tile as the edge and not worry about it?
I guess the alternative could be to merge that into the adjacent tile, so then I'd be looking at having 144x128 on the right side. I'm not sure which is better.
I guess Larrabee does its inner tile calculates on 16x16 pixel mini-tiles. In that case, even if they did use some 32x128 tiles, they would still be multiples of 16 so the vector code wouldn't break.
Maybe this isn't even a big deal. I'm just trying to understand the best way to tackle this problem. What do you guys think?