Re: [Intel-gfx] [PATCH 05/14] drm/i915: kill ranged cpu read domain support
On Thu, Feb 16, 2012 at 03:52:46PM -0800, Eric Anholt wrote: On Thu, 16 Feb 2012 18:38:08 +0100, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Feb 16, 2012 at 08:48:07AM -0800, Eric Anholt wrote: On Thu, 16 Feb 2012 13:11:31 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: No longer needed. What this code was for: Before gtt mapping, we were doing software fallbacks in Mesa with pread/write on pages at a time (or worse) of the framebuffer. It would regularly result in hitting the same page again, since I was only caching the last page I'd pulled out, instead of keeping a whole copy of the framebuffer during the fallback. Urgh, that's not really efficient ;-) I think for s/w fallbacks and readbacks we can presume decent damage tracking (like sna does) on the userspace sides. Since we've been doing gtt mapping for years at this point, I'm happy to see the code die. I'm not sure about the rest of the code. In particular, for the code that's switching between gtt and cpu mappings to handle a read/write, I'm concerned about whether the behavior matches for tiled objects. I haven't reviewed enough to be sure. Behaviour should match old code if you read/write entire pages (we should have decent set of tests for that). If you do non-cacheline-aligned reads/writes on tiled objects, we might hit an issue, but they should be solveable (I've simply been too lazy to write testcases for this). Not cacheline aligned reads/writes on untiled also work, I've created a set of tests to exercise issues there (and tested the tests by omitting some of the clflushes, i.e. all the clfushes now left _are_ required). If old mesa depends on sub-page reads/writes to tiled objects I need to create the respective tests and double-check the code, otherwise I think we're covered. Do you want me to adapt the tests to check correctness for sub-page reads/writes to tiled objects? In the long long ago, I believe we did per-pixel accesses of tiled objects through pread/pwrite. Crazy, I know. Ok, I'll create a new tests to check partial, unaligned pwrites/preads on tiled objects. On re-reading the patches the thing I'll likely got wrong is that I don't swizzle the clflushing. But if we need to swizzle a page we go through the slow-path anyway (no point in adding optimized code for something no one cares about perf-wise anymore), so there shouldn't be any issues with adding another branch to fix up the flushing. Won't be fast though, but I guess no one cares ;-) Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] updated -next
On Thu, 16 Feb 2012 18:27:44 +0100 Daniel Vetter dan...@ffwll.ch wrote: Hi all, Updated -next and -testing trees. I haven't merged in any of the patches Jesse queued up because he hasn't yet pushed out his latest -fixes tree. No cookies for Jesse today! wtf I swear I pushed that branch, I even pushed updates to it. I wonder where those pushes have been going... Looks like the branch is there now, I must have pushed to a bogus ref. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/11] drm/i915/context: extend contexts to execbuffer2
On Wed, 15 Feb 2012 21:00:16 +0100 Ben Widawsky b...@bwidawsk.net wrote: On Wed, 15 Feb 2012 11:55:56 -0800 Eric Anholt e...@anholt.net wrote: On Tue, 14 Feb 2012 22:09:15 +0100, Ben Widawsky b...@bwidawsk.net wrote: Extend the flag parameter to support the context id (from the create IOCTL) so that userspace can associate a context with the batchbuffer. Signed-off-by: Ben Widawsky b...@bwidawsk.net /** Resets the SO write offset registers for transform feedback on gen7. */ #define I915_EXEC_GEN7_SOL_RESET (18) +#define I915_EXEC_CONTEXT_MASK (((122)-1) 9) Instead of stuffing a context id into a subset of flags, could we just use a uint32_t context id in half of rsvd1? Yeah, having over 1 22 contexts is crazy, but this just seems to eat up all the rest of the flags for no reason and then we'll have to carve out of rsvd1 for the next flag. Sure. I didn't know if rsvd fields were allowed to be used, and I was too lazy to check libdrm history to see if they'd always been zero'd out. So yes, I will update this. Yeah it's ok to use them. We added them for just this purpose iirc, and even tried to make sure we could use them in the future by making sure old (then current) userspace zeroed them out. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] SNB/IVB sprite demo
Yeah, I got lazy and just did a diff. Sorry about that ... Here is a real git patch made by git diff sprite_on.c Thanks have a good weekend, Armin -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Saturday, February 11, 2012 2:53 AM To: Reese, Armin C Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] SNB/IVB sprite demo Hi Armin, On Sat, Feb 11, 2012 at 01:11:16AM +, Reese, Armin C wrote: Thanks for letting me know about the GCC warning messages. I did my final tweeks on the program in Android and compiled in that environment. The compiler there is a bit blind and the build jobs generate so much output, it's easy to ignore warnings. Np. Btw I've just merged the Android build patches for i-g-t in case that's useful for you. Anyway, I'll be more careful next time. The GCC compiler on my Ubuntu 11.04 system is version 4.5.2. I haven't installed 4.6.2 yet. GCC produced no warnings after the patch was applied. I attached both the patch and the new source code for sprite_on.c. Thanks, patch looks nice. Can I have it as a git patch? That's much esier to handle than your patch which contains funny paths into your own home directory ;-) /me is a lazy bastard Thanks for taking time for this. I intend on adding color key support into sprite_on.c to validate operation of that feature, so there will be more patches coming. Awesome, but I that case if more stuff is to show up, I _really_ prefer git patches. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 sprite_on_patch Description: sprite_on_patch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
