>I'd have to think about it harder but even those are not likely to actually
>get ASTC decode. Maybe for some sort of decompression thing but if you're
>doing
> GetCompressedTexImage, it'll probably turn into a blorp_copy which will use
> R32G32B32A32_UINT.
I am thinking for the case where a
On Tue, Dec 5, 2017 at 10:34 AM, Rogovin, Kevin
wrote:
> Hi,
>
> >This isn't true. 100% of the intel_mipmap_tree -> blorp_surf
> translations are handled by that function.
> > It's a perfectly reasonable place to handle these things. It could
> also be handled in genX(blorp_exec) if that makes
Hi,
>This isn't true. 100% of the intel_mipmap_tree -> blorp_surf translations are
>handled by that function.
> It's a perfectly reasonable place to handle these things. It could also be
> handled in genX(blorp_exec) if that makes someone more comfortable.
This is where I placed the ASTC en
> Are you saying that this bug extends over hardware context?
Different HW contexts imply different execbuffer2 ioctl's. The kernel inserts a
full blown flush of everything after (or before, I cannot remember) each
execbuffer2 call. This way there is context isolation in HW buggineness.
-Kevin
On Tue, Dec 5, 2017 at 10:17 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Tue, Dec 05, 2017 at 10:26:33AM +, Rogovin, Kevin wrote:
> > Hi,
> >
> >
> > >> Here are my comments of the patch posted:
> > >>
> > >> 1. it is essentially replication and moving around of the code
On Tue, Dec 05, 2017 at 10:26:33AM +, Rogovin, Kevin wrote:
> Hi,
>
>
> >> Here are my comments of the patch posted:
> >>
> >> 1. it is essentially replication and moving around of the code of the
> >> patch series posted earlier but missing various
> >> important bits: preventing t
> If you take a look at brw_update_texture_surface(), just in the end before
> brw_emit_surface_state() the logic explictly consults for
> intel_miptree_texture_aux_usage().
> This in turn tells if the auxiliary buffer is resolved and it doesn't need to
> be programmed.
The full stack trace is
On Tue, Dec 05, 2017 at 01:00:28PM +0200, Pohjolainen, Topi wrote:
> On Tue, Dec 05, 2017 at 10:26:33AM +, Rogovin, Kevin wrote:
> > Hi,
> >
> >
> > >> Here are my comments of the patch posted:
> > >>
> > >> 1. it is essentially replication and moving around of the code of the
> > >> patc
On Tue, Dec 05, 2017 at 10:26:33AM +, Rogovin, Kevin wrote:
> Hi,
>
>
> >> Here are my comments of the patch posted:
> >>
> >> 1. it is essentially replication and moving around of the code of the
> >> patch series posted earlier but missing various
> >> important bits: preventing t
Hi,
>> Here are my comments of the patch posted:
>>
>> 1. it is essentially replication and moving around of the code of the
>> patch series posted earlier but missing various
>> important bits: preventing the sampler from using the auxiliary buffer
>> (this requires to modify surface
On Tue, Dec 05, 2017 at 05:41:56AM +, Rogovin, Kevin wrote:
> Hi,
>
> The patch series I have submitted handles the case of needing to resolve
> texture surfaces when a draw (or compute) accesses a texture which is
> astc5x5. As it is quite clear you understand the issue and know the code o
Hi,
The patch series I have submitted handles the case of needing to resolve
texture surfaces when a draw (or compute) accesses a texture which is astc5x5.
As it is quite clear you understand the issue and know the code of i965 the
patch centers on, you are an excellent person to review the co
This is just drafting some thoughts and only compile tested.
CC: "Rogovin, Kevin"
---
src/mesa/drivers/dri/i965/brw_blorp.c | 8 +
src/mesa/drivers/dri/i965/brw_context.h | 10 ++
src/mesa/drivers/dri/i965/brw_draw.c| 54 -
3 files changed, 71 inser
13 matches
Mail list logo
