Paletted Textures

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Paletted Textures

Post by BlackAura » Sun Jun 21, 2009 12:59 pm

The topic of paletted textures came up recently, and since it seems that nobody has the slightest clue how they work, I figured I might as well try to explain it. Most of this can be deduced from the pvr.h file included with KOS (which is how I managed to get this working), but it can be a bit of a pain. And I've already forgotten half of this stuff anyway - it might be useful to have a reference next time I need it.

Disclaimer: I'm nowhere near by DC dev setup at the moment, so I've not tested all of this, and the only code I have to go on is the PVR renderer from Genesis Plus / DC (which is a bit weird, since it handles twiddling itself, and builds polygon headers directly). So, although I'm pretty sure this is all correct, it may need a bit of tweaking to get it entirely correct.

Texture formats
The PVR supports textures in 16bpp (ARGB444, ARGB1555, RGB565) truecolour formats. That's pretty much the most common format used in Dreamcast homebrew. We've also got a 4bpp compressed format (you can generate textures in this format using vqenc, which comes with KOS), a bumpmap format (someone wrote a demo using this), and a YUV422 format (which is probably used for videos - I know of no homebrew that uses it). It also supports 8-bit and 4-bit textures using a shared colour palette.

If you look in pvr.h, you'll see a list of these in the PVR_TXRFMT_ flags. These are the values you pass as the textureformat parameter to the pvr_poly_cxt_txr function (or whatever the equivalent is in Parallax).

There are also two flags you can set in combination with the texture format. They are PVR_TXRFMT_TWIDDLED / PVR_TXRFMT_NONTWIDDLED, and PVR_TXRFMT_NOSTRIDE / PVR_TXRFMT_STRIDE. The defaults, if you don't set them, are PVR_TXRFMT_TWIDDLED and PVR_TXRFMT_NOSTRIDE. I have absolutely no idea what the stride flag does. The twiddled flag means that the pixels have been rearranged into a format that's optimized for bilinear / trilinear filtering. Exactly how this works is unimportant, but it's mostly used in 3D games to speed up rendering when using bilinear / trilinear filtering and mipmaps.

Just below that are two macros - PVR_TXRFMT_8BPP_PAL and PVR_TXRFMT_4BPP_PAL. These are used to specify which colour palette to use for a texture (more on that later). As the notes above the macros state, the bits in the texture format used to specify which colour palette to use happen to overlap the twiddled / stride flags. This means that all 4bpp and 8bpp paletted textures must be twiddled.

Colour palettes
The PVR has an internal bank of colour palette entries. This bank contains a total of 1024 colour palette entires, each of which is 32 bits wide.

The colour palette can be configured in three modes which match the format of the standard 16-bit textures: ARGB1555, ARGB4444, RGB565. There's also a 32-bit mode, which allows you to use ARGB8888 colour palette entries.

The palette mode is a global setting - it affects all rendering of paletted textures, so it's a good idea to set this to something that fills all your paletted texture needs.

ARGB8888 is the more versatile format. The Dreamcast renders internally at 32bpp anyway, converting down to 16bpp RGB565 (with dithering). The ARGB8888 format allows higher colour precision than any of the 16bpp formats, and much higher alpha precision. Unless you have a very good reason to use another format, I'd recommend using this one.

To set the palette format, you use the pvr_set_pal_format function, with one of the PVR_PAL_ values. For example, to set up an ARGB8888 palette:

Code: Select all

pvr_set_pal_format(PVR_PAL_ARGB8888);
To set a colour palette entry, use the pvr_set_pal_entry function. This function takes a palette index from 0 to 1023, and a colour value. The colour value is in whatever format you set the palette to. In our case, that's ARGB8888. So, to set the first four palette entries to transparent, black, white, and red, we could do something like this:

Code: Select all

#define PACK_ARGB8888(a,r,g,b) ( ((a & 0xFF) << 24) | ((r & 0xFF) << 16) | ((g & 0xFF) << 8) | (b & 0xFF) )

pvr_set_pal_entry(0, PACK_ARGB8888(0, 0, 0, 0));
pvr_set_pal_entry(1, PACK_ARGB8888(255, 0, 0, 0));
pvr_set_pal_entry(2, PACK_ARGB8888(255, 255, 255, 255));
pvr_set_pal_entry(3, PACK_ARGB8888(255, 255, 0, 0));
There are 1024 colour palette entries. If you're using 4bpp images (16 colours each), you treat this as 64 separate 16 colour palettes. Palette 0 consists of colours 0 through 15, palette 1 consists of colours 16 through 31, and so on. For 8bpp images, you get four 256 colour palettes, with palette 0 being colours 0 through 255, palette 1 being colours 256 through 511, and so on.

