[Mesa-dev] Janitorial work: no more intel_context.[ch]; tidying
vlee at freedesktop.org
Tue Oct 1 22:51:22 PDT 2013
On Mon, Sep 30, 2013 at 10:21 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 09/27/2013 06:24 PM, Emil Velikov wrote:
>> On 28/09/13 00:45, Kenneth Graunke wrote:
>>> This series combines brw_context.[ch] and intel_context.[ch],
>>> and cleans up our context creation code quite a bit. A bunch of
>>> functionality was awkwardly split between the two sets of files;
>>> now it's all in one place.
>>> While this series is large, it should be fairly easy reading.
>>> Patch 28 does have one functional change on 32-bit systems - it removes
>>> a handcoded assembly version of memcpy. This has not been tested.
>> Hi Kenneth
>> Hope you can bare with me and a couple of silly questions :)
>> * With the recent split of the intel driver codebase, the new i965
>> headers has been getting a bunch of #pragma once over the standard
>> #ifndef _HEADER_H_... Are those intentional ?
> Yup, that's intentional. "#pragma once" doesn't require inventing a
> unique #define name, is less typing, and is faster on some compilers.
> I actually forgot that it wasn't standard. It's supported basically
> everywhere, though, so I'd be really shocked if it caused problems.
Oracle Solaris Studio does not support "#pragma once".
>> * In patch 29 the drm* headers are included quoted, over angle brackets.
>> I realise that's a very pedantic point, just curious is it just a
>> copy'n'paste thing or was it planned.
> Not intentional - I actually just copied those #include lines from
> intel_context.h, just like they were before. But you're right, angle
> brackets make a lot more sense. I've updated the patch to use <drm.h>,
> <intel_bufmgr.h>, and <i915_drm.h>. Thanks!
>> * The inline function is_power_of_two() in patch 29 is used by both
>> intel drivers. Possibly move it to macros.h ? Gallium has it's
>> equivalent in auxiliary/util/u_math.h - util_is_power_of_two()
> That's not a bad idea; it'd at least share it between the classic
> drivers. It'd be nice to share a couple of these with Gallium, but I
> don't think we use the same includes for whatever reason.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev