Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / 3D Theory & Graphics / using MMX for 32 bit ARGB bilinear filtering Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Alex J. Champandard

June 01, 1999, 06:23 AM

Hi,

I've been woring on a 32 bit bilinear span renderer, and i was considering using MMX.

Loading the texel RGB information is easy as long as you use a palette. Otherwise, you have to
read in 64 bits, just to use the lower 32 bits! Btw, the higher 32 bits do not correspond to
the next texel!!
MMX does the packed multiplication of the colours by the coefficiants really efficiantly,
but the problem is getting the final RGB values out of the MMX regs. I can use a pack
instruction to get the 8.8 values (after the muls) down to 8 bits, but i think i have to
write the whole 64 bit qword register to memory just to get the lower 32 bits... which seems a
shame.
Writing two pixels at a time is not an option since i'm drawing vertical spans (voxel
rendering).

There must be a better way of doing this... but how?? (not using MMX is not considered a
valid answer :)

Cheers,
Alex




 
Dimitris

June 02, 1999, 11:18 AM



Alex J. Champandard wrote:
>>Hi,
>>
>>I've been woring on a 32 bit bilinear span renderer, and i was considering using MMX.
>>
>>Loading the texel RGB information is easy as long as you use a palette. Otherwise, you have to
>>read in 64 bits, just to use the lower 32 bits! Btw, the higher 32 bits do not correspond to
>>the next texel!!
>>MMX does the packed multiplication of the colours by the coefficiants really efficiantly,
>>but the problem is getting the final RGB values out of the MMX regs. I can use a pack
>>instruction to get the 8.8 values (after the muls) down to 8 bits, but i think i have to
>>write the whole 64 bit qword register to memory just to get the lower 32 bits... which seems a
>>shame.
>>Writing two pixels at a time is not an option since i'm drawing vertical spans (voxel
>>rendering).
>>
>>There must be a better way of doing this... but how?? (not using MMX is not considered a
>>valid answer :)
>>
>>Cheers,
>>Alex
>>
>>
>>
>>
If you show me what are you doing when you read or write pixels maybe i can help you.
What MMX instructions do you use?

By the way. I need a little help.
I want to deside what mip-map level to use for each pixel of the polygon not for the
whole polygon. If you don't know this just tell me how do you make mip-map in your TMT engine.
(When you will to release the source?)


 
Phantom

June 03, 1999, 03:38 AM

I am no MMX guru, so I will not contribute anything to this discussion. :)
However, Dimitris also asked something, about the mipmaps, and that
happens to be something that I encountered just a few months ago.
If you want to know which mipmap level you should use for a single pixel,
you have to determine the size of this pixel in texture space. I mean,
if the pixel represents four texels, it's obvious that you should use a
mipmap. Question is, how to calculate this.
Here's a way: The size of a pixel (in texture space) depends on the
delta-U and delta-V that you use to interpolate through texture space.
Thus, one could say that the size of a screenpixel in texturespace is
actually delta-U*delta-V. If this size is smaller than one, use the
original texture. If it's between 1 and 4, use the first mipmap. If it's
between 4 and 16, use the second mipmap. And so on.
Calculating the mipmap level for an entire subspan in your perspective
texturemapper should be a feasible option. I tried this in Focus, but I
never got it quite working. That was also because I tried to do the
twisted kind of mipmapping, where you have scaled versions of the
source texture in both U and V direction (forgot the name of the
technique).
Anyway, I hope this helps a bit, and if anyone has more information,
please correct me or add to my info.

Greets
Phantom

Dimitris wrote:
>>
>>
>>Alex J. Champandard wrote:
>>>>Hi,
>>>>
>>>>I've been woring on a 32 bit bilinear span renderer, and i was considering using MMX.
>>>>
>>>>Loading the texel RGB information is easy as long as you use a palette. Otherwise, you have to
>>>>read in 64 bits, just to use the lower 32 bits! Btw, the higher 32 bits do not correspond to
>>>>the next texel!!
>>>>MMX does the packed multiplication of the colours by the coefficiants really efficiantly,
>>>>but the problem is getting the final RGB values out of the MMX regs. I can use a pack
>>>>instruction to get the 8.8 values (after the muls) down to 8 bits, but i think i have to
>>>>write the whole 64 bit qword register to memory just to get the lower 32 bits... which seems a
>>>>shame.
>>>>Writing two pixels at a time is not an option since i'm drawing vertical spans (voxel
>>>>rendering).
>>>>
>>>>There must be a better way of doing this... but how?? (not using MMX is not considered a
>>>>valid answer :)
>>>>
>>>>Cheers,
>>>>Alex
>>>>
>>>>
>>>>
>>>>
>>If you show me what are you doing when you read or write pixels maybe i can help you.
>>What MMX instructions do you use?
>>
>>By the way. I need a little help.
>>I want to deside what mip-map level to use for each pixel of the polygon not for the
>>whole polygon. If you don't know this just tell me how do you make mip-map in your TMT engine.
>>(When you will to release the source?)
>>
>>

 
Dimitris