We'll cover how to select which palette to use later. If you do not set a palette, you end up with palette 0.

Loading textures
You can load a paletted texture in the normal way, using pvr_txr_load_ex. You just need to make sure they're twiddled, which pvr_txr_load_ex will do for you.

Actually loading texture data is a bit trickier than it could be - the utility functions in KOS to load textures automatically convert everything to 16bpp RGB565, which is obviously not what we want.

I might post some sample code for reading a paletted image later. Most likely, either a PNG, PCX, or BMP file. But for now, just assume that you've managed to load an 8bpp image from somewhere...

Code: Select all

void *image_data;
pvr_ptr_t texture_pointer;
int width, height;

// To load an 8bpp image...
pvr_txr_load_ex(image_data, texture_pointer, width, height, PVR_TXRLOAD_8BPP);

// To load a 4bpp image...
pvr_txr_load_ex(image_data, texture_pointer, width, height, PVR_TXRLOAD_4BPP);
Using paletted textures
Now that we've come this far, we get to the easy part - using the textures.

To use a paletted texture, you just need to specify the texture format when building the polygon header. For example, for an 8-bit texture with no filtering, using the default palette, and being rendered into the punch-through display list:

Code: Select all

pvr_poly_hdr_t hdr;
pvr_poly_cxt_t cxt;
pvr_poly_cxt_txr(&cxt, PVR_LIST_PT_POLY, PVR_TXRFMT_PAL8BPP, width, height, texture_pointer, PVR_FILTER_NONE);
pvr_poly_compile(&hdr, &cxt);
Same deal for 4bpp textures - just substitude PVR_TXRFMT_PAL4BPP.

If you want to use something other than the default palette, you need to use the PVR_TXRFMT_8BPP_PAL and PVR_TXRFMT_4BPP_PAL macros:

Code: Select all

pvr_poly_cxt_txr(&cxt, PVR_LIST_PT_POLY, PVR_TXRFMT_PAL8BPP | PVR_TXRFMT_8BPP_PAL(1), width, height, texture_pointer, PVR_FILTER_NONE);
The numbers passed to PVR_TXRFMT_xBPP_PAL are palette numbers, not indexes. So in this example, the texture will use the second 256 colour palette, consisting of palette entries 256 through 511.

Why bother?
The main reason is memory usage. An 8bpp image takes up half as much video RAM as a 16bpp image, and a 4bpp image takes up half as much again. This is useful for 2D games, particularly if the source images use colour palettes anyway.

You also get the ability to do palette animation, and use the same image multiple times with different colour palettes. These are tricks that a lot of old console games used to use to get animation from static images, and to provide a bit of variety to the graphics without needing to include more graphics data.

You can also use paletted images for fonts. The ROM fonts are natively 4bpp images. Typically, we would convert them to a 16bpp ARGB4444 image, with the colour of every pixel set to white. That's a huge waste of memory, when we could just load the font as a 4bpp texture. In fact, anywhere you might use an ARGB4444 texture with all the colours set to white can be replaced with a 4bpp texture.

It's also useful for simulating luminance-only and alpha-only textures. You can simulate a luminance-only (greyscale) texture by using an 8bpp image, and setting colour palette entry i to ARGB(255, i, i, i). Similarly, you can simulate an alpha-only texture by setting colour palette entry i to ARGB(i, 255, 255, 255). By itself, this isn't necessarily useful, since the PVR's framebuffer is only 5 or 6 bits per colour channel. However, if you combine this with blending, you can eliminate a lot of the rendering artefacts you'd get by using an ARGB4444 texture. For example, you might have a particle texture which is coloured by setting the vertex colours, and blended onto the scene, or a lightmap. Since the PVR renders everything internally in 32bpp, and only converts to RGB565 as the final step, rendering quality would be improved.

Not that anyone's likely to be using lightmaps on a DC homebrew game. It might be useful if you wanted to run something like Quake though. Think of the difference in lighting between software Quake and GLQuake. Software mode uses 16-level lightmaps, which creates a banding effect on the lighting. GLQuake uses 256-level lightmaps, and the lighting looks far better, even if you're rendering in 16-bit.

Y'know... It might be a good idea to write some kind of PVR reference guide somewhere. Maybe on the Wiki?

