# Handling non-power of two screen resolutions with tile based rendering

This topic is 2802 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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?

##### Share on other sites
Little screen rect check is neaded to skip pixels that are out of screen area.
It`s not ideal sollution, but amount of wasted processing power is minimal.

example:
bucket size = 64 x 64
screen size = 1025 x 1025 (notice that there is one pixel overflow)
buckets area = 17 x 17 buckets (1088 x 1088 pixels)

pixels calculated = 1183744
wasted pixels < 2% (with early exit this can be divided by about 10)

/Tyrian

• 33
• 12
• 10
• 9
• 9
• ### Forum Statistics

• Total Topics
631352
• Total Posts
2999486
×