June 03, 1999, 05:15 AM


Phantom wrote:
>>I am no MMX guru, so I will not contribute anything to this discussion. :)
>>However, Dimitris also asked something, about the mipmaps, and that
>>happens to be something that I encountered just a few months ago.
>>If you want to know which mipmap level you should use for a single pixel,
>>you have to determine the size of this pixel in texture space. I mean,
>>if the pixel represents four texels, it's obvious that you should use a
>>mipmap. Question is, how to calculate this.
>>Here's a way: The size of a pixel (in texture space) depends on the
>>delta-U and delta-V that you use to interpolate through texture space.
>>Thus, one could say that the size of a screenpixel in texturespace is
>>actually delta-U*delta-V. If this size is smaller than one, use the
>>original texture. If it's between 1 and 4, use the first mipmap. If it's
>>between 4 and 16, use the second mipmap. And so on.
>>Calculating the mipmap level for an entire subspan in your perspective
>>texturemapper should be a feasible option. I tried this in Focus, but I
>>never got it quite working. That was also because I tried to do the
>>twisted kind of mipmapping, where you have scaled versions of the
>>source texture in both U and V direction (forgot the name of the
>>technique).
>>Anyway, I hope this helps a bit, and if anyone has more information,
>>please correct me or add to my info.
>>
>>Greets
>>Phantom
>>

This is the best and the faster solution they have told me.
Thanks Phantom.

( PS. I can't run Focus16B Or Focus15B under win98.
I have extracted all files properly (textures in FocusTextures, etc).
Do you know how can i correct this? )


 
Phantom

June 03, 1999, 09:01 AM

I have uploaded a previous (working) demo of Focus to
http://members.xoom.com/phantomus/Phantoms_Portfolio/Demos/Focus/focusdemo.zip
since the last version here on flipcode is a not-very-functional
work-in-progress demo. :) The demo on the xoom site should work
properly. If not, let me know. Be sure to extract with full path (winzip
will do that for you).

Dimitris wrote:
>>
>>Phantom wrote:
>>>>I am no MMX guru, so I will not contribute anything to this discussion. :)
>>>>However, Dimitris also asked something, about the mipmaps, and that
>>>>happens to be something that I encountered just a few months ago.
>>>>If you want to know which mipmap level you should use for a single pixel,
>>>>you have to determine the size of this pixel in texture space. I mean,
>>>>if the pixel represents four texels, it's obvious that you should use a
>>>>mipmap. Question is, how to calculate this.
>>>>Here's a way: The size of a pixel (in texture space) depends on the
>>>>delta-U and delta-V that you use to interpolate through texture space.
>>>>Thus, one could say that the size of a screenpixel in texturespace is
>>>>actually delta-U*delta-V. If this size is smaller than one, use the
>>>>original texture. If it's between 1 and 4, use the first mipmap. If it's
>>>>between 4 and 16, use the second mipmap. And so on.
>>>>Calculating the mipmap level for an entire subspan in your perspective
>>>>texturemapper should be a feasible option. I tried this in Focus, but I
>>>>never got it quite working. That was also because I tried to do the
>>>>twisted kind of mipmapping, where you have scaled versions of the
>>>>source texture in both U and V direction (forgot the name of the
>>>>technique).
>>>>Anyway, I hope this helps a bit, and if anyone has more information,
>>>>please correct me or add to my info.
>>>>
>>>>Greets
>>>>Phantom
>>>>
>>
>>This is the best and the faster solution they have told me.
>>Thanks Phantom.
>>
>>( PS. I can't run Focus16B Or Focus15B under win98.
>> I have extracted all files properly (textures in FocusTextures, etc).
>> Do you know how can i correct this? )
>>
>>

 
Dimitris

June 03, 1999, 02:21 PM

It seems that i'm not very lucky.
If the demo runs with your computer under windows98
then something must going wrong with my win98.
Do i must have something from scitech installed?



 
Dimitris

June 03, 1999, 06:15 PM



Dimitris wrote:
>>It seems that i'm not very lucky.
>>If the demo runs with your computer under windows98
>>then something must going wrong with my win98.
>>Do i must have something from scitech installed?
>>

Ok. The problem was that i had windows in 32 bit display.
I turned windows in 16 bit and the problem corrected :)
So, if anybody of you have problems running FOCUS check this.
Greets
Dimitris


 
Alex J. Champandard

