[Mesa-dev] Janitorial work: no more intel_context.[ch]; tidying

Kenneth Graunke kenneth at whitecape.org
Mon Sep 30 22:21:32 PDT 2013


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.

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

> Thanks
> Emil


More information about the mesa-dev mailing list