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
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,
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
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