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.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to