2011/5/5 Alex Deucher :
> 2011/5/5 Alex Deucher :
>> 2011/5/5 Mathias Fröhlich :
>>>
>>> Hi all,
>>>
>>> On Thursday, May 05, 2011 04:32:03 you wrote:
Okay my guess at the problem is that:
the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
on the base in the CB
2011/5/5 Alex Deucher :
> 2011/5/5 Mathias Fröhlich :
>>
>> Hi all,
>>
>> On Thursday, May 05, 2011 04:32:03 you wrote:
>>> Okay my guess at the problem is that:
>>>
>>> the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
>>> on the base in the CB being the same as the texture BASE
2011/5/5 Mathias Fröhlich :
>
> Hi all,
>
> On Thursday, May 05, 2011 04:32:03 you wrote:
>> Okay my guess at the problem is that:
>>
>> the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
>> on the base in the CB being the same as the texture BASE which it won't
>> be in the case
Hi all,
On Thursday, May 05, 2011 04:32:03 you wrote:
> Okay my guess at the problem is that:
>
> the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
> on the base in the CB being the same as the texture BASE which it won't
> be in the case where we are rendering to mip sublevel
2011/5/5 Dave Airlie :
>>> So to be honset I do not understand where the data sticks and what I need to
>>> do to get it out.
>>> May be that observations make sense for somebody else?
>>>
>>
>> I've been staring at this I'm running out of good ideas, and even bad ideas.
>>
>> It really does seem l
>> So to be honset I do not understand where the data sticks and what I need to
>> do to get it out.
>> May be that observations make sense for somebody else?
>>
>
> I've been staring at this I'm running out of good ideas, and even bad ideas.
>
> It really does seem like the TC has some invalid lin
2011/5/3 Mathias Fröhlich :
>
> Marek,
>
> On Tuesday, May 03, 2011 01:33:17 you wrote:
>> 2011/5/2 Mathias Fröhlich :
>> > I have again spent some more tries with different kinds of flushes on the
>> > rv635. What helps for the mipmap problem here is emitting a
>> > texture_barrier as well as flus
On Wed, May 4, 2011 at 5:05 AM, Fredrik Höglund wrote:
> On Monday 02 May 2011, Alex Deucher wrote:
>> One thing to double check is that rv6xx_context_surface_base_update()
>> gets emitted properly every time a base address is emitted. Right now
>> I think we only call it once per command buffer,
On Monday 02 May 2011, Alex Deucher wrote:
> One thing to double check is that rv6xx_context_surface_base_update()
> gets emitted properly every time a base address is emitted. Right now
> I think we only call it once per command buffer, but it needs to be
> emitted every time a base address chang
2011/5/3 Mathias Fröhlich :
>
> Marek,
>
> On Tuesday, May 03, 2011 01:33:17 you wrote:
>> 2011/5/2 Mathias Fröhlich :
>> > I have again spent some more tries with different kinds of flushes on the
>> > rv635. What helps for the mipmap problem here is emitting a
>> > texture_barrier as well as flus
2011/5/3 Mathias Fröhlich :
> Correct me when I am wrong:
> In u_gen_mipmap, we call cso_set_framebuffer, which I expect to be aequivalent
> to switching rendering outputs to a different fbo. When I do the aequivalent
> from OpenGL level, I expect to have everything available from the previous
> bo
Marek,
On Tuesday, May 03, 2011 01:33:17 you wrote:
> 2011/5/2 Mathias Fröhlich :
> > I have again spent some more tries with different kinds of flushes on the
> > rv635. What helps for the mipmap problem here is emitting a
> > texture_barrier as well as flushing anything that covers the whole
>
2011/5/2 Mathias Fröhlich :
> I have again spent some more tries with different kinds of flushes on the
> rv635.
> What helps for the mipmap problem here is emitting a texture_barrier as well
> as flushing anything that covers the whole memory range and more than two
> arbitrary color buffers. !?!
On 05/02/11 22:20, Mathias Fröhlich wrote:
> Hi,
>
> On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote:
>>> So, I know that this patch is not applicable, since it does not account
>>> for sufficient cs space for this additional flush. Also it is probably
>>> too croase in face of the fineg
2011/5/2 Mathias Fröhlich :
>
> Hi,
>
> On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote:
>> > So, I know that this patch is not applicable, since it does not account
>> > for sufficient cs space for this additional flush. Also it is probably
>> > too croase in face of the finegrained bo
Hi,
On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote:
> > So, I know that this patch is not applicable, since it does not account
> > for sufficient cs space for this additional flush. Also it is probably
> > too croase in face of the finegrained bo flush logic.
>
> Actually I think it
On Saturday 30 April 2011, Gustaw Smolarczyk wrote:
> I can confirm this breakage on rv670 too. It may be related to all
> chips < RV710 (just a guess).
> The bug report:
> https://bugs.freedesktop.org/show_bug.cgi?id=35312
>
> I compile mesa with attached patch since then, but that flush should
>
On Saturday 30 April 2011, Mathias Fröhlich wrote:
> Hi,
>
> Since the lazy gpu flush changes for r600g about two weeks ago, I get broken
> mipmaps on my notebooks rv635.
> I am not sure if my analysis is right, but it appears to me that flushing the
> destination caches like it is done in r600_
I can confirm this breakage on rv670 too. It may be related to all
chips < RV710 (just a guess).
The bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=35312
I compile mesa with attached patch since then, but that flush should
indeed be implicit, not explicit.
2011/4/30 Mathias Fröhlich :
>
Hi,
Since the lazy gpu flush changes for r600g about two weeks ago, I get broken
mipmaps on my notebooks rv635.
I am not sure if my analysis is right, but it appears to me that flushing the
destination caches like it is done in r600_context_flush_dest_caches is not
sufficient for my rv635. Sin
20 matches
Mail list logo
