Christian Neumair wrote: > 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.
Right. The driDrawPriv->driverPrivate field is initialized to point to a GLframebuffer in the radeonCreateBuffer() function. > 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. I'm not sure I understand all that. In any case... > 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 *). The __DRIDrawablePrivateRec (see dri_util.h) is the structure that generally has all the DRI-related fields. Its driverPrivate field points to a GLframebuffer in most (all?) of the drivers. This is slightly different that the context data structures. The __DRIContextPrivateRec has DRI-related per-context fields. The driverPrivate field in that struct (unlike for drawables) points to a driver-specific context object, like struct radeon_context. The radeon_context, in turn, points to a Mesa GLcontext. So far, we usually haven't needed a special driver-specific structure to represent windows/drawables because the __DRIdrawablePrivateRec and GLframebuffer types provide everything that's needed. The piece which you might be looking for is a pointer from the GLframebuffer back to the corresponding/parent __DRIDrawablePrivateRec. Is that true? So far, we've gotten by without that. > 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. It sounds like radeonCreateBuffer() isn't getting called. That's where the __DRIDrawablePrivate->driverPrivate field gets initialized to point to a GLframebuffer object. > 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. By time _mesa_make_current() is called, the GLframebuffers that are passed in should have already been initialized. That's an area that might be rough right now. > Maybe somebody could explain me the involved idea, and make suggestions > how we could resolve this? Did any of the above help? -Brian ------------------------------------------------------------------------- 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
