TeamForge : Post

Forum Topic - devg-extreme2 on 82852GM Intel integrated graphics device:

View: as

Mike Gorchak

03/30/2009 2:10 AM

post25507

devg-extreme2 on 82852GM Intel integrated graphics device

I noticed recently problem with devg-extreme2 stability while using on Intel 82852GM integrated graphics device on 
LexSystem CI852A embedded SBC (pci -vvv output is attached).

After 10-20 consecutive runs of apllication which uses OpenGL ES (egl-ph-gears or egl-gears, for example), application 
hangs with all graphics stuff, only net and keyboard still work. It could hang at gf_display_detach() or gf_dev_attach()
 function calls (maybe during hardware initialization), but in another time it could hang somwhere inside rendering.

Bug could be reproduced easily when you will run egl-ph-gears and will try to resize window size (maximize/restore). 
Sometimes 30-40 resizes is enough to hang graphics driver.

While using the same graphics driver devg-extreme2 on 82865G (desktop chipset) all work fine, without any lockups.

Attachment:

ci852a.txt.gz 2.66 KB

Michael Van Reenen

03/30/2009 2:10 PM

post25594

Re: devg-extreme2 on 82852GM Intel integrated graphics device

We've filed a PR for this issue on your behalf. (PR # 66876)

Mike Gorchak

03/31/2009 2:09 PM

post25709

Re: devg-extreme2 on 82852GM Intel integrated graphics device

Maybe this could help you, I think OpenGL ES gears demo for photon (gf-ph-3d) is bad example by design, it uses widget 
damage routine to draw OpenGL ES backbuffer in place of PtRaw widget in same time when some GL drawings are performing 
in the work_proc() routine.

Looks like 82852GM has an issue with simultaneous frame buffer access by 2D and by 3D engines, or has problem with 
hardware graphics pipe when executing mixed 2D and 3D commands without flushing after transition from 2D mode to 3D and 
vice versa. Since I added eglWaitGL() as first function of raw_draw_f() callback, there are no any lockups during last 
two hours. But this patch looks weak on multi-processor machines.

Misha Nefedov

03/31/2009 2:38 PM

post25710

Re: devg-extreme2 on 82852GM Intel integrated graphics device

Your analysis of what gf-ph-3d does is wrong. This application is not multi-threaded. The raw widget doesn’t render 3d 
scene – it merely copies the content of the 3d frame buffer to the current photon’s render context (which will take 
care of calculation what part of the window is actually visible and so on) when it is told to do so. It calls the 
PgWaitHWIdle() to make sure that the blit is actually done before the work_proc() will render the next frame. The 
work_proc() works when it has a chance, sequentially, not in parallel to the blit.

Etienne Belanger(deleted)

03/31/2009 3:24 PM

post25719

Re: devg-extreme2 on 82852GM Intel integrated graphics device

gf-ph-3d does all the right calls to ensure the presentation blits and 3D rendering are serialized. However, you may be 
right when you say that you nevertheless observe simultaneous buffer access by the 3D and 2D engines.

The problem is that eglWaitGL is stubbed out. I don't know why inserting it at different locations fixes your problem. 
It probably didn't; just changed the timing a little bit.

Pending the resolution of this issue, you should replace eglWaitGL with glFinish, or simply add a glFinish before 
eglWaitGL in your work_proc.

Mike Gorchak

04/01/2009 12:36 AM

post25726

Re: devg-extreme2 on 82852GM Intel integrated graphics device

> The problem is that eglWaitGL is stubbed out. I don't know why inserting it at
>  different locations fixes your problem. It probably didn't; just changed the 
> timing a little bit.

Thanks for the eglWaitGL() internals explanation :) Dunno why, but it really helps to avoid lockups in my application 
running on 82852GM. You are right, it adds some very small delays in code execution...

eglWaitNative() also does nothing ?

Etienne Belanger(deleted)

04/01/2009 8:32 AM

post25740

Re: devg-extreme2 on 82852GM Intel integrated graphics device

Unfortunately, eglWaitNative() also does nothing. You would have to add gf_draw_finish, or replace any gf_draw_flush 
with gf_draw_finish before gf_draw_end. However, that only covers for the rendering that you are doing...

The correct implementation would have to wait on all operations, including the ones from other processes. As far as I 
know, the GF API (our "native" API) doesn't have a wait idle function, which is why eglWaitNative can't do anything for 
now.

Nevertheless, in the gf-ph-3d example, I don't think this is an issue because the framework waits for operations to 
complete before calling the work_proc, so the call to eglWaitNative may not be necessary.

Return