On Mon, Jan 20, 2014 at 09:32:11PM +0000, Hrustich, John wrote: > The compute memory pool used by the gallium r600 driver seems to be > problematic. The pool looks to be a single radeon buffer object. There > could be multiple maps set up into that single buffer object. If there is a > need to grow the pool, then the resource associated with the buffer object is > destroyed, which results in all of the maps for that buffer object also being > destroyed. When the new larger pool is created, the pointers that the > application has to the mapped region are no longer valid. > > A temporary work-around would appear to be to make sure that the buffer pool > is large enough that there isn't a need to grow the pool once any maps into > it are created. A longer term solution seems much harder. Even if the maps > could all be precisely recreated into the newly allocated buffer object, > there would be a period of time when the pointers held by the application > would be invalid. >
This is just one of the many problems with the compute memory pool. It would be good to have some piglit tests for the use case you described. I think the compute code in r600g has stabilized enough now that we could consider replacing the memory pool with something else. I'm open to suggestions if you have any ideas. -Tom _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
