Talk:PowerVR

Untitled

The end of this page talks a lot about "AIBs" - can anybody make that more clear? What is an AIB? ThomasHarte 14:34, 28 October 2005 (UTC)

AIB stands for Add-in-Board. An AIB supplier is someone who takes a (typically graphics) chipset and builds a graphics card around it. It's pretty much a Value-added reseller for graphics cards. Cmdrjameson 18:10, 28 October 2005 (UTC)

Perhaps worth mentioning some drawbacks of the tile-based renderer? Ones from the top of my head: tile memory is preallocated on the video RAM of the card, reducing the amount available for texturing. This would also place a hard-limit on the total number of polygons able to be submitted per frame, after which no more polygons could be drawn. More awkwardly, this also puts a hard-limit on the maximum number of polygons allowed per-tile; which is far less predictable in practice. On the Dreamcase either of these conditions would just cause a run-time exception. As I understand it on the PC, such an exception was dealt with by transporting all the polygon data back over the PCI bus to the main PC; allocating more video RAM (potentially swapping out textures etc) and then re-submitting the polygon data. This would cause a major delay in rendering. TheMoog 14:29, 17 February 2006 (UTC)

If the scene buffer overflows, the scene gets rendered in multiple passes. All the scene data collected so far will be used to render the first pass, storing depth and color buffers for subsequent passes. However, there are techniques like metatiling that help prevent such a situation. 20:46, 20 April 2006 (UTC)

Does Intel 2900G carry the codename "Stanwood"? If so, it is based on MBX not SGX. 20:46, 20 April 2006 (UTC)

Infinite plane rendering

I remember reading in initial Dreamcast articles that "infinite plane rendering" was an important part of the technology. Can information be added about this?

Lazy8s: Infinite planes support was dropped after PowerVR Series 1, actually. They were a more flexible way of defining objects of which polygons were just a subset. Application designers, however, were overwhelming more familiar with conventional systems, so the later generations were optimized to deal with just triangles and quadrilaterals in Series 2 and eventually just triangles with Series 3.

Incorrect Info about the OMAP2420

There seems to be a mistake concerning the omap2420's components. The FPU is not the TI c55x DSP at 220 MHz. The FPU (called VFP) is an extension to the ARM11 core. The c55x DSP of the omap2420 which is a seperate core can't even do floating point operations (only 16-bit fixed point) :P Y3Ah27 (talk) 02:56, 14 September 2008 (UTC)

Hardware that does not take advantage of MBX/MBX Lite

There are some systems that even though they have MBX or MBX Lite they don't take advantage of it.

Some Samsung phones with OMAP2430 (i520, i550, i560, g810) for example, use a generic OpenGL ES driver (by NOKIA) which doesn't use MBX Lite. No acceleration is present on these phones and there will not be unless either Samsung or a 3rd party releases new firmware with updated OpenGL ES driver.

I've been told that this is also true for some Nokia phones. Only difference is that they use an OMAP2420 where MBX is disabled. I don't know which models are affected in that case. —Preceding unsigned comment added by 94.65.144.234 (talk) 10:58, 5 April 2009 (UTC)

Series 6

I removed the series 6 section, as it had just the text "Nothing officially announced". If there is stuff "unofficially" announced, feel free to re-add the section, this time citing some sources of the rumours' origins. Jalwikip (talk) 10:16, 21 April 2009 (UTC)

Confusing information.

 See Dreamcast which BEGAN development in 1997, and Nintendo 64 retail release in 1996. Nintendo 64 used the RCP (Reality Co-Processor) "is 
 one of two main chips for the Nintendo 64 (the other being the NEC VR4300). It was developed by Silicon Graphics for Nintendo." Nintendo 64:"The 
 RSP is a MIPS R4000-based 8-bit integer vector processor." 

The PowerVR PCX2 is same series as NEC embedded MIPS processors found as coprocessor on e.g. intel ethernet cards. The PowerVR series 1 chips were available before the VR2 series chip in Dreamcast.

Shjacks45 (talk) 11:52, 13 April 2010 (UTC)

Sorry where is the quote "The PowerVR PCX2 is same series as NEC embedded MIPS processors" located? PCX1 and PCX2 had nothing to do with NEC's line of MIPS CPUs (except that there was a system under development that used MIPS chips as the host CPU and for T&L acceleration).