Edit: Corrected parameter order in pvr_txr_load_ex. Thanks BB Hood.
OneThirty8
Damn Dirty Ape
Damn Dirty Ape
Posts: 5031
Joined: Thu Nov 07, 2002 11:11 pm
Location: Saugerties, NY
Has liked: 0
Been liked: 0

Re: Paletted Textures

Post by OneThirty8 » Sun Jun 21, 2009 4:21 pm

Thanks for the detailed explanation! I had wanted to experiment some using paletted textures but never managed to find the time to figure out how they work.
BlackAura wrote:and a YUV422 format (which is probably used for videos - I know of no homebrew that uses it).
I am pretty sure that DCDivX uses the YUV422 format, and VC/DC uses it. It made much more sense to pack the Y,U, and V planes into one uyvy image than it did to convert to RGB565. For homebrew games and emulators, it probably wouldn't make much sense.
BB Hood
Insane DCEmu
Insane DCEmu
Posts: 169
Joined: Fri Mar 30, 2007 12:09 am
Has liked: 7 times
Been liked: 1 time

Re: Paletted Textures

Post by BB Hood » Sun Jun 21, 2009 4:23 pm

Code: Select all

pvr_txr_load_ex(texture_pointer, image_data, width, height, PVR_TXRLOAD_8BPP);
should be

Code: Select all

pvr_txr_load_ex(image_data, texture_pointer,width, height, PVR_TXRLOAD_8BPP); 

What is an "alpha-only texture"? and why "PVR_LIST_PT_POLY" because PVR_LIST_OP_POLY and PVR_LIST_TR_POLY both work. Thanks A LOT for this tutorial.
OneThirty8
Damn Dirty Ape
Damn Dirty Ape
Posts: 5031
Joined: Thu Nov 07, 2002 11:11 pm
Location: Saugerties, NY
Has liked: 0
Been liked: 0

Re: Paletted Textures

Post by OneThirty8 » Thu Jun 25, 2009 12:24 am

BB Hood wrote:
What is an "alpha-only texture"?
In the example BlackAura gave, he suggested a palette you could build like this:

Code: Select all

void somefunc()
{
 int i;

 for (i = 0; i < 256; i++)
 {
  pvr_set_pal_entry(0, PACK_ARGB8888(i, 255, 255, 255));
 }

}
A texture using that palette would have all white pixels, but depending on the value of the alpha byte, those pixels with a value of 0 for the alpha would be completely transparent while those set to 255 would be completely opaque, and some would be only partially opaque/transparent.
BB Hood wrote: and why "PVR_LIST_PT_POLY" because PVR_LIST_OP_POLY and PVR_LIST_TR_POLY both work.
I think he was just saying you could use the punch-thru list if you wanted to. I haven't used it for anything myself, but I believe that it's used for things that will have some pixels that are fully transparent and some that are fully opaque, but none that are partially opaque/transparent. You would use this display list because it's faster than using the transparent list.

I must say thanks again for this tutorial--I've managed to find a few free moments to work on some coding and this was incredibly useful to me.
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Re: Paletted Textures

Post by BlackAura » Thu Jun 25, 2009 9:14 am

BB Hood wrote:

Code: Select all

pvr_txr_load_ex(texture_pointer, image_data, width, height, PVR_TXRLOAD_8BPP);
should be

Code: Select all

pvr_txr_load_ex(image_data, texture_pointer,width, height, PVR_TXRLOAD_8BPP); 

What is an "alpha-only texture"? and why "PVR_LIST_PT_POLY" because PVR_LIST_OP_POLY and PVR_LIST_TR_POLY both work.
As OneThirty8 said, an alpha-only texture is a texture than contains no colours, but contains an alpha channel. The texture behaves as if it were all white, but if you render it with blending turned on (in the PVR_LIST_TR_POLY display list), the pixels with alpha=0.0 are fully transparent, and the pixels with alpha=1.0 are fully opaque.

You might use this to render anti-aliased fonts - draw the font glyphs onto an 8bpp (or 4bpp) greyscale texture. Load that as an alpha-only texture, and then draw a rectangle for each glyph in the PVR_LIST_TR_POLY display list. You get white anti-aliased text, blended with whatever's behind it. To change the colour of the text, you can change the vertex colours.

