On Wed, Sep 24, 2014 at 3:57 PM, Dave Airlie wrote:
> On 25 September 2014 08:51, Ian Romanick wrote:
>> On 09/24/2014 12:52 PM, Eric Anholt wrote:
>>> Roland Scheidegger writes:
>>>
Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these
to util code. That plus the thi
On 25 September 2014 08:51, Ian Romanick wrote:
> On 09/24/2014 12:52 PM, Eric Anholt wrote:
>> Roland Scheidegger writes:
>>
>>> Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these
>>> to util code. That plus the things I already mentioned should be all
>>> needed I think. Bu
On 09/24/2014 12:52 PM, Eric Anholt wrote:
> Roland Scheidegger writes:
>
>> Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these
>> to util code. That plus the things I already mentioned should be all
>> needed I think. But I strongly believe either this needs to be done or
>>
Am 24.09.2014 21:52, schrieb Eric Anholt:
> Roland Scheidegger writes:
>
>> Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these
>> to util code. That plus the things I already mentioned should be all
>> needed I think. But I strongly believe either this needs to be done or
>>
On Wed, Sep 24, 2014 at 12:52 PM, Eric Anholt wrote:
> Roland Scheidegger writes:
>
>> Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these
>> to util code. That plus the things I already mentioned should be all
>> needed I think. But I strongly believe either this needs to be
Roland Scheidegger writes:
> Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these
> to util code. That plus the things I already mentioned should be all
> needed I think. But I strongly believe either this needs to be done or
> we should revert it.
What's the actual problem be
Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these
to util code. That plus the things I already mentioned should be all
needed I think. But I strongly believe either this needs to be done or
we should revert it.
Roland
Am 24.09.2014 00:44, schrieb Roland Scheidegger:
> Actual
Actually I would definitely NAK this in the current state if it weren't
too late.
We cannot let mesa includes creep in there as that defeats the purpose
of the independent util code completely.
I did a quick look and it seems the only include it really needs from
mesa is bitset, which could be mov
I just pushed a quick fix to get things compiling again. I'm wondering
about that dependency too though.
-Brian
On 09/23/2014 04:26 PM, Roland Scheidegger wrote:
This change seems to cause compile failure with scons:
Compiling src/util/register_allocate.c ...
src/util/register_allocate.c:
This change seems to cause compile failure with scons:
Compiling src/util/register_allocate.c ...
src/util/register_allocate.c:76:26: fatal error: main/imports.h: No such
file or directory
#include "main/imports.h"
Looks like it could be fixed by patching up the CPPPATH in the
SConscript file
On 23/09/14 01:32, Eric Anholt wrote:
> The r300 gallium driver is using it outside of the Mesa tree, and I wanted
> to do so for vc4 as well. Rather than make the multiple-definitions
> problem even more complicated, just move it to more-shared code.
> ---
> src/gallium/drivers/r300/Makefile.am
r300 has a symlink to the code:
./src/gallium/drivers/r300/register_allocate.c
With that removed as well,
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
The r300 gallium driver is using it outside of the Mesa tree, and I wanted
to do so for vc4 as well. Rather than make the multiple-definitions
problem even more complicated, just move it to more-shared code.
---
src/gallium/drivers/r300/Makefile.am | 14 +-
src/gallium/drivers/r300
13 matches
Mail list logo
