> As discussed on irc this contains a (not yet fully tuned and also not yet > in granting mode) cmd parser for gen7. Performance is still a bit rough, > but not quite as bad as originally feared (Ken later on discovered that he > also changed something in his glamour setup which made things worse). If > it doesn't get better (and ofc if we don't get all the missing bits in for > granting mode) I'll disable it before 3.16 again. But I want to give this > beast as much testing as possible for now to avoid ugly regressions once > we switch it on. > > Also please don't use the autogenerate merge commit since that'll miss the > stuff from the 1st drm-intel-next tag. > > If I read the merges in -nightly correctly there's a bit a conflict in > i915_gem_context.c. I can provide an example merge if you want (or > otherwise just peak at linux-next or drm-intel-nightly). > Merged, but 32-bit still a thing, CC [M] drivers/gpu/drm/i915/i915_cmd_parser.o /ssd/git/drm-next/drivers/gpu/drm/i915/i915_cmd_parser.c: In function ‘i915_parse_cmds’: /ssd/git/drm-next/drivers/gpu/drm/i915/i915_cmd_parser.c:919:4: warning: format ‘%td’ expects argument of type ‘ptrdiff_t’, but argument 5 has type ‘long unsigned int’ [-Wformat=] DRM_DEBUG_DRIVER("CMD: Command length exceeds batch length: 0x%08X length=%u batchlen=%td\n", ^ Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel