On Tue, Nov 26, 2013 at 9:24 PM, Volkin, Bradley D <[email protected]> wrote:
[snip] > Which "state setup stuff" are you referring to? Something specific in i-g-t > or something > more general? The state setup 3D commands as opposed to doing actual rendering commands (with 3D_PRIM). Just to have a bit more realistic cs opcode lengths for micro-benchmarking. [snip] > Ok, I'll look at the hw context code for buffer mgmt. For "purgeable", just > via the > madv field in the i915 gem object? Yeah, though I'd extract two tiny helpers (maybe shared with the madvise ioctl) to set an object to purgeable and then resurrect it. The later can obviously fail. The helpers are just so we have a place to throw debug asserts into, maybe there are other needs for in-kernel caches. > Also, there are a couple iterations of the work-in-progress patches. Do you > prefer a > cache per ring or a single cache shared by all rings? I've pondered a bunch of reasons for/against the two approaches and I think it won't really matter. Maybe slightly leaning towards per-ring caches since then objects retire in order. Well, until we do preemption ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
