On Thu, Jul 24, 2014 at 8:07 PM, Alex Deucher wrote:
> On Thu, Jul 24, 2014 at 6:28 PM, wrote:
> > From: Jerome Glisse
> >
> > The ucode we got for hawaii does not support 0x1000 special nop
> > packet type 3 and this leads to gpu reading invalid memory. As pa
From: Jerome Glisse
The ucode we got for hawaii does not support 0x1000 special nop
packet type 3 and this leads to gpu reading invalid memory. As packet
type 2 still exist just use packet type 2.
Note this only partialy fix hawaii issues and some zbuffer tiling
issues are still present
On Thu, Jul 24, 2014 at 05:42:21PM -0400, j.gli...@gmail.com wrote:
> From: Jerome Glisse
>
> The gpu packet prefetcher hates the ugly big nop packet those leads
> to prefetching some invalid memory in some case. Apparently hawaii
> is particularly sensible to this.
>
> No
From: Jérôme Glisse
Trace buffer allow to dump a command buffer which is fully repliable
as a standalone c program. This make debuging lockup immensively
simpler. This patch only plug the core minimal stuff and is still
missing the more fancy aspect that are in r600g. It however already
proved
From: Jerome Glisse
The gpu packet prefetcher hates the ugly big nop packet those leads
to prefetching some invalid memory in some case. Apparently hawaii
is particularly sensible to this.
Note this only partialy fix hawaii issues and some zbuffer tiling
issues are still present.
Signed-off-by
From: Jerome Glisse
There is no reason anymore to load with RTLD_GLOBAL and for some driver
this even result in dlclose failing to unload leading to catastrophic
failure with swrast fallback.
Signed-off-by: Jérôme Glisse
---
src/glx/dri_common.c | 10 +-
1 file changed, 5 insertions
On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote:
> On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote:
> > On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding
> > wrote:
> > > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote:
> > >> On Mon, Nov 18, 2013 at 8:29 AM, Thie
On Thu, Sep 05, 2013 at 03:29:52PM -0400, Jerome Glisse wrote:
> On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
> > Hi all,
> >
> > This thread is about
> > http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
> >
> > We rec
On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
> Hi all,
>
> This thread is about
> http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
>
> We recently find some interesting thing about UVD based playback on
> loongson 3a plaform, and also find a way to fix the prob
On Mon, May 20, 2013 at 5:13 AM, Vadim Girlin wrote:
> On 05/20/2013 11:27 AM, Dragomir Ivanov wrote:
>>
>> 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0,
>> surf=0x88d848,
>> level=0x88dea8, bpe=1, tile_split=0, offset=65536, start_level=0)
>>
>> It looks like division by 0. tile_sp
On Wed, May 1, 2013 at 1:23 PM, Marek Olšák wrote:
> This is a funny subject. Originally, we only used SURFACE_SYNC on
> Evergreen, which is what the hw guys recommend using, but then Jerome
> came and rewrote it with no reasonable argument to back it up (what he
> was trying to fix by his cache-f
On Wed, Apr 24, 2013 at 3:15 PM, wrote:
> From: Alex Deucher
>
> Lighter weight then using streamout. Only evergreen
> and newer asics support embedded data as src with
> CP DMA.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
>
From: Jerome Glisse
This move the tracing timeout and printing into winsys and add
an debug environement variable for it (R600_DEBUG=trace_cs).
Lot of file touched because of winsys API changes.
v2: Do not write lockup file if ib uniq id does not match last one
Signed-off-by: Jerome Glisse
From: Jerome Glisse
This move the tracing timeout and printing into winsys and add
an debug environement variable for it (R600_DEBUG=trace_cs).
Lot of file touched because of winsys API changes.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r300/r300_context.c| 2 +-
src
From: Jerome Glisse
Most test pass, issue are with border color and swizzle.
Based on ircnick patch.
v2: Restaged commit hunk
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/radeonsi/si_state.c | 71 -
src/gallium/drivers/radeonsi/sid.h | 7
2
From: Jerome Glisse
v2: Remove left over code
v3: Restage properly the commit so hunk of first one are not in
second one.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/radeonsi/r600_texture.c | 11 ++--
src/gallium/drivers/radeonsi/si_state.c | 81
From: Jerome Glisse
Most test pass, issue are with border color and swizzle.
Based on ircnick patch.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/radeonsi/si_state.c | 165 +---
src/gallium/drivers/radeonsi/sid.h | 7 ++
2 files changed, 96
From: Jerome Glisse
v2: Remove left over code
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/radeonsi/r600_texture.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/r600_texture.c
b/src/gallium/drivers/radeonsi/r600_texture.c
Rebase on top of lastest libdrm patch. With small modification to ddx you can
also
have tiled front buffer rendering. But again we need to wait next mesa release
before changing ddx to assume by default it is installed with a recent enough
mesa.
No regression, just new test that pass.
Cheers,
J
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/radeonsi/r600_texture.c | 4 +-
src/gallium/drivers/radeonsi/si_state.c | 83 +
2 files changed, 14 insertions(+), 73 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/r600_texture.c
This is mesa match for 2d tiling, it's missing change to configure.ac
to require proper libdrm. Will respin once i know.
Cheers,
Jerome
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Jerome Glisse
Build time option, set RADEON_CS_DUMP_ON_LOCKUP to 1 in radeon_drm_cs.h to
enable it.
When enabled after each cs submission the code will try to detect lockup by
waiting on one of the buffer of the cs to become idle, after a timeout it
will consider that the cs triggered a
On Wed, Mar 27, 2013 at 11:27 AM, wrote:
> From: Jerome Glisse
>
> Build time option, set RADEON_CS_DUMP_ON_LOCKUP to 1 in radeon_drm_cs.h to
> enable it.
>
> When enabled after each cs submission the code will try to detect lockup by
> waiting on one of the buffer of
From: Jerome Glisse
Build time option, set RADEON_CS_DUMP_ON_LOCKUP to 1 in radeon_drm_cs.h to
enable it.
When enabled after each cs submission the code will try to detect lockup by
waiting on one of the buffer of the cs to become idle, after a timeout it
will consider that the cs triggered a
On Wed, Mar 27, 2013 at 4:45 AM, Christian König
wrote:
> Am 27.03.2013 01:43, schrieb Jerome Glisse:
>
>> On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie wrote:
>>>>>>
>>>>>> correctly). But Marek is quite right that this only counts for state
>&g
On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie wrote:
>>
correctly). But Marek is quite right that this only counts for state
objects
and makes no sense for set_* and draw_* calls (and I'm currently thinking
how to avoid that and can't come up with a proper solution). Anyway it's
On Tue, Mar 26, 2013 at 2:14 PM, Jordan Justen wrote:
> On Tue, Mar 26, 2013 at 10:34 AM, Jerome Glisse wrote:
>> On Tue, Mar 26, 2013 at 4:39 AM, violin yanev wrote:
>>> Thanks for your replies guys!
>>>
>>> The output of eglinfo is:
>>> EGL API ver
On Tue, Mar 26, 2013 at 4:39 AM, violin yanev wrote:
> Thanks for your replies guys!
>
> The output of eglinfo is:
> EGL API version: 1.4
> EGL vendor string: Mesa Project
> EGL version string: 1.4 (DRI2)
> EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
> EGL extensions string:
> EGL_MESA_drm_im
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák wrote:
> On Tue, Mar 26, 2013 at 3:59 PM, Christian König
> wrote:
>> Am 26.03.2013 15:34, schrieb Marek Olšák:
>>
>>> Speaking of si_pm4_state, I think it's a horrible mechanism for
>>> anything other than constant state objects (create/bind/delete
>
On Tue, Mar 26, 2013 at 6:22 AM, Christian König
wrote:
> Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
>
>> From: Jerome Glisse
>>
>> Same as on r600, trace cs execution by writting cs offset after each
>> states, this allow to pin point lockup inside command
On Mon, Mar 25, 2013 at 1:12 PM, Christian König
wrote:
> Am 25.03.2013 17:50, schrieb Jerome Glisse:
>
>> On Mon, Mar 25, 2013 at 12:38 PM, Christian König
>> wrote:
>>>
>>> Am 25.03.2013 17:01, schrieb j.gli...@gmail.com:
>>>
>>>>
From: Jerome Glisse
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside command stream and
narrow down the scope of lockup investigation.
v2: Use WRITE_DATA packet instead of WRITE_MEM
Signed-off-by: Jerome Glisse
---
src/gallium
On Mon, Mar 25, 2013 at 12:38 PM, Christian König
wrote:
> Am 25.03.2013 17:01, schrieb j.gli...@gmail.com:
>
>> From: Jerome Glisse
>>
>> Same as on r600, trace cs execution by writting cs offset after each
>> states, this allow to pin point lockup inside command
On Mon, Mar 25, 2013 at 12:17 PM, Michel Dänzer wrote:
> On Mon, 2013-03-25 at 12:01 -0400, j.gli...@gmail.com wrote:
>> From: Jerome Glisse
>>
>> Same as on r600, trace cs execution by writting cs offset after each
>> states, this allow to pin point lockup inside c
From: Jerome Glisse
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside command stream and
narrow down the scope of lockup investigation.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/radeonsi/r600_hw_context.c | 58
On Mon, Mar 4, 2013 at 2:05 PM, Michel Dänzer wrote:
> On Mon, 2013-03-04 at 13:17 -0500, j.gli...@gmail.com wrote:
>> From: Jerome Glisse
>>
>> Some code calling the flush function gave a fence pointer that point
>> to an old fence and should be unrefer
From: Jerome Glisse
Some code calling the flush function gave a fence pointer that point
to an old fence and should be unreference to avoid leaking fence.
Candidate for 9.1
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/r600_pipe.c | 8 +---
src/gallium/drivers
On Wed, Feb 27, 2013 at 6:11 PM, Marek Olšák wrote:
> The states were split because we thought it caused a hardlock. Now we know
> the hardlock was caused by something else and has since been fixed.
For the serie:
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/everg
On Sun, Mar 3, 2013 at 8:39 AM, Marek Olšák wrote:
> also change names of other functions, so that they make sense
For the serie:
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/evergreen_state.c |4 +-
> src/gallium/drivers/r600/r600_pipe.h |8 +--
&g
On Sun, Mar 3, 2013 at 9:13 AM, Marek Olšák wrote:
> This avoids the kernel CS checker errors with MSAA textures.
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/r600_texture.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/ga
> -util_hash_table_set(bo->mgr->bo_handles,
> (void*)(uintptr_t)whandle->handle, bo);
> -pipe_mutex_unlock(bo->mgr->bo_handles_mutex);
> -
> whandle->stride = stride;
> return TRUE;
> }
> --
> 1.8.1.4
>
Reviewed-by: Jerome Glisse
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Feb 26, 2013 at 1:05 PM, Stefan Seifert wrote:
> Good news!
>
> I gave the r600-sb branch a good testing at commit
> 265ae41b1f1d086d35d274c7378c43cddb8215c8 and so far I've not had a single
> lockup in about 1 1/2 hours of flight time!
>
> The downside is that this is with R600_HYPERZ=0.
|3 +--
> src/gallium/drivers/r600/r600_hw_context.c | 26 +-
> 2 files changed, 18 insertions(+), 11 deletions(-)
For the serie:
Reviewed-by: Jerome Glisse
>
> --
> 1.7.7.5
>
> ___
>
From: Jerome Glisse
This work around disable hyperz if write to zbuffer is disabled. Somehow
using hyperz when not writting to the zbuffer trigger GPU lockup. See :
https://bugs.freedesktop.org/show_bug.cgi?id=60848
Candidate for 9.1
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600
>
> Also the sampler swizzling was broken in theory and the fact it worked was
> a lucky coincidence.
>
> radeonsi might need to port this.
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/evergreen_state.c | 13 +++-
> src/gallium/drivers/r600/r60
From: Jerome Glisse
Seems that alpha test being enabled confuse the GPU on the order in
which it should perform the Z testing. So force the order programmed
throught db shader control.
v2: Only force z order when alpha test is enabled
v3: Update db shader when binding new dsa + spelling fix
On Mon, Feb 11, 2013 at 6:45 PM, wrote:
> From: Jerome Glisse
>
> Seems that alpha test being enabled confuse the GPU on the order in
> which it should perform the Z testing. So force the order programmed
> throught db shader control.
>
> v2: Only force z order when
From: Jerome Glisse
Seems that alpha test being enabled confuse the GPU on the order in
which it should perform the Z testing. So force the order programmed
throught db shader control.
v2: Only force z order when alpha test is enabled
Signed-off-by: Jerome Glisse
Reviewed-by: Marek Olšák
From: Jerome Glisse
Seems that alpha test being enabled confuse the GPU on the order in
which it should perform the Z testing. So force the order programmed
throught db shader control.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/evergreen_state.c | 5 +
src/gallium/drivers
From: Jerome Glisse
We are now seing cs that can go over the vram+gtt size to avoid
failing flush early cs that goes over 70% (gtt+vram) usage. 70%
is use to allow some fragmentation.
The idea is to compute a gross estimate of memory requirement of
each draw call. After each draw call, memory
On Wed, Jan 30, 2013 at 10:35 PM, Marek Olšák wrote:
> On Wed, Jan 30, 2013 at 6:14 PM, wrote:
>> From: Jerome Glisse
>>
>> We are now seing cs that can go over the vram+gtt size to avoid
>> failing flush early cs that goes over 70% (gtt+vram) usage. 70%
>> i
From: Jerome Glisse
We are now seing cs that can go over the vram+gtt size to avoid
failing flush early cs that goes over 70% (gtt+vram) usage. 70%
is use to allow some fragmentation.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/evergreen_state.c| 4
src/gallium/drivers
From: Jerome Glisse
v2: Add virtual address to dma src/dst offset for cayman
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/evergreen_hw_context.c | 46 ++
src/gallium/drivers/r600/evergreen_state.c | 201
src/gallium/drivers/r600/evergreend.h
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/evergreen_hw_context.c | 44 ++
src/gallium/drivers/r600/evergreen_state.c | 197
src/gallium/drivers/r600/evergreend.h | 15 ++
src/gallium/drivers/r600/r600.h
From: Jerome Glisse
Add ring support, you can create a cs for each ring. DMA ring is
bit special regarding relocation as you must emit as much relocation
as there is use of the buffer.
v2: - Improved comment on relocation changes
- Use a single thread to queue cs submittion this simplify
So design is mostly the same then previously. Few changes, first i use only
one thread to offload all cs submission wether gfx or dma. Reasons is that
using on thread for gfx and one for dma lead to more complex synchronization
with no gain ie when submitting gfx you would need to make sure previou
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/evergreen_compute.c | 2 ++
src/gallium/drivers/r600/r600_hw_context.c | 1 +
src/gallium/drivers/r600/r600_pipe.c | 6 ++
src/gallium/drivers/r600/r600_pipe.h | 1 +
src/gallium/drivers/r600
On Tue, Jan 8, 2013 at 10:15 AM, Marek Olšák wrote:
> On Mon, Jan 7, 2013 at 9:30 PM, wrote:
>> From: Jerome Glisse
>>
>> Signed-off-by: Jerome Glisse
>> ---
>> src/gallium/drivers/r300/r300_context.c | 2 +-
>> src/gallium/drivers/r600/r6
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r300/r300_context.c | 2 +-
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 2 +-
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 2
So first patch is the winsys change while second patch implement multi ring
in the r600g driver. It use a stack to keep track of the order into which
rings must be submited. If will only pop the necessary entry from the stack
depending on the current request.
I think this address all concern from
On Mon, Jan 7, 2013 at 11:03 AM, Marek Olšák wrote:
> On Mon, Jan 7, 2013 at 3:45 PM, Christian König
> wrote:
>> On 07.01.2013 01:24, Marek Olšák wrote:
>>>
>>> On Sun, Jan 6, 2013 at 11:58 PM, Jerome Glisse wrote:
>>>>
>>>> On Sun, Jan
On Sat, Jan 5, 2013 at 9:49 AM, Christian König wrote:
> On 04.01.2013 23:19, j.gli...@gmail.com wrote:
> [SNIP]
>
>> diff --git a/src/gallium/drivers/r300/r300_emit.c
>> b/src/gallium/drivers/r300/r300_emit.c
>> index d1ed4b3..c824821 100644
>> --- a/src/gallium/drivers/r300/r300_emit.c
>> +++ b/
On Fri, Jan 4, 2013 at 6:33 PM, Alex Deucher wrote:
> On Fri, Jan 4, 2013 at 5:19 PM, wrote:
>> From: Jerome Glisse
>>
>> The design is to take advantage of the fact that kernel will emit
>> semaphore when buffer is referenced by different ring. So the only
On Fri, Jan 4, 2013 at 5:19 PM, wrote:
> From: Jerome Glisse
>
> Signed-off-by: Jerome Glisse
For the serie piglit says no regression on r7xx/evergreen. I need to
test r3xx/r5xx and SI.
Cheers,
Jerome
> ---
> src/gallium/drivers/r600/r600_pipe.c | 18 +-
From: Jerome Glisse
The design is to take advantage of the fact that kernel will emit
semaphore when buffer is referenced by different ring. So the only
thing we need to enforce synchronization btw dma and gfx/compute
ring is to make sure that we never reference same bo at the same
time on the
From: Jerome Glisse
Upcoming async dma support rely on winsys knowing about GPU families.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r300/r300_chipset.c | 57 +--
src/gallium/drivers/r300/r300_chipset.h | 27 --
src/gallium/drivers/r300/r300_emit.c
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/r600_pipe.c | 18 +-
src/gallium/drivers/r600/r600_pipe.h | 2 +-
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 3 +--
src/gallium/winsys/radeon/drm/radeon_drm_cs.h | 2 +-
4
On Wed, Dec 19, 2012 at 12:33 PM, Tom Stellard wrote:
> On Sun, Dec 16, 2012 at 08:33:23PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This adds TBO support to r600g, and with GLSL 1.40 enabled,
>> we now get 3.1 core profiles advertised for r600g.
>>
>> This code is evergreen only so fa
On Wed, Dec 19, 2012 at 12:17 PM, wrote:
> From: Jerome Glisse
>
> It's a build time option you need to set R600_TRACE_CS to 1 and it
> will print to stderr all cs along as cs trace point value which
> gave last offset into a cs process by the GPU.
>
> Signed-o
From: Jerome Glisse
It's a build time option you need to set R600_TRACE_CS to 1 and it
will print to stderr all cs along as cs trace point value which
gave last offset into a cs process by the GPU.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/r600_hw_context.c
From: Jerome Glisse
This force surface allocated from ddx to be consider as height
aligned on 8 and fix 1D->2D tiling transition that result from
this.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/r600_texture.c | 12 +---
1 file changed, 9 insertions(+), 3 deleti
From: Jerome Glisse
htile is used for HiZ and HiS support and fast Z/S clears.
This commit just adds the htile setup and Fast Z clear.
We don't take full advantage of HiS with that patch.
v2 really use fast clear, still random issue with some tiles
need to try more flush combination
From: Jerome Glisse
htile is used for HiZ and HiS support and fast Z/S clears.
This commit just adds the htile setup and Fast Z clear.
We don't take full advantage of HiS with that patch.
v2 really use fast clear, still random issue with some tiles
need to try more flush combination
From: Jerome Glisse
This bring r600g allmost inline with closed source driver when
it comes to flushing and synchronization pattern.
v2-v4: history lost somewhere in outer space
v5: Fix compute size of flushing, use define for flags, update
worst case cs size requirement for flush, treat
So those were tested on everegreen (caicos, redwood, turks, barts) and on
rv740 and did not regress anything. I can't test other r6xx/r7xx as currently
mesa master trigger lockup on anything else than rv740.
I am gonna merge those by the end of this week.
Cheers,
Jerome
_
From: Jerome Glisse
htile is used for HiZ and HiS support and fast Z/S clears.
This commit just adds the htile setup and Fast Z clear.
We don't take full advantage of HiS with that patch.
v2 really use fast clear, still random issue with some tiles
need to try more flush combination
From: Jerome Glisse
This bring r600g allmost inline with closed source driver when
it comes to flushing and synchronization pattern.
v2-v4: history lost somewhere in outer space
v5: Fix compute size of flushing, use define for flags, update
worst case cs size requirement for flush, treat
Ok so this time it should be it. Following patch seems to behave properly.
I am still in process of checking again that they don't regress anything,
i should be done monday or tuesday. If there is no objection by them i
will commit them.
Note that you need kernel patch for those and that by defaul
aven't paid much attention to compute side, i should probably look at it.
> And one question:
>
> Why do you use set both FLUSH_AND_INV and STREAMOUT_FLUSH on
> Evergreen, while r600 only gets FLUSH_AND_INV? Did you overlook this?
No, just matching fglrx pattern, i don't think i teste
From: Jerome Glisse
htile is used for HiZ and HiS support and fast Z/S clears.
This commit just adds the htile setup and Fast Z clear.
We don't take full advantage of HiS with that patch.
v2 really use fast clear, still random issue with some tiles
need to try more flush combination
From: Jerome Glisse
This bring r600g allmost inline with closed source driver when
it comes to flushing and synchronization pattern.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/evergreen_compute.c | 8 +-
.../drivers/r600/evergreen_compute_internal.c | 4 +-
src
So i finally have something that doesn't seem to lockup (i run in loop several
things that used to lockup on various GPU over 24hour without a single lockup),
or regress anything. It's a bundle deal the first patch is needed for lockup
avoidance. Tested on :
rv610, rv635, rv670, rv710, rv730, rv740
On Fri, Nov 30, 2012 at 7:43 AM, Benoit Jacob wrote:
> On 12-11-23 02:21 PM, Benoit Jacob wrote:
>> On 12-11-21 12:48 PM, Chad Versace wrote:
>>> On 11/20/2012 09:29 AM, Benoit Jacob wrote:
>>>
Any questions?
Do you support or oppose me asking FD.o admins to allow hidden bugs on
Mes
On Thu, Nov 01, 2012 at 03:13:31AM +0100, Marek Olšák wrote:
> On Thu, Nov 1, 2012 at 2:13 AM, Alex Deucher wrote:
> > On Wed, Oct 31, 2012 at 8:05 PM, Marek Olšák wrote:
> >> The problem was we set VRAM|GTT for relocations of STATIC resources.
> >> Setting just VRAM increases the framerate 4 tim
o.
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/r600_buffer.c | 42
> ---
> src/gallium/drivers/r600/r600_texture.c |3 ++-
> 2 files changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_bu
On Tue, Oct 30, 2012 at 8:49 PM, Tzvetan Mikov wrote:
> On 10/30/2012 05:20 PM, Tzvetan Mikov wrote:
>>
>> Thanks a lot! I reproduced the same results here and I think I have
>> figured out what the problem is. The frame buffer is always created in
>> linear mode. The temporary hack included below
From: Jerome Glisse
On r6xx/r7xx shader resource management need to make sure that the
shader does not goes over the gpr register limit. Each specific
asic has a maxmimum register that can be split btw shader stage.
For each stage the shader must not use more register than the
limit programmed
On Tue, Oct 30, 2012 at 10:43 AM, Tzvetan Mikov wrote:
> On 10/30/2012 07:12 AM, Patrick Baggett wrote:
>> Is your screen refresh rate 70 Hz? Because if so, that means that it's
>> syncing to the vblank on Mesa, and not doing so on the proprietary one.
>
> Unfortunately no. In fact the Gallium EGL
On Fri, Oct 26, 2012 at 10:26 PM, Tzvetan Mikov wrote:
>> -Original Message-
>> From: Jerome Glisse
>
>> > Can anyone shed some light on this? Is this by design - e.g. is
>> > this a case of "we know that tiling is currently slower than linear
&g
On Fri, Oct 26, 2012 at 10:01 PM, wrote:
> From: Jerome Glisse
>
> On r6xx/r7xx shader resource management need to make sure that the
> shader does not goes over the gpr register limit. Each specific
> asic has a maxmimum register that can be split btw shader stage.
> For eac
From: Jerome Glisse
On r6xx/r7xx shader resource management need to make sure that the
shader does not goes over the gpr register limit. Each specific
asic has a maxmimum register that can be split btw shader stage.
For each stage the shader must not use more register than the
limit programmed
On Fri, Oct 26, 2012 at 8:07 PM, Tzvetan Mikov wrote:
> Hi,
> I have been running tests with Mesa 9.0 and Rdeon R600 (Radeon HD 6460) and I
> accidentally noticed that a small hack I did to disable texture tiling,
> actually *doubles* the frame rate. With different chips (e.g. 6750) the
> diffe
;
> The command buffers are nothing like that. They represent states, not state
> slots.
>
> We could probably give r600_atom a better name someday.
For the serie:
Reviewed-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/evergreen_compute.c |4 +--
> src/gallium/d
On Wed, Oct 3, 2012 at 5:50 PM, Marek Olšák wrote:
> The decompression is done in-place and only the compressed tiles are
> decompressed. Note: R6xx-R7xx can do that only with Z16 and Z32F.
>
> The texture unit is programmed to use non-displayable tiling and depth
> ordering of samples, so that it
On Wed, Sep 12, 2012 at 5:24 PM, Jerome Glisse wrote:
> On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák wrote:
>> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse wrote:
>>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák wrote:
>>>> Please provide information about the G
On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák wrote:
> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse wrote:
>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák wrote:
>>> Please provide information about the GPU and the test which locks up. I'd
>>> like to reproduc
On Tue, Jul 17, 2012 at 1:58 PM, wrote:
> From: Jerome Glisse
>
> htile is used for HiZ and HiS support and fast Z/S clears.
> This commit just adds the htile setup and Fast Z clear.
> We don't take full advantage of HiS with that patch.
>
> v2 really use fast clea
On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák wrote:
> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse wrote:
>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák wrote:
>>> Please provide information about the GPU and the test which locks up. I'd
>>> like to reproduc
On Tue, Sep 11, 2012 at 3:00 PM, Jerome Glisse wrote:
> On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák wrote:
>> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse wrote:
>>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák wrote:
>>>> Please provide information about the G
On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák wrote:
> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse wrote:
>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák wrote:
>>> Please provide information about the GPU and the test which locks up. I'd
>>> like to reproduc
1 - 100 of 261 matches
Mail list logo
