Navigate:

Advice
Beginners
BIOS Guide
CPUs
Links
Mainboards
Memory
Network
Storage
Video/Sound Cards

Contact
Forum
SiteMap
Sponsors
WebNews
Home
. .

Prices:

Mainboards

ABIT
ASUS
Chaintech
Shuttle
Soyo
Tyan

CPU
Intel
P4 2.4C-800
P4 2.6C-800
P4 2.8C-800
P4 3.0-800
P4 3.2-800

AMD
AthlonXP
XP 1700+
XP 2000+
XP 2400+
XP 2500+
XP 2700+
XP 3000+
XP 3200+

Athlon64
Athlon64 3200+
Athlon64 FX-51

Opteron
Opteron 240
Opteron 242
Opteron 244
Opteron 246

Memory

Corsair
Crucial
Kingston
Mushkin
OCZ

What are you
shopping for?



































































































































































LOSTCIRCUITS

SHORTCUTS:
top page
specs
tech. details
setup / 2D
SS7 D3D
SS7 OpenGL
SS7 CAD
Athlon D3D
Athlon OpenGL/CAD
conclusion
 3DLabs Permedia3 Create!
Mind Over Matter
(Review by MS, October 2, 1999)

Some more details

Specs are one thing but they hardly tell the story. So, let’s look a little deeper into the Create!. To start with the very basic, the core operates at 73MHz which is not exactly earth-shattering, at the same time, the memory is tacted at 110 MHz. It does not require Gaussian math capabilities to figure out that the common denominator of the two numbers is 220 MHz. Since the core itself can deliver 3 texture blend operations per (core chip) cycle this requires two reads per (memory) cycle and results in a maximum fill rate of the “Triple-Blend Texture Core” of 220 Mtexels/sec dual bilinear mip-map textures or 110 Mpixels/sec trilinear mip-map texture.

Fill rate is, however, not where the real strength of the Permedia3 chip lies. Rather is it the capability of taking full advantage of the DirectX 6 feature set and thus to perform up to eight DX6 multi-texture rendering operations per single pass

Bump Mapping

For an in depth description of the phenomenon of bump mapping, there is a very good article on Gamasutra explaining the different modes like emboss bump mapping. In general bump mapping can be performed in either software or else in hardware. Emboss bump mapping is basically an overlap of two inverted masks with a lateral displacement of the negative lighting scheme away from the origin of light. While this is the simplest form (thus the preferred software mode), it is also the least precise. On the other end of the spectrum is DOT3 bump mapping in which the normal of the triangulated surface is used to calculate the shadow / reflexion of each single pixel relative to the position of the light source.


What is a normal and what is DOT3?

DOT3 simply means that each pixel consists of 3 color values (RGB). A normal is a line orthogonal to a plane which can be used as reference for e.g. calculating the angle of the reflected light. The main drawback of this method, though it is implemented in DX6 is that it needs to be done on a pixel by pixel basis and thus it trades in speed for performance. With respect to suitability for different applications, it depends on the effects desired whether Environment Mapped Bump Mapping (EMBM) or DOT3 bumpmapping is the better choice. EMBM is good for moderately bumpy reflective surfaces (e.g. ripples on ponds), but cannot handle very bumpy surfaces well. In addition, it is quite a performance hit. DOT3 is good for lighting very bumpy non-reflective surfaces (e.g. mountain ranges), and can also do shiny surfaces. Emboss bumpmapping is also good at matt surfaces, but not as good as DOT3 at shiny surfaces, nor is it as good at very bumpy surfaces since the different slopes of the bump surfaces would require differential lateral displacement of the negative mask.

Virtual Texture Management

The best example to explain virtual texture management is Unreal. If you look at the flyby scene, and think that the castle wasn’t there, you would see all the textures in the background of the scene. But the castle is there and so there is really no need to load the entire panorama, render it and then, as a secondary effect block it out by overlaying the building. If there were a way to ignore everything hidden by the castle, it would make the amount of texture that needs to be loaded and processed much smaller and thus the game would run smoother. In order to do this, however, it is necessary to find a means not to load the entire background texture in one chunk but to actually split it into physical entities that can be accessed by logical addresses. If you have not read it yet elsewhere, here is the how and why as a quote from 3Dlabs’ white papers:

"The virtual texture engine is analogous to the instruction cache in your CPU. In an instruction cache, the CPU maintains a logic to physical address mapping of program instructions. When the CPU has a miss in the L1 and L2 cache, it DMAs the requested block of instructions from system memory into these cache levels. With Virtual Texturing, the principle is the same except that instead of instructions, it is fetching texture data, and instead of L1 and L2 instruction caches, we have on-chip and on-board texture memory.

Virtual texturing creates a logical address space for texture memory that maps to physical locations on-chip, on-card and in system memory. The maximum size for this logical address space is 256MB and is allocated in 4KB pages. When a texel is required for rendering by the graphics core, the Virtual Texture engine does a table lookup to see where the texture data is located. If the texture is not on-card, the Virtual Texture engine will DMA the required page into on-card memory where it can be accessed at full pixel rates by the graphics core. Since the Virtual Texture engine operates on 4KB logical pages instead of on whole textures, it allows both optimization of bus bandwidth as well as full use of on-board texture memory."

Note that we also have a hierarchically structured Unified Memory Architecture with cache, on-board and system memory. The hierarchy is necessary since even AGPx4 (at standard bus speed) is limited to 1.066 GB/sec whereas the on-board memory transfer can reach up to 2GB/sec. In addition, there are no less than seven DiME (direct memory execution) engines integrated in the Permedia3 which allow direct read and write to the system memory and thus account for extremely low CPU usage.

The main difference between virtual texture management and texture compression as realized by the S3 texture compression protocol (S3TC) is that compressed textures cannot be addressed in individual chunks according to need but need to downloaded as whole objects. Thus, even while they may load faster, unnecessary amounts of on-card memory are wasted while, at the same time, image quality is compromised. Moreover, S3TC needs to be supported by the application whereas virtual texture management is used automatically by all OpenGL 1.x applications and can be selected through the appropriate D3D storage mode (specialized D3D drivers). The effect is actually quite striking, at least in Unreal where selection of the wrong D3D mode causes a major choppyness whereas, in the correct mode, it runs amazingly well.

Next Page:    => next =>

Click Here!

If you enjoyed reading this article and found it useful, please consider making a small donation to LostCircuits.
Thank you!

General disclaimer: This page only reflects the author's personal opinion and assumes no responsibility whatsoever regarding any of the contents or any damages that may occur explicitly or implicitly from reading the contents of this site. All names and trademarks mentioned in this review are the exclusive property of the respective parent companies.
All contents of this site are protected by international copyright laws. Reproduction of the contents even in parts is not allowed except after written permission by the author and referral to this site.
Copyright 1998 - 2008 LostCircuits