Simon Fenney (talk) 09:09, 14 April 2010 (UTC)

KYRO and KYRO II

I think it's worth noting that these chips are share identical technologies, with the KRYO II being produced on a smaller process giving it higher core clock frequencies. —Preceding unsigned comment added by 86.15.87.56 (talk) 01:44, 26 June 2010 (UTC)

Series5 (SGX)

• SGX530 (14 MPolys/s, 500Mpx/s@200MHz) for the handheld mobile market
• SGX531
• SGX535 (28 MPolys/s, 1Gpx/s@200MHz, Max Memory Band (GB/s) 4.2GB/s) for handheld high end mobile, portable, MID, UMPC, consumer, and automotive devices (Intel calls it the GMA 500)
• SGX540 (twice performance of SGX530)

According the infos I found SGX540 has twice the processing units of SGX530 - but since it also has an improved design it's more than twice as fast. I found 90 million triangles/sec stated on a Samsung Website (http://samsungi9000galaxys.com/gaming-on-the-galaxy-s-powervr-sgx540-next-generation-moblie-gpu/) —Preceding unsigned comment added by 88.217.2.79 (talk) 09:12, 12 July 2010 (UTC)

SGX 543: Sorry to say, but the die size value is useless unless you specify the core config (number of cores, single or MP1 config). Also the bus width is wrong. — Preceding unsigned comment added by 188.99.123.42 (talk) 20:57, 28 June 2011 (UTC)

copyright violation?

the text in this article can be found word for word at this website. as can the text in the List of PowerVR products, which i have nominated for deletion considering the same information is covered in less detail in this article. not sure if this constitutes a copy vio as the user who posted the info on enotes.com could have also been the user who created the two articles on wikipedia. even the images on that website is link back to the wiki files used in this article. any thoughts? should this article also be nominated for deletion? it is completely unsourced and does appear to only really promote the companies website in addition to the copy and paste editing. WookieInHeat (talk) 04:41, 7 October 2010 (UTC)

after looking on google news there are numerous WP:RS discussiing the company, no need to nominate this article for deletion. but still, maybe a user more versed in wikipolicy could look over all this info to identify any infractions. cheers WookieInHeat (talk) 04:56, 7 October 2010 (UTC)

Isn't this more of a case of enotes plagiarising the Wikipedia article? 12.232.17.226 (talk) 15:12, 21 October 2010 (UTC)

At least today, the enotes article clearly cites Wikipedia as the source. So, the article here does not violate copyright, as it was the source to begin with. I will remove the nomination for deletion. - Johnlogic (talk) 23:31, 25 October 2010 (UTC)

Controversy surrounding GMA 500

There should be some content here about the manufacturer's refusal to continue creating Linux drivers for this closed-API chipset, and about Intel's falling-out with the company due to the bad press Intel gets for not getting the real manufacturer to support the GMA 500, a relabelled PowerVR. Millions of netbooks are unable to upgrade to or otherwise install a current Linux kernel and GNU/Linux distribution (due to X server version, library deps, etc) because of this. As a result, they must run old, unsupported software that places them at a security risk due to known vulnerabilities in these old versions.

-128.61.83.190 (talk) 09:17, 24 November 2010 (UTC)

Intel GMA#GMA 500 on Linux suggests the drivers were made by Tungsten Graphics (now acquired by VMware) not PowerVR. As PowerVR generally primarily licence their tech for others to integrate, it's not clear how much driver support they would provide, my guess is it will be minimal unless Intel paid for it (but the fact they paid someone else to make the drivers suggest they didn't). In other words, it's not really clear whether it was PowerVR's fault at all, or Intel's dealings with the company they subcontracted to write the drivers. Mind you, one would presume their subcontractee would be willing to release their work as open source if Intel paid enough however they apparently worked on drivers for several different manufacturers so it's not unsurprising if they would expect decent payment if they feared releasing their work as open source would compromise their other work. Now it's possible Tungsten Graphics were allowed access to proprietary PowerVR code as part of the deal, and this required the code to be kept proprietary but even if this were the case, and we have no evidence it was, it's still likely a case of they would have released it if Intel paid enough (again bearing in mind PowerVR licence their tech to many manufacturers and may be concerned about any loss they may suffer would likely expect a decent payment). This non RS [1] says something similar. BTW as for Intel falling out with PowerVR Intel's recent moves don't exactly support that idea. Nil Einne (talk) 02:48, 18 July 2011 (UTC)