As for the display list chosen in the example - all three of the display lists would work. However, the most obvious use for paletted textures is 2D sprite graphics, which usually have only binary transparency. In this case, either the PT (punch-through) or TR (transparent) display lists would work. However, the PT display list simply skips transparent pixels, while the TR display list blends them with the background. The PT display list is almost as fast as the OP (opaque) display list, while the TR display list is much slower.

If you have any knowledge of OpenGL, the OP display list behaves the same as regular OpenGL rendering. Using the TR display list is the equivalent of doing this:

Code: Select all

glEnable(GL_BLEND);
Using the PT display list is the equivalent of:

Code: Select all

glEnable(GL_ALPHA_TEST);
glAlphaTest(GL_GREATER, 0.0f);
Punch-through is great for 2D sprites / backgrounds, particularly if you're not going to be scaling or rotating them.
BB Hood wrote:Thanks A LOT for this tutorial.
OneThirty8 wrote:I must say thanks again for this tutorial--I've managed to find a few free moments to work on some coding and this was incredibly useful to me.
You're welcome.
BB Hood
Insane DCEmu
Insane DCEmu
Posts: 169
Joined: Fri Mar 30, 2007 12:09 am
Has liked: 7 times
Been liked: 1 time

Re: Paletted Textures

Post by BB Hood » Thu Jun 25, 2009 3:48 pm

I didn't know PVR_LIST_PT_POLY was so useful and this is the first time i've heard of it. It's hard to find programs that still output in 8bpp and 4bpp but I found this free program if anybody else has trouble making 8-bit or 4-bit images. GraphicsGale.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5380
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 9 times
Contact:

Re: Paletted Textures

Post by BlueCrab » Thu Jun 25, 2009 6:34 pm

