ImgTec Launches Programmable Shader Graphics Family

[Nappe1]

Yes.

Cheers,

AJ

This was the most informative post in the whole thread. Or at least it's in top 3. you just need to know how to read between the lines. ( and there's 5 of them. )


and no, I am not joking.

 

[Dave Baumann]

Yes.

Cheers,

AJ

I would say that the end of the Xenos article wasn't entirely supposition...

 

[ddes]

If the TBDR advantages in small embedded/UMA architectures can't be surpassed, then theoretically at least other IHVs could easily consider using TBDRs of their own. As long as it wouldn't infringe IMG's patents, I don't see a problem there.

I believe it's not just IMG's patents, but also Gigapixel's patens, which are now owned by NVIDIA. I think IMG is also affected by these patents.

 

[ddes]

based on paper specs, no one has anything that can compete with SGX right now. G40 is the closest thing, but it's slower and less flexible. (though both have full OpenGL ES 2.0 support, SGX goes beyond that.)

I believe in mobile space you have to compare the performance/size/power ratios rather than pure performance, which is quite insignificant.

 

[Ailuros]

I believe it's not just IMG's patents, but also Gigapixel's patens, which are now owned by NVIDIA. I think IMG is also affected by these patents.

In what way "affected"?

 

[TEXAN]

I believe it's not just IMG's patents, but also Gigapixel's patens, which are now owned by NVIDIA. I think IMG is also affected by these patents.

TBR and TBDR are two different things.

Nobody has access to TBDR apart from IMG.

 

[Ailuros]

TBR and TBDR are two different things.

Nobody has access to TBDR apart from IMG.

Who says that Gigapixel's cores weren't DRs?

The Giga3D architecture processes the geometry in a different manner. The front of the rendering pipeline is very
much like a classical architecture. Following that is a binning and visibility culling system, and then a tile-based
rasterization system. In the case of the Giga3D architecture, primitives are accepted immediately without waiting
for rasterization. The Geometry/Binning/Visibility and Rasterization (or tiling) systems operate in parallel, but
normally on two separate frames. While binning frame N, frame N-1 is being rasterized. This means that before
rasterization begins, all required textures have been seen and work can be done to make them available as soon as
they are needed.
• Geometry processing
– Vertices are transformed to viewing space
– The primitive is clipped to fit the screen
– Vertex-lighting is computed and applied
• Binning and visibility
– Each primitive and its required information is associated with all of the screen tiles it touches
– All primitives and pixels which are covered by opaque surfaces are discarded
• Rasterization—performed per tile for all primitives that affect the tile
– Iterates colors
– Iterates texture coordinates
– Performs texture look-up and filtering operations
– Reads on-chip Z-buffer to get current depth value
– Compares Z-buffer depth to primitive depth—if primitive is closer, writes color and Z to the on-chip
tile-buffer
– After all primitives have been rendered, writes Color and, optionally, Z data to the external frame-buffer
In this case, the multi-sample calculations are done in parallel. This is possible because they access only a small but
very wide local tile buffer. Normal operation never reads Z values from external memory and only writes Color
values for the completed tile. Since there is a frame of latency between binning and rasterization, the system can
automatically tell when the application will do a Z read-back and can write the final Z values to the frame-buffer in
that case.

The fact that there is a frame of latency between the binning and rasterization steps provides the opportunity to
optimize performance for each scene. The primitives can be accepted very fast since they don’t have to be rasterized
immediately. Performance is more consistent much like systems that use triple-buffered rendering. As mentioned
above, Z values are only stored off-chip when read-back is requested. Texture management is greatly improved as
well. The device driver knows all textures that will be used before the scene is rasterized. It is then able to make
optimal decisions about which textures should be resident and which should come from host memory.

 

[Simon F]

I don't think it was deferred.

 

[3N1gM4]

The SGX looks to have an impressive spec list for a core targeted at mobile phones, but how much of it is going to matter? Developers will probably just keep to the minimum spec as defined in OpenGL ES2.0 and not bother with the extra functionality.

I noticed that GLES2.0 doesn’t support MRT’s – which is one of the features that Img Tech were hyping in their press release. And, it does support a new texture compression scheme that is supposedly superior to the S3/PVR 4bit/pixel texture compression methods.

Apart from closed systems such as Sega’s arcade boards the extra features will probably not be used. What ultimately counts is compliance to standards, core size, power efficiency, performance and compatibility with previous products.

 

[Ailuros]

I don't think it was deferred.

I wasn't immediate in the strict sense either with a binning engine the way I can understand it.

Speaking of, isn't the proposed OGL_ES2.0 texture compression scheme from Ericsson?

 

[Nappe1]

I wasn't immediate in the strict sense either with a binning engine the way I can understand it.

Speaking of, isn't the proposed OGL_ES2.0 texture compression scheme from Ericsson?

PACKMAN compression perhaps?
that's the one comes to my mind...

 

[Nappe1]

I believe in mobile space you have to compare the performance/size/power ratios rather than pure performance, which is quite insignificant.

yeah, but from this generation, (G40, SGX, Mali200) does any of the companies give any public information about power consumption numbers? we could (as always) speculate that SGX should not be as power hungry as MBX was, but there's no raw fact on that.

 

[Simon F]

PACKMAN compression perhaps?
that's the one comes to my mind...

It's an updated version of the one in their presentation at Siggraph 2003.

 

[3N1gM4]

PACKMAN compression perhaps?
that's the one comes to my mind...

LINK

 

[Ailuros]

yeah, but from this generation, (G40, SGX, Mali200) does any of the companies give any public information about power consumption numbers? we could (as always) speculate that SGX should not be as power hungry as MBX was, but there's no raw fact on that.

It's been often said that there's a difference between estimating power consumption on paper and what it turns out to be in a final implementation.

Given the capabilities of MBX I don't consider it power hungry at all; Freescale's MBX-Lite (MBX R-S from ARM) consumes according to them ~40mW@66MHz.

Falanx claims 2-3mm^2 (edit: die size) for their Mali 200. I'd be willing to bet that that's an estimate for their lowest end model of the series of graphics IP. To have those numbers in the same graph where you claim a maximum of 10M Tris/sec performance, is a bit sneaky.

 

[TEXAN]

Yes, Falanx does seem like a sneaky sort of a company to me.

Don't believe what comes out of their mouths I say.

 

[Simon F]

LINK

Looks like I'll have to do more work on the PVR-TC compressor.

 

[TEXAN]

I've done some reading up on paralax mapping and it's apparantly the best method of bump mapping in the business, and even the gpu's of the ps3 and xenos can't do it.

And yet this tiny GPU can. Absolutely amazing.

 

[SuperCow]

Uh?

To TEXAN:
Where on earth did you read that Parallax bump mapping couldn't be done on PS3 or Xenos? Parallax bump mapping is only slightly more sophisticated than "normal" bump mapping - it just requires two accesses to a bump map (normal + height data) instead of one (although there are even more advanced parallax bump mapping techniques which give you self-shadowing as well etc.). Off the top of my head the basic parallax bump mapping method could probably be done with PS1.4-level hardware.

 

[Lazy8s]

Imgtec changed the name of their new PowerVR architecture slightly from Unified Scalable Shader Engine to Universal Scalable Shader Engine, probably for greater distinction and to better reflect its encompassing of video along with vertex and fragment processing all from the same computational units.

If SGX's programmable floating-point power is accessible enough, the most computationally intensive tasks in general on mobiles could be moved to the PowerVR processor. Hopefully Intel is taking such considerations into account with Stanwood.