Hello out there! I'm trying to do some hacking with EGL and an Radeon Mobility M300 card. With some hacking here and there, I got my card beyond eglInitialize() (yay!). Now that buffers are created I experienced a weird problem:
The radeon driver (and other non-ATI ones as well) seem to pass their private data pointer as a casted GLframebuffer * to _mesa_make_current, which (see below) sometimes is stored in the GLContext fields DrawBuffer and ReadBuffer. I'm not sure how this is supposed to work, but as the private structs aren't derived from GLframebuffer (at least the private radeonContextPtr passed as GLframebuffer *), this could mean that the framebuffer access functions are fully provided by the DRI driver and that it will the only one being aware of the actual GLframebuffer * contents (after casting it back into its private ptr). Nevertheless, the GLframebuffer * maps to struct gl_framebuffer, and is also accessed by the MESA code, which has another idea about the memory layout. So first of all, we have to clearly define whether this buffer is supposed to be accessed (also) by common MESA code, in which case we should possibly pack the private DRI private driver data somewhere at the end of a newly allocated GLframebuffer * (or derive the private struct from a GLframebuffer), or whether only the DRI driver is responsible for access to GLframebuffer data, in which case the GLcontext's DrawBuffer and BackBuffer should be transparent to the common code (i.e. void *). I don't understand the whole code layout, but a quick gdb analysis revealed that a crasher I experienced with progs/egl/demo1.c comes from radeonMakeCurrent(), and involves the said lack of a clear memory layout concept: The function calls _mesa_make_current(), which will (sometimes) compare the (garbaged) passed-in drawBuffer/readBuffer's fields with some of the context fields. Of course, since the drawBuffer/readBuffer contents is random, this will usually fail, and so the buffers are not set. Sometimes the call will then be followed by _mesa_set_viewport(), which instead will access the GLcontext *'s ctx->DrawBuffer->_DepthMaxF. Since the buffer wasn't set (and would be garbaled if it was set anyway), this results in a segfault or undefined behavior. Maybe somebody could explain me the involved idea, and make suggestions how we could resolve this? -- Christian Neumair <[EMAIL PROTECTED]> ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