The Punch-thru list renders almost as fast as the Opaque list internally, and thus is the right way to go if you're doing a bunch of 2D sprites where there's no actual blending needed (other than removing transparent pixels). Internally, translucent rendering is a whole lot more work on the PVR. (I believe its around 2 times as much work to do translucent polygons, even if there's no actual blending happening as it is to do Opaque/Punch-thrus).
nymus
DC Developer
DC Developer
Posts: 955
Joined: Tue Feb 11, 2003 4:12 pm
Location: In a Dream
Has liked: 0
Been liked: 1 time

Re: Paletted Textures

Post by nymus » Thu Jun 25, 2009 6:53 pm

I'm not sure I agree with the claims of abysmal performance of translucent polygons. I'd have to check my old PVR marketing docs, but I think the issue with them is that PowerVR doesn't run as fast as the competition (eg 100 MHZ vs 400MHZ) so raw filrate is lower and hence textures would have to be looked up more repeatedly rather than once which would be rough due to limited bandwidth.

However, since it's per-pixel blending not per-polygon blending the overall impact of translucent polygons should be less than on conventional GPUs, shouldn't it? ie if a translucent polygon is occluded in a tile then that tile will run at full speed...??

Again, I'd have to confirm. I remember seeing an xbox game halve its frame rate in a corridor just because some dust was rendered. I don't think this would happen on PowerVR....

If a single translucent pixel was at the top and everything under it was opaque, then I believe PowerVR would only have to blend with the first opaque pixel below it and nothing more whereas conventional GPUs would blend all the pixels below, barring software-based deferred rendering...???
behold the mind
inspired by Dreamcast
BB Hood
Insane DCEmu
Insane DCEmu
Posts: 169
Joined: Fri Mar 30, 2007 12:09 am
Has liked: 7 times
Been liked: 1 time

Re: Paletted Textures

Post by BB Hood » Thu Jun 25, 2009 7:07 pm

It doens't work for me. I guess NullDC does not support it. Need to wait till I get my dreamcast back.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5380
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 9 times
Contact:

Re: Paletted Textures

Post by BlueCrab » Thu Jun 25, 2009 7:41 pm

nymus wrote:I'm not sure I agree with the claims of abysmal performance of translucent polygons. I'd have to check my old PVR marketing docs, but I think the issue with them is that PowerVR doesn't run as fast as the competition (eg 100 MHZ vs 400MHZ) so raw filrate is lower and hence textures would have to be looked up more repeatedly rather than once which would be rough due to limited bandwidth.

However, since it's per-pixel blending not per-polygon blending the overall impact of translucent polygons should be less than on conventional GPUs, shouldn't it? ie if a translucent polygon is occluded in a tile then that tile will run at full speed...??

Again, I'd have to confirm. I remember seeing an xbox game halve its frame rate in a corridor just because some dust was rendered. I don't think this would happen on PowerVR....

If a single translucent pixel was at the top and everything under it was opaque, then I believe PowerVR would only have to blend with the first opaque pixel below it and nothing more whereas conventional GPUs would blend all the pixels below, barring software-based deferred rendering...???
I believe that the performance penalty comes when the PVR goes and sorts the polygons internally for translucent drawing. I can't quite remember the details that I once read online, but I'm pretty sure that the sorting step takes significantly more time especially when translucent polygons overlap each other (since the sorting seems to be done on a pixel level). The actual drawing is fairly easy, once the sorting is done.
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Re: Paletted Textures

Post by BlackAura » Fri Jun 26, 2009 11:29 am

nymus wrote:If a single translucent pixel was at the top and everything under it was opaque, then I believe PowerVR would only have to blend with the first opaque pixel below it and nothing more whereas conventional GPUs would blend all the pixels below, barring software-based deferred rendering...???
That's right, but that only happens if you have mostly opaque polygons. If you throw everything in the TR display list, the sorting hardware has no way to determine if a polygon is occluded or not, so it will be forced to draw everything.

The deferred rendering approach is great for 3D games, where you can make use of opaque geometry to reduce the work the PVR does. It has fewer immediate benefits for 2D games, particularly classical tile-based games.

So it's not that blending is slow - it's actually bloody fast for such old 3D hardware. It's just that blending combined with lots of overdraw, which would be rare in 3D but typical in 2D, is likely to be slow.

The stated fillrate of the PVR2DC is 100 million pixels per second. That's enough to draw every pixel on a 640x480 screen slightly more than 5 times over at 60FPS. Genesis Plus / DC probably manages less than half of that before the PVR starts to slow down (average overdraw is around 2.2 or so). That's using the PT display list. GP/DC is probably a pathological worst case - thousands of tristrips containing only four vertices each - so I assume you'd be able to get closer to the limit with a more carefully designed renderer. So you might be able to draw each pixel on screen between 4 and 5 times, and still maintain 60FPS.

With that level of overdraw, blending would start to become slow, so it makes sense to turn it off if you don't need it. Rather than blending half the pixels on the screen once, you're having to blend every single pixel on screen five times. On a modern GPU, I could believe that blending would be as fast as no blending, but not on something as old as the PVR, and not one something that relies on reducing workload rather than brute force.

I honestly don't know what the overhead of sorting the TR and PT lists is like. It's entirely possible that GP/DC is limited by sorting performance rather than fillrate, in which case you can't really draw any conclusions about fillrate or blending performance.
Last edited by BlackAura on Fri Jun 26, 2009 11:31 am, edited 1 time in total.
Reason: Re-ordered paragraphs
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5380
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 9 times
Contact:

Re: Paletted Textures

Post by BlueCrab » Fri Jun 26, 2009 8:38 pm

BlackAura wrote:I honestly don't know what the overhead of sorting the TR and PT lists is like. It's entirely possible that GP/DC is limited by sorting performance rather than fillrate, in which case you can't really draw any conclusions about fillrate or blending performance.
I remember reading that sorting the PT list is just about as fast as sorting the OP list (once again, don't remember the source, so don't quote me on it).
BB Hood
Insane DCEmu
Insane DCEmu
Posts: 169
Joined: Fri Mar 30, 2007 12:09 am
Has liked: 7 times
Been liked: 1 time

Re: Paletted Textures

Post by BB Hood » Mon Jul 06, 2009 2:04 pm

Just for reference if anybody can't get the PT list to work is because mostly likely you initialized default PVR settings (ie. pvr_init_defaults();). So what you need to do is create your own PVR init settings like so:

Code: Select all

pvr_init_params_t params = {
	/* Enable opaque, translucent polygons and punch thru with size 16 */
	{ PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_16 },
	
	/* Vertex buffer size 512K */
	512*1024
};
^ put that above your main function and in your main function call:

Code: Select all

/* Init PVR API */
if (pvr_init(&params) < 0)
	return -1;
Reference (BlackAura Post)
TapamN
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Sun Oct 04, 2009 11:13 am
Has liked: 0
Been liked: 0

Re: Paletted Textures

Post by TapamN » Sun Oct 04, 2009 11:20 am

ARGB8888 is the more versatile format. The Dreamcast renders internally at 32bpp anyway, converting down to 16bpp RGB565 (with dithering). The ARGB8888 format allows higher colour precision than any of the 16bpp formats, and much higher alpha precision. Unless you have a very good reason to use another format, I'd recommend using this one.
There is a very good reason to use the other formats; they're faster. ARGB8888 palette pixels render at half speed compared to the 16 bit formats, so your theoretical maximum raw fillrate of 100 million pixels becomes 50 million per second.
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Re: Paletted Textures

Post by BlackAura » Sun Oct 04, 2009 11:57 am

Are you sure about that?

The DC's internal rendering buffer appears to be 32-bit anyway, and the internal palette banks are all 32 bits wide. I can't imagine what extra work the PVR would be doing that would cause it to halve the fillrate.

Then again, I will freely admit that my knowledge of how these things are actually implemented in hardware is close to zero, and that I've not bothered benchmarking any of this.

On that note, anyone got any ideas about how to measure the PVR's fillrate? The naive approach (just render loads of triangles, calculate their area, and multiply by the framerate) probably wouldn't be useful for OP polygons without disabling the depth buffer somehow.
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Re: Paletted Textures

Post by Chilly Willy » Sun Oct 04, 2009 1:18 pm

The fill rate would be half if it were writing ARGB8888. Clearly, it's twice the space of thousands, so you have to write twice as much data. If it were writing thousands mode, I'd see the speed would only differ by the time the dithering takes. I'd try any benches with and without dithering to see if that's where the speed loss was.
TapamN
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Sun Oct 04, 2009 11:13 am
Has liked: 0
Been liked: 0

Re: Paletted Textures

Post by TapamN » Sun Oct 04, 2009 2:48 pm

BlackAura wrote:Are you sure about that?

The DC's internal rendering buffer appears to be 32-bit anyway, and the internal palette banks are all 32 bits wide. I can't imagine what extra work the PVR would be doing that would cause it to halve the fillrate.

Then again, I will freely admit that my knowledge of how these things are actually implemented in hardware is close to zero, and that I've not bothered benchmarking any of this.
Yes, I'm sure. The PVR's interal frame buffer is 32 bit, so it has no problem writing 32 bit values, but it seems that whatever is responsible for reading texture colors can only process 16 bits at a time, so reading colors from a 32 bit palette takes twice a long as normal.
On that note, anyone got any ideas about how to measure the PVR's fillrate? The naive approach (just render loads of triangles, calculate their area, and multiply by the framerate) probably wouldn't be useful for OP polygons without disabling the depth buffer somehow.
It would depend on what you're trying to measure. If your trying to measure effective fillrate, to compare to a non-tile based GPU, what you just described would work fine. To measure raw fillrate, draw transparent full screen polygons with autosorting off, then do the calculations off of that.

However, for measuring fillrate, I think it would be better to draw a few large, rather than a bunch of small ones. It makes calcuations easier, and avoids having polygon calculations interfere with the actual drawing.
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has liked: 0
Been liked: 0

Re: Paletted Textures

Post by BlackAura » Mon Oct 05, 2009 9:39 am

Yes, I'm sure. The PVR's interal frame buffer is 32 bit, so it has no problem writing 32 bit values, but it seems that whatever is responsible for reading texture colors can only process 16 bits at a time, so reading colors from a 32 bit palette takes twice a long as normal.
Makes sense. It wouldn't have been worth the effort to natively support 32-bit textures, considering that almost every other texture format is 16-bit.
To measure raw fillrate, draw transparent full screen polygons with autosorting off, then do the calculations off of that.
Wouldn't that also measure the blend operation you're using? As far as I understand, the TR display list renders in the same way a PC graphics card would with blending enabled, so it has the extra step of combining the rendered pixel with the framebuffer.
TapamN
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Sun Oct 04, 2009 11:13 am
Has liked: 0
Been liked: 0

Re: Paletted Textures

Post by TapamN » Tue Oct 06, 2009 10:00 pm

BlackAura wrote:Wouldn't that also measure the blend operation you're using? As far as I understand, the TR display list renders in the same way a PC graphics card would with blending enabled, so it has the extra step of combining the rendered pixel with the framebuffer.
No, drawing one transparent pixel takes the same amount of time as one opaque pixel. It's not the same as a PC graphics card because the PVR uses a fast on-chip buffer instead of a slower external memory. (The extra step of blending things together is hidden by pipelining.) The PS2 and Xbox 360 have free blended pixels (compared to opaque pixels), like the PVR, since they use embedded DRAM instead of some form of external SDRAM to store their framebuffer. Of course, the PVR has "free-er than free" obscured-by-opaque pixels. You can actually use all of the blending operations with opaque polygons on the DC.
Post Reply