On Thu, Oct 29, 2015 at 12:32 AM, Iago Toral wrote:
> On Wed, 2015-10-28 at 10:58 -0700, Kristian Høgsberg wrote:
>> On Wed, Oct 28, 2015 at 10:01:40AM +0100, Samuel Iglesias Gonsálvez wrote:
>> > There is no opinions about this issue or reviews of the proposed patch
>> > after one week.
>> >
>> >
On Wed, 2015-10-28 at 10:58 -0700, Kristian Høgsberg wrote:
> On Wed, Oct 28, 2015 at 10:01:40AM +0100, Samuel Iglesias Gonsálvez wrote:
> > There is no opinions about this issue or reviews of the proposed patch
> > after one week.
> >
> > This is just a reminder in case you have missed it :-)
>
On Wed, Oct 28, 2015 at 10:01:40AM +0100, Samuel Iglesias Gonsálvez wrote:
> There is no opinions about this issue or reviews of the proposed patch
> after one week.
>
> This is just a reminder in case you have missed it :-)
Thanks for the reminder! How about something like this instead?
diff --
There is no opinions about this issue or reviews of the proposed patch
after one week.
This is just a reminder in case you have missed it :-)
Sam
On 21/10/15 12:23, Iago Toral wrote:
> Hi,
>
> The problem is with code like this (see brw_send_indirect_message):
>
> setup = brw_OR(p, addr, desc,
Hi,
The problem is with code like this (see brw_send_indirect_message):
setup = brw_OR(p, addr, desc, brw_imm_ud(0));
send = next_insn(p, BRW_OPCODE_SEND);
...
return setup;
If next_insn triggers a realloc of the instruction store, then the setup
instruction pointer is no longer valid. Notice th
Hello,
I have found several invalid memory accesses when running
dEQP-GLES31.functional.ssbo.* tests on i965 driver (and gen7+). That
invalid memory accesses were unluckily happening when generating the
assembly instructions for SSBO stores for different compute shaders.
However it looks like thi