On Fri, Oct 23, 2015 at 5:38 AM, Francisco Jerez wrote:
> Kristian Høgsberg writes:
>
>> On Tue, Oct 20, 2015 at 11:56 AM, Francisco Jerez
>> wrote:
>>> Kristian Høgsberg writes:
>>>
On Tue, Oct 20, 2015 at 3:16 AM, Francisco Jerez
wrote:
> Kristian Høgsberg writes:
>
Kristian Høgsberg writes:
> On Tue, Oct 20, 2015 at 11:56 AM, Francisco Jerez
> wrote:
>> Kristian Høgsberg writes:
>>
>>> On Tue, Oct 20, 2015 at 3:16 AM, Francisco Jerez
>>> wrote:
Kristian Høgsberg writes:
> On Mon, Oct 19, 2015 at 4:19 AM, Francisco Jerez
> wrote:
>>
On Tue, Oct 20, 2015 at 11:56 AM, Francisco Jerez wrote:
> Kristian Høgsberg writes:
>
>> On Tue, Oct 20, 2015 at 3:16 AM, Francisco Jerez
>> wrote:
>>> Kristian Høgsberg writes:
>>>
On Mon, Oct 19, 2015 at 4:19 AM, Francisco Jerez
wrote:
> Neil Roberts writes:
>
>> Ju
Kristian Høgsberg writes:
> On Tue, Oct 20, 2015 at 3:16 AM, Francisco Jerez
> wrote:
>> Kristian Høgsberg writes:
>>
>>> On Mon, Oct 19, 2015 at 4:19 AM, Francisco Jerez
>>> wrote:
Neil Roberts writes:
> Just a thought, would it be better to move this check into the
> eli
On Tue, Oct 20, 2015 at 3:16 AM, Francisco Jerez wrote:
> Kristian Høgsberg writes:
>
>> On Mon, Oct 19, 2015 at 4:19 AM, Francisco Jerez
>> wrote:
>>> Neil Roberts writes:
>>>
Just a thought, would it be better to move this check into the
eliminate_find_live_channel optimisation? Th
Kristian Høgsberg writes:
> On Mon, Oct 19, 2015 at 4:19 AM, Francisco Jerez
> wrote:
>> Neil Roberts writes:
>>
>>> Just a thought, would it be better to move this check into the
>>> eliminate_find_live_channel optimisation? That way it could catch
>>> sources that become immediates through l
I wrote a similar patch a while back because I was annoyed by how this
was causing the send disassembly to not be as nice. :) I dropped it
from my branch at some point, but I still think it is a good idea.
Reviewed-by: Jordan Justen
On 2015-10-18 21:31:43, Kristian Høgsberg Kristensen wrote:
> A
On Mon, Oct 19, 2015 at 4:19 AM, Francisco Jerez wrote:
> Neil Roberts writes:
>
>> Just a thought, would it be better to move this check into the
>> eliminate_find_live_channel optimisation? That way it could catch
>> sources that become immediates through later optimisations. One problem
>> wit
Neil Roberts writes:
> Just a thought, would it be better to move this check into the
> eliminate_find_live_channel optimisation? That way it could catch
> sources that become immediates through later optimisations. One problem
> with this that I've seen before is that eliminating the
> FIND_LIVE
Just a thought, would it be better to move this check into the
eliminate_find_live_channel optimisation? That way it could catch
sources that become immediates through later optimisations. One problem
with this that I've seen before is that eliminating the
FIND_LIVE_CHANNEL doesn't cause the subseq
On Sun, 2015-10-18 at 21:31 -0700, Kristian Høgsberg Kristensen wrote:
> An immdiate is already uniform so just return it up front. Without this,
> brw_fs_surface_builder ends up passing immediate surface indices through
> SHADER_OPCODE_BROADCAST. This writes to a stride 0 dst, which we can't
> con
An immdiate is already uniform so just return it up front. Without this,
brw_fs_surface_builder ends up passing immediate surface indices through
SHADER_OPCODE_BROADCAST. This writes to a stride 0 dst, which we can't
constant propagate out of, and further, we don't constant propagate into
the typed
12 matches
Mail list logo