Wiki Categories.

Per my post in Apple inc. Hardware category, removing PowerVR as it is owned and designed by Imagination Tech. Daniellis89 (talk) 00:42, 27 January 2011 (UTC)

Ok, but you also removed the language inter-wiki links after the category link. In future be more careful with your edits e.g use the 'show changes' button to see exactly what you've changed. --Imroy (talk) 11:58, 27 January 2011 (UTC)

Shippoop, sorry bout that, Yeah, I epic failed there. Daniellis89 (talk) 22:34, 28 January 2011 (UTC)

Series6 (Rogue) comparision with Mali-400 MP

I have removed the reference to Mali-400 because the paper linked as [3] is not validating this erroneous claim and does not reference the product. Fifthbro (talk) 18:47, 28 March 2011 (UTC)

Power VR chipsets

I just found this new item from 2001 and wonder where it fits in. Maybe it's already covered elsewhere. Thanks. --Trevj (talk) 11:19, 9 May 2011 (UTC)

That just refers to MBX. Simon Fenney (talk) 08:40, 17 May 2011 (UTC)

Wrong description

'Tiles are rendered using a process similar to ray-casting. Rays are cast onto the triangles associated with the tile and a pixel is rendered from the triangle closest to the camera. The PowerVR hardware typically calculates the depths associated with each polygon for one tile row in 1 cycle.

This method has the advantage that, unlike a more traditional z-buffered rendering pipeline, no calculations need to be made to determine what a polygon looks like in an area where it is obscured by other geometry.'

That's wrong, see: http://www.imgtec.com/factsheets/SDK/PowerVR%20Technology%20Overview.1.0.2e.External.pdf page 7. They process the triangles one by one, which is rasterization, RT can't work in that order, also it's stated that the (MBX in this case) has a Z-Buffer - which you know if you ever programmed on a MBX/SGX.

A small technical point - it states ray casting not ray tracing and so you can work in any order. Anyway, I think it's possible the use of the 'ray' term in the description might stem from an early PowerVR patent (e.g. US 5,596,685) which describes the rendering of convex polyhedra Simon Fenney (talk) 12:59, 24 October 2012 (UTC)

FYI, I didn't understand the technology claim made in the quoted sentences, until I read Deferred shading. That page explains the benefit: lighting and texture lookup work is avoided for pixels of polygons that are not visible. That's the meaning of "no calculations ...". The other essential fact here is that PowerVR hardware rasterizes (depth calculation) A WHOLE ROW of a polygon in 1 clock cycle. I almost overlooked that. Not "1 pixel per clock" but "1 tile row per clock". Not a typo. Possible because of specialized hardware, and working in on chip RAM. Deferred rendering means that the "wasted" work (of not-seen pixels) is reduced to something that hardware then astoundingly speeds up. Basically, the technique is a form z-culling. Working with a small tile, presumably the Z-buffer for a tile is in on-chip RAM, lessening the need for power-hungry high-bandwidth external memory. So on the one hand it might be correct to say "no big deal, this is just fast polygon rasterization and z-buffering", it is important to grasp the exact details, to understand how this results in an allegedly more power efficient solution. ToolmakerSteve (talk) 04:25, 23 October 2012 (UTC)

If you think ImgTec is using raycasting in some chips, please provide a source of that claim, as it sounds ridiculous. — Preceding unsigned comment added by 188.100.48.33 (talk) 20:56, 7 May 2012 (UTC)

This objection I fully agree with. The technique does NOT "cast rays". So it shouldn't be described as doing so. According to ImgTec's white paper, and the referenced wiki page on deferred rendering, it uses a variation on Z-buffering, not on ray casting. ToolmakerSteve (talk) 04:31, 23 October 2012 (UTC)

