Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Paul wrote: > | Brian Paul wrote: > |> On 2/21/08, Ian Romanick <[EMAIL PROTECTED]> wrote: > |>> -----BEGIN PGP SIGNED MESSAGE----- > |>> Hash: SHA1 > |>> > |>> Brian Paul wrote: > |>> | Ian Romanick wrote: > |>> > |>> |> Suggestions? > |>> | > |>> | demos/texcyl.c is the one texturing test that pretty much works as > |>> | expected. Use the right mouse button for the options menu. > |>> > |>> > |>> Unfortunately texcyl, renormal, and possibly others die with > |>> "cmd_batch(): assertion 0 failed." Somehow a 0 command is sneaking > in. > |>> ~ I've been trying to debug it, but I can't see what's happening > |>> different for renormal than, say, gears. Ugh. :( > |> Hmmm, those programs were working fine for me the other day. I'll try > |> to test tomorrow or over the weekend. > | > | I just updated everything, fixed some build breakage, and the above > | tests run OK here now. > > > I managed to track down the problem. cell_start_spus is being called > multiple times. Each time it is called the SPUs expect the buffers to > be stored in a different location. However, when the batch data is > later sent to the SPUs, the addresses for one of the earlier invocations > of cell_start_spus is used. The buffer the SPUs actually look at is > empty, and 'cmd_batch(): assertion 0 failed.' results. > > I added a printf to cell_start_spus. I've attached the GDB output with > backtraces at each call to cell_start_spus. > > It seems to me that the state tied to the SPUs should be treated as a > singleton. cell_start_spus should only be called once, and later calls > to cell_create_context should use the same singleton data. If this > approach seems correct, I'll start working on it tomorrow.
Looks like you're using freeglut. One way freeglut is different from Kilgard's GLUT (the one included with Mesa) is freeglut uses GL calls to display pop-up menus, rather than Xlib/Win32. So it's creating an extra rendering context for menus. I usually don't use freeglut. I haven't really given much thought to how we'll deal with multiple contexts in the Cell driver. My first take on it is to view the SPUs as if it were a GPU with a single HW rendering context. So per-SPU data would be singleton and switching GL contexts should totally overwrite the SPU data. If we want to be threadsafe I guess we'll need a lock and an arbitration mechanism, but I think we could put that off for now. I think we're close to this with the 'cell_global' data. Feel free to implement what you think is best for the time being. -Brian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
