On Mon, 2009-08-31 at 07:37 -0700, Brian Paul wrote: > Eric Anholt wrote: > > On Sat, 2009-08-29 at 11:24 -0700, Jose Fonseca wrote: > >> Eric, > >> > >> This change broke softpipe on master (eg. terrain), and probably all > >> gallium based drivers. I'm pretty sure the vbo module was working > >> correctly without it, so there might be a different in the interpretation > >> of the MapBufferRange semantics between the drivers, but I couldn't find > >> it just by llooking at intel's and mesa state tracker implementation of > >> MapBufferRange. > >> > >> Was there any particular bug this change fixed? > > > > Yes, garbage was drawn all over the screen when enabling VBOs in the VBO > > module. obj->Pointer should pretty clearly be the pointer to the mapped > > range, as if you're creating a temporary space (system memory or > > temporary buffer object) as part of MapRange, where else would it point > > -- to an unmapped address? It also then matches the > > ARB_map_buffer_range semantics.
Fair enough. > Looks like a quick fix in > > st_bufferobj_map_range. > > I'll check in a fix for this shortly... Thanks. I should also change pipe_screen::buffer_flush_mapped_range semantics to do the same. Even if Gallium allows simultaneous mappings of the same buffer, it is better to have the same semantics everywhere. Weird, I never received Eric's email, just Brian's reply. Was it just me? Jose ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
