On 14.09.2017 15:14, Marek Olšák wrote:
On Thu, Sep 14, 2017 at 12:31 PM, Timothy Arceri wrote:
On 31/08/17 01:55, Marek Olšák wrote:
On Wed, Aug 30, 2017 at 2:22 PM, Timothy Arceri
wrote:
On 30/08/17 20:07, Marek Olšák wrote:
If LLVM was fixed to do the correct thing, we could enable
On Thu, Sep 14, 2017 at 12:31 PM, Timothy Arceri wrote:
>
>
> On 31/08/17 01:55, Marek Olšák wrote:
>>
>> On Wed, Aug 30, 2017 at 2:22 PM, Timothy Arceri
>> wrote:
>>>
>>> On 30/08/17 20:07, Marek Olšák wrote:
If LLVM was fixed to do the correct thing, we could enable CONSTBUF
On 31/08/17 01:55, Marek Olšák wrote:
On Wed, Aug 30, 2017 at 2:22 PM, Timothy Arceri wrote:
On 30/08/17 20:07, Marek Olšák wrote:
If LLVM was fixed to do the correct thing, we could enable CONSTBUF
LOAD for LLVM 6.0 and later.
You seem to think that the compiler *should* be placing them
On Wed, Aug 30, 2017 at 2:22 PM, Timothy Arceri wrote:
> On 30/08/17 20:07, Marek Olšák wrote:
>>
>> If LLVM was fixed to do the correct thing, we could enable CONSTBUF
>> LOAD for LLVM 6.0 and later.
>
>
> You seem to think that the compiler *should* be placing them near where they
> are used? Wh
On 30/08/17 20:07, Marek Olšák wrote:
If LLVM was fixed to do the correct thing, we could enable CONSTBUF
LOAD for LLVM 6.0 and later.
You seem to think that the compiler *should* be placing them near where
they are used? What part of LLVM were you expecting to do this? I'm
happy to do some d
If LLVM was fixed to do the correct thing, we could enable CONSTBUF
LOAD for LLVM 6.0 and later.
Marek
On Wed, Aug 30, 2017 at 9:18 AM, Timothy Arceri wrote:
> On 30/08/17 10:25, Marek Olšák wrote:
>>
>> I have to conclude that I don't see a way to use LOAD with CONSTBUF
>> and keep the same per
On 30/08/17 10:25, Marek Olšák wrote:
I have to conclude that I don't see a way to use LOAD with CONSTBUF
and keep the same performance as before. It looks like there are some
deficiencies in our compiler stack that are unfixable in Mesa alone.
Well that's frustrating :( Pretty much makes finis
I have to conclude that I don't see a way to use LOAD with CONSTBUF
and keep the same performance as before. It looks like there are some
deficiencies in our compiler stack that are unfixable in Mesa alone.
Marek
On Wed, Aug 30, 2017 at 2:11 AM, Marek Olšák wrote:
> Related IRC discussion:
>
> 0
Related IRC discussion:
00:01 < mareko> arsenm: what are the chances I can convince you to
allow me to set mayLoad = 0 on s_buffer_load_dword? :) the instruction
always reads from read-only memory with Mesa
00:02 < mareko> apparently, readnone doesn't get through
00:02 < arsenm> mareko: you should
Interesting. It may be that glsl_to_tgsi uses copy propagation to fold
those CONST loads into operands, which puts them next to their uses in LLVM.
I guess LLVM doesn't understand that s_buffer_load_dword loads from
immutable dereferenceable memory. It would benefit from mayLoad = 0 in
this case I
On 24/08/17 18:12, Nicolai Hähnle wrote:
On 24.08.2017 09:45, Timothy Arceri wrote:
On 22/08/17 22:14, Timothy Arceri wrote:
I'm a little unsure what to do with this now. Below is my shader-db
results, the majority of negative changes are from Natural Selection
2.
I looked at some dumps of
On 24.08.2017 09:45, Timothy Arceri wrote:
On 22/08/17 22:14, Timothy Arceri wrote:
I'm a little unsure what to do with this now. Below is my shader-db
results, the majority of negative changes are from Natural Selection
2.
I looked at some dumps of the worst Natural Selection 2 shaders and
i
On 22/08/17 22:14, Timothy Arceri wrote:
I'm a little unsure what to do with this now. Below is my shader-db
results, the majority of negative changes are from Natural Selection
2.
I looked at some dumps of the worst Natural Selection 2 shaders and
it seems to just be scheduling differences ca
I'm a little unsure what to do with this now. Below is my shader-db
results, the majority of negative changes are from Natural Selection
2.
I looked at some dumps of the worst Natural Selection 2 shaders and
it seems to just be scheduling differences causing the regressions.
I tested with sisched
14 matches
Mail list logo
