[Intel-gfx] [PULL] drm-intel-next

Dave Airlie airlied at gmail.com
Thu May 1 01:26:50 CEST 2014


> 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.



More information about the Intel-gfx mailing list