Hi, I am currently working with a team that is porting the Intel Linux open source stack to Integrity OS (a real-time OS by Green Hills) for embedded systems. The current architecture we're using is the Sandybridge architecture (device ID: 0x0116). After a good amount of work, we have finally made it possible to run the Mesa (7.11.2)/X Server (1.10.4)/DRM (kernel version 3.1)/xf86-video-intel (2.17.0) on our system, but we are running into some issues with rendering. In particular when running Xclock or a simple GL application consisting of a full screen rotating triangle, we've found that either the blit and render rings seem to hang. To determine this, we read the ring buffer's head/tail pointer for each ring. From looking at the current instruction based on the head pointer, the previous instruction that has yet to complete in each case is a batch buffer. However if I look at the batch buffer address register 2140h, it seems like the batch buffer has started running into instructions that are not ours. On further decoding of the dispatched batch buffer, I can see the MI_BATCH_BUFFER_END instruction well before the current batch buffer instruction address. Is there any ways to determine why the batch/ring buffer are stuck at these instructions? One of the key differences between the Linux driver and our own is that we cannot support the page fault mechanism as is used by the DRM currently. To deal with this we have changed all gem object creations to essentially force a call to the page fault handler in order to guarantee things are allocated before being used. Any help on this issue would be greatly appreciated. If there are any particular registers that we can look at or submit please let me know. Thanks, Matt -- Matt Knowles Software Developer | Presagis T. +1 781 852.0202 X2096 F. +1 781 203.0110 CONFIDENTIALITY NOTICE: This e-mail message is intended only for the above named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you have received this message in error or are not the named recipient(s), please immediately notify the sender, delete this e-mail message without making a copy and do not disclose or relay this e-mail message to anyone. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20130116/ec2a504c/attachment.html>
