From PowerVR Series5 Graphics.SGX architecture guide for developers.1.0.8.External.pdf:
Once a tile has been rendered, the Pixel Back End (PBE) combines the subsample colours for each fragment into a single colour value that can be written to the frame buffer in system memory
In OpenGL spec:
An additional buffer, called the multisample buffer, is added to the framebuffer.
Pixel sample values, including color, depth, and stencil values, are stored in this
buffer.
seems that these two are conflict, PowerVR said no additional buffer in framebuffer, but OpenGL spec said there is an additional buffer.
Hi,
I think the details that may be required to fully answer this and many of the other questions you have asked on the forum may be IP sensitive.
If you want to continue with this discussion, please send an email to devtech@imgtec.com and we can try and set up an NDA.
If you are asking the questions to evaluate the hardware or to create drivers, we have private channels that are better suited to these kinds of discussions.
Joe wrote:
Hi,
I think the details that may be required to fully answer this and many of the other questions you have asked on the forum may be IP sensitive.
If you want to continue with this discussion, please send an email to devtech@imgtec.com and we can try and set up an NDA.
If you are asking the questions to evaluate the hardware or to create drivers, we have private channels that are better suited to these kinds of discussions.
I think the details that may be required to fully answer this and many of the other questions you have asked on the forum may be IP sensitive.
If you want to continue with this discussion, please send an email to devtech@imgtec.com and we can try and set up an NDA.
If you are asking the questions to evaluate the hardware or to create drivers, we have private channels that are better suited to these kinds of discussions.
don't think it is a good manner for you to answer such for so many questions. I never touched the IP sensitive part and all are raised from your public released documents, the open/public forum should be able to discuss such questions.
Take this quesiton as an example, my concern is that the info in your document is conflict with OpenGL spec, i do not see any thing should be kept secert to answer YES or NO.
take another question "any document for SGX543MP1-16, SGX544MP1-16, SGX55" as an example, i'm just asking if you have any released public document? I guess there should be some documents and so I asked.
take another exmaple "what does flush buffer mean in PB manage", is this not a good topic to answer in this public forum?
as for another example "when aer fragments groupped per tile", actually I think it is a logic error in the document since it says A here but says !A there. It is still a good topic to discuss the public document issues here.
Hi,
Usually when we get so many questions about how the hardware works, it is from a company that wants to evaluate the hardware.
I was still intending to answer the topic’s you’ve posted where I know we can discuss the issues publicly, but I wanted to ensure that you were using the correct method of communication before continuing discussions that may lead into potentially IP sensitive information being posted on the forum.
In regards to the original question on this topic, the graphics cores that are listed as being OpenGL capable are completely conformant with the specification. The Multi Sample Anti Aliasing method discussed in the SGX architecture guide is a PowerVR specific optimization that benefits from the TBDR architecture’s use of tiling.
yes, you are right, we are using one of the products in SGX Series5, it is not easy for everyone to use the private communication channel and think this forum is also an effective way to discuss public questions.
To be frankly speaking, do not see you "was still intending to answer the topics" i've posted, there are still public questions un-answered.
In ragards to the original question on this topic, the two paragraphs I extracted from the two documents obviously show that they are conflict, not understand why they are still completely confromant.
Hi yjguo,
Let me try to address some of your concerns:
If there is trouble with the official communication setup for you then this is obviously something that needs to be fixed. Communicating through this channel means that your questions can be answered within context and in the knowledge that suitable NDAs etc. are in place between our companies. It is important that this works and if it isn’t then please tell us why. This forum is not the appropriate place for such discussion so please send messages through the devtech@imgtec.com address in preference to posting further on this forum.
Using the official channel will allow us to be more helpful and answer more freely.
I am afraid that some of your questions, although asked about public documents, do require answers that Imagination consider non-public information or very close to non-public information. We have no knowledge of who you are or what company you are affiliated with and also who may read responses in this forum in the future so please understand that, as an IP company, we must be very careful about our own and our customers’ confidential information.
Also, please note that this forum is contributed to by working engineers who only have a certain amount of time and remit to answer questions and, particularly once these threads began approaching confidential material, it is difficult for them to respond as quickly or as freely as for straight-forward public domain information. This is another reason to use the official channels provided for licencees so that your queries can be answered in context and prioritised.
As Joe has already said, the questions that you have already asked will be answered to the level that does not risk exposing confidential information, in due course. For further enquiries, please use the official channels or email us directly.
This topic is now locked
In answer to your question:
Imagination’s implementation of OpenGL/OpenGL ES has passed the conformance tests required of it to be fully conformant according to Khronos’ specifications. It is worth noting that the implementation of these API specifications is down to the vendor and in some cases the way a vendor solves a particular requirement of the specification may be different than the model described by Khronos. An example of this is when and how depth testing or hidden surface removal is carried out in modern graphics cores - no modern implementation does this entirely after fragment resolution, as the OpenGL spec suggests, but all attempt to eliminate obscured fragments earlier in the pipeline (with greater or lesser efficiency).
A conformant solution, such as PowerVR, does not produce different output for the same input than the spec requires, but how it processes that input (and the speed it performs it at) varies between solutions.
This is how the paragraphs you have found may appear to be contradictory, but can still be correct.