June 04, 1999, 07:53 AM

>>By the way. I need a little help.
>>I want to deside what mip-map level to use for each pixel of the polygon not for the
>>whole polygon. If you don't know this just tell me how do you make mip-map in your TMT engine.
>>(When you will to release the source?)


I designed my TMT engine nearly 2 years ago...and i've just added a couple features since,
i really should change the whole structure. Anyway, mipmaping is nothing clever... i use texture
sizes from 256x256 down to 32x32 in powers of 2, and change the mipmap according to the Z coordinate
of the centre of the poly... (i bet you think less of me now :)

On the other hand, my OpenVL engine uses awesome span level bi-directionnal mipmaping (if i may say
so myself). Basically at the span level, you have at your disposition du and dv, probably in 16.16
fixed point. My engine first checks du, and if it's above 65536 (>1), then i use a texture size
twice smaller in X, and i divide u and du by 2. I repeat this procedure until du is below 65536...
and i do the same for dv... i am sure therefore than no texels are skiped, and in combination with
bilinear filtering, that gives me anisthropic (spelling??) filtering :)

I'll e-mail you the source of Indirect 3d now. If anyone else is interested, please mail me.

Cheers,
Alex

 
Dimitris

June 05, 1999, 01:28 PM

I'm sorry but i had wrote my e-mail wrong.
The correct as you can see is Dimitris_CE@Yahoo.com

Bye :)

 
Martin Hristov

June 07, 1999, 04:04 AM



Alex J. Champandard wrote:
>>>>By the way. I need a little help.
>>>>I want to deside what mip-map level to use for each pixel of the polygon not for the
>>>>whole polygon. If you don't know this just tell me how do you make mip-map in your TMT engine.
>>>>(When you will to release the source?)
>>
>>
>>I designed my TMT engine nearly 2 years ago...and i've just added a couple features since,
>>i really should change the whole structure. Anyway, mipmaping is nothing clever... i use texture
>>sizes from 256x256 down to 32x32 in powers of 2, and change the mipmap according to the Z coordinate
>>of the centre of the poly... (i bet you think less of me now :)
>>
>>On the other hand, my OpenVL engine uses awesome span level bi-directionnal mipmaping (if i may say
>>so myself). Basically at the span level, you have at your disposition du and dv, probably in 16.16
>>fixed point. My engine first checks du, and if it's above 65536 (>1), then i use a texture size
>>twice smaller in X, and i divide u and du by 2. I repeat this procedure until du is below 65536...
>>and i do the same for dv... i am sure therefore than no texels are skiped, and in combination with
>>bilinear filtering, that gives me anisthropic (spelling??) filtering :)
>>
>>I'll e-mail you the source of Indirect 3d now. If anyone else is interested, please mail me.
>>
>>Cheers,
>>Alex

What about poly flasing with SPAN level MIP map?

 
Alex J. Champandard

June 07, 1999, 06:46 AM



Martin Hristov wrote:

>>What about poly flasing with SPAN level MIP map?

Never heard of that before, please enlighten me... (maybe i didn't understand the question :)

Alex

 
Dimitris

June 07, 1999, 01:24 PM

>>What about poly flasing with SPAN level MIP map?

What is a flasing poly?:)

 
Michael Herf

July 02, 1999, 02:21 PM


>>so myself). Basically at the span level, you have at your disposition du and dv, probably in 16.16
>>fixed point. My engine first checks du, and if it's above 65536 (>1), then i use a texture size
>>twice smaller in X, and i divide u and du by 2. I repeat this procedure until du is below 65536...
>>and i do the same for dv... i am sure therefore than no texels are skiped, and in combination with
>>bilinear filtering, that gives me anisthropic (spelling??) filtering :)

This technique is NOT anisotropic. It is, in fact, uniform, since each texture sample represents a square sample of the texture space. Anisotropic can sample from a non-square region. MIPMap techniques without scan conversion of the texture generally over-filter (make blurry).

Anisotropic is probably not suitable for real-time in software, since it would require 9-25 samples of the texture, and lots of multiplies to reconstruct a value.

mike

 
Michael Herf

July 02, 1999, 02:24 PM

Use movd (32-bit load) both ways.
It's actually fastest to avoid unaligned loads with "movq"
in the case of arbitrary bilinear. If you want to use twice as much memory,
you could ensure that every pair of texels is 64-bit aligned (by duplicating them.)

Anyway, even with movd, MMX will still definitely win, because the unpacks, multiplies, etc., will be about 2x faster than x86 asm.

mike

 
This thread contains 14 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.