Having thought about this further, I concur even more strongly with the two other posters. The description seems to be a comparison to early hardware implementations of z-buffering, which rendered all pixels of all polygons, only using z-buffer to decide whether to keep or to reject each rendered pixel. (Presumably because the complexity of skipping the pixel render exceeded the cost savings. Simple pixel rendering, before modern shaders.) Not a fair comparison to either modern graphics cards, nor to how those cards are used by current game developers, AFAIK. HOWEVER, note that PowerVR is targetting uses that are limited by POWER consumption. Bottom line: I think the technique has a potential advantage, but the claim being made needs to be said differently, as it is NOT a ray-based technique, NOR does z-buffering INHERENTLY have the limitations being competitively cited. Quite the contrary. ToolmakerSteve (talk) 04:39, 23 October 2012 (UTC)

I've marked "Rays are cast" as "dubious", and the comparison to z-buffer rendering as POV. IMHO, the technology section reads as an "advertisement" for PowerVR's product, rather than as neutral, accurate, and source-citing. However, it does not do so blatantly enough to slap a more severe label on the section. And I did find it personally useful, so I wouldn't want it to be chucked as merely corporate advertising. I think there is a valid claim that can be made here, it just needs to be made more accurately. I don't know enough yet to rewrite it with that accuracy... ToolmakerSteve (talk) 06:14, 23 October 2012 (UTC)

Correct Values for GFlops for the 5 Series?

I doubt, that the GFlop values for SGX540, SGX545 and following are correct. They are listed with 7.2 GFlops, but comparing their values with the preceding entries (e.g. 535), the config core are double only. This would result in 3.2 GFlops. Is there a typo? Also, pleas check the 540's performance on this page: http://www.anandtech.com/show/4940/qualcomm-new-snapdragon-s4-msm8960-krait-architecture/3 There it is listed with 3.2 GFlops.

I suppose to also recheck the values for SGX543 and SGX544, for the fact if the GFlops are doubled for GPUs with USSE2 chipset. See here: http://www.anandtech.com/show/5072/nvidias-tegra-3-launched-architecture-revealed/2

This page from IMGTECH shows that for USSE => USSE2, the SMIDs are doubled: http://imgtech.wikispaces.com/Series6 — Preceding unsigned comment added by 193.141.219.36 (talk) 11:58, 3 July 2012 (UTC)

Incorrect information about series 6

Only MT8135 will be using G6200 chipset. — Preceding unsigned comment added by 5.28.169.125 (talk) 08:34, 10 August 2013 (UTC)

STG5500 - Listed memory bandwidth of 4GB/s? With DDR?

Under "List of PowerVR Chipsets", the STG5500 memory specs don't add up. Planned memory clock on the 5500 was 250Mhz vs 200Mhz for the 4800 - a 25% increase. This memory clock boost alone would account for the 25% increase in memory bandwidth (4.0 GB/s, up from 3.2). It was known that the STG4800 (used in the cancelled Hercules Kyro II SE) used SDR like its predecessors. The STG5500, however, was scheduled to use DDR (the table agrees on this part). DDR memory would of course double the effective memory bandwidth, resulting in 8 GB/sec. So either the 4GB/s figure is wrong, or it was going to use SDR (unlikely given the planned timeframe and statements attributed to David Harold).

Two other minor issues. The first is unavoidable: STG5500 was supposed to be a "Series 4" chip, sold in Kyro 3 boards. That didn't happen, so it gets lumped in with Series 3 here. The second is that the STG5500 was planned to have DX7-class hardware T&L. For those interested there were also rumors of DX8 shader support and 128MB of memory as an option. However, there's very little solid information on these last two items.

http://www.abload.de/img/01-12a-pic22de.jpg

Alexvrb (talk) 01:56, 11 September 2013 (UTC)

this page reads like an advertisement

just look at it, it's like a product pitch --72.37.171.188 (talk) 18:40, 22 June 2015 (UTC)

Article in Next Generation

There's a fairly detailed article on PowerVR in the April 1995 issue of Next Generation, but I don't understand the subject matter well enough to be able to make use of it. If anyone here is willing and able to use this reference to improve the article, the title is "Low-Cost 3D Power from VideoLogic" and you can find it on pages 16-17.--Martin IIIa (talk) 11:22, 7 June 2016 (UTC)

Layout

This page seems very repetitive with 'PowerVR chipsets' and 'List of PowerVR chipsets'. It seems like the first part is meant to be discriptions and the second is meant to be tables, but they appear mixed and repetitive. Should they just be merged (something like the Tegra page)? Dbsseven (talk) 18:44, 13 March 2017 (UTC)