Dave Airlie wrote: > >> On Monday, October 8, 2007 10:13 am Keith Whitwell wrote: >>> Neither 42 nor 256 are very good - the number needs to be dynamic. >>> Think about situations where an app has eg. one glyph per texture and >>> is doing font rendering... Or any reasonably complex game might use >>>> 256 textures in a frame. >> >> So maybe the buffer count should be part of the execbuffer request >> object? Or does it have to be a separate settable parameter? > > I would think the kernel needs to limit this in some way... as otherwise > we are trusting a userspace number and allocating memory according to it... > > So I'll make it dynamic but I'll have to add a kernel limit.. > > keithw: btws poulsbo uses 256 I think also..
Yes but I suspect we'll need to increase or make it dynamic before we're done. As with most hard limits, you can work around it by flushing prematurely, but there is a cost to that, one way or another. Keith ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
