On Thu, Jul 24, 2014 at 8:07 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Jul 24, 2014 at 6:28 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
The ucode we got for hawaii does not support 0x1000 special nop
packet type 3 and this leads to gpu reading
On Thu, Jul 24, 2014 at 05:42:21PM -0400, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
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
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
thierry.red...@gmail.com wrote:
On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote:
On Mon, Nov 18, 2013 at
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 problem.
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 recently find some interesting thing about UVD based
On Mon, May 20, 2013 at 5:13 AM, Vadim Girlin vadimgir...@gmail.com 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
On Wed, May 1, 2013 at 1:23 PM, Marek Olšák mar...@gmail.com 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: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_hw_context.c | 66
+++
src/gallium/drivers/r600/evergreend.h | 42 ++
src/gallium/drivers/r600/r600_blit.c| 10 +++-
src/gallium/drivers/r600/r600_pipe.h
On Wed, Mar 27, 2013 at 4:45 AM, Christian König
deathsim...@vodafone.de wrote:
Am 27.03.2013 01:43, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie airl...@gmail.com wrote:
correctly). But Marek is quite right that this only counts for state
objects
and makes no sense
On Wed, Mar 27, 2013 at 11:27 AM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
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
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
deathsim...@vodafone.de 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
On Tue, Mar 26, 2013 at 4:39 AM, violin yanev violin.ya...@gmail.com 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:
On Tue, Mar 26, 2013 at 2:14 PM, Jordan Justen jljus...@gmail.com wrote:
On Tue, Mar 26, 2013 at 10:34 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Mar 26, 2013 at 4:39 AM, violin yanev violin.ya...@gmail.com wrote:
Thanks for your replies guys!
The output of eglinfo is:
EGL API
On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie airl...@gmail.com 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 Mon, Mar 25, 2013 at 12:17 PM, Michel Dänzer mic...@daenzer.net wrote:
On Mon, 2013-03-25 at 12:01 -0400, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside
On Mon, Mar 25, 2013 at 12:38 PM, Christian König
deathsim...@vodafone.de wrote:
Am 25.03.2013 17:01, schrieb j.gli...@gmail.com:
From: Jerome Glisse jgli...@redhat.com
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
deathsim...@vodafone.de wrote:
Am 25.03.2013 17:50, schrieb Jerome Glisse:
On Mon, Mar 25, 2013 at 12:38 PM, Christian König
deathsim...@vodafone.de wrote:
Am 25.03.2013 17:01, schrieb j.gli...@gmail.com:
From: Jerome Glisse jgli
On Sun, Mar 3, 2013 at 9:13 AM, Marek Olšák mar...@gmail.com wrote:
This avoids the kernel CS checker errors with MSAA textures.
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/r600_texture.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Sun, Mar 3, 2013 at 8:39 AM, Marek Olšák mar...@gmail.com wrote:
also change names of other functions, so that they make sense
For the serie:
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c |4 +-
src/gallium/drivers/r600/r600_pipe.h
On Wed, Feb 27, 2013 at 6:11 PM, Marek Olšák mar...@gmail.com 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 jgli...@redhat.com
---
src/gallium
On Mon, Mar 4, 2013 at 2:05 PM, Michel Dänzer mic...@daenzer.net wrote:
On Mon, 2013-03-04 at 13:17 -0500, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Some code calling the flush function gave a fence pointer that point
to an old fence and should be unreference to avoid
;
return TRUE;
}
--
1.8.1.4
Reviewed-by: Jerome Glisse jgli...@redhat.com
___
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 n...@detonation.org 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
+--
src/gallium/drivers/r600/r600_hw_context.c | 26 +-
2 files changed, 18 insertions(+), 11 deletions(-)
For the serie:
Reviewed-by: Jerome Glisse jgli...@redhat.com
--
1.7.7.5
___
mesa-dev mailing list
mesa-dev
and the fact it worked was
a lucky coincidence.
radeonsi might need to port this.
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c | 13 +++-
src/gallium/drivers/r600/r600_state.c |8 -
src/gallium/drivers/r600/r600_texture.c
On Mon, Feb 11, 2013 at 6:45 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
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
On Wed, Jan 30, 2013 at 10:35 PM, Marek Olšák mar...@gmail.com wrote:
On Wed, Jan 30, 2013 at 6:14 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
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
On Sat, Jan 5, 2013 at 9:49 AM, Christian König deathsim...@vodafone.de 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
---
On Fri, Jan 4, 2013 at 5:19 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Signed-off-by: Jerome Glisse jgli...@redhat.com
For the serie piglit says no regression on r7xx/evergreen. I need to
test r3xx/r5xx and SI.
Cheers,
Jerome
---
src/gallium/drivers/r600
On Fri, Jan 4, 2013 at 6:33 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Fri, Jan 4, 2013 at 5:19 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
The design is to take advantage of the fact that kernel will emit
semaphore when buffer is referenced by different ring
On Wed, Dec 19, 2012 at 12:17 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
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
On Wed, Dec 19, 2012 at 12:33 PM, Tom Stellard t...@stellard.net wrote:
On Sun, Dec 16, 2012 at 08:33:23PM +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
This adds TBO support to r600g, and with GLSL 1.40 enabled,
we now get 3.1 core profiles advertised for r600g.
This code
this?
No, just matching fglrx pattern, i don't think i tested without that
change, but it definitly match fglrx.
Cheers,
Jerome
Marek
On Thu, Dec 6, 2012 at 8:51 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
This bring r600g allmost inline with closed source driver when
On Fri, Nov 30, 2012 at 7:43 AM, Benoit Jacob bja...@mozilla.com 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
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 alexdeuc...@gmail.com wrote:
On Wed, Oct 31, 2012 at 8:05 PM, Marek Olšák mar...@gmail.com wrote:
The problem was we set VRAM|GTT for relocations of STATIC resources.
Setting just VRAM
On Tue, Oct 30, 2012 at 8:49 PM, Tzvetan Mikov tmi...@jupiter.com 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
.
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
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_buffer.c
b/src
On Tue, Oct 30, 2012 at 10:43 AM, Tzvetan Mikov tmi...@jupiter.com 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
On Fri, Oct 26, 2012 at 8:07 PM, Tzvetan Mikov tmi...@jupiter.com 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.
On Fri, Oct 26, 2012 at 10:01 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
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
On Fri, Oct 26, 2012 at 10:26 PM, Tzvetan Mikov tmi...@jupiter.com 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
but the huge payoff is scheduled
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 jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_compute.c |4 +--
src/gallium/drivers/r600/evergreen_state.c |4 +--
src
On Wed, Oct 3, 2012 at 5:50 PM, Marek Olšák mar...@gmail.com 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
On Wed, Sep 12, 2012 at 5:24 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák mar...@gmail.com wrote:
Please
On Tue, Jul 17, 2012 at 1:58 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
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
),
atomization of some states, some fixes and a major cleanup in r600_draw_vbo.
Tested on RS880 and REDWOOD.
Please review.
For the first 18 patch :
Reviewed-by: Jerome Glisse jgli...@redhat.com
NAK for the 19 see other reply
Marek Olšák (19):
r600g: consolidate initialization
On Mon, Sep 10, 2012 at 7:16 PM, Marek Olšák mar...@gmail.com wrote:
NAK this one introduce lockup. As i said in another email register
group/order matter and with this patch i get 100% lockup rate in some
test case for instance the test case i reference in my other email
---
. But the
ordering relative to pa is kind of weird and moving when looking at
fglrx.
Cheers,
Jerome
On Tue, Sep 11, 2012 at 6:48 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Mon, Sep 10, 2012 at 7:16 PM, Marek Olšák mar...@gmail.com wrote:
NAK this one introduce lockup. As i said in another
On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák mar...@gmail.com wrote:
Please provide information about the GPU and the test which locks up. I'd
like
On Tue, Sep 11, 2012 at 3:00 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák mar...@gmail.com wrote:
Please
On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák mar...@gmail.com wrote:
Please provide information about the GPU and the test which locks up. I'd
like
On Sun, Sep 9, 2012 at 1:03 AM, Marek Olšák mar...@gmail.com wrote:
Based on the patch called simplify and fix flushing and synchronization
by Jerome Glisse.
Rebased, removed unneded code, simplified more and cleaned up.
Also, SH_ACTION_ENA is not set when changing shaders (hw doesn't seem
On Thu, Sep 6, 2012 at 11:32 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Sep 6, 2012 at 10:54 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Thu, Sep 6, 2012 at 6:20 AM, Dave Airlie airl...@gmail.com wrote:
On Thu, Sep 6, 2012 at 5:21 PM, Philipp Klaus Krause p...@spth.de wrote
On Thu, Sep 6, 2012 at 11:32 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Sep 6, 2012 at 10:54 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Thu, Sep 6, 2012 at 6:20 AM, Dave Airlie airl...@gmail.com wrote:
On Thu, Sep 6, 2012 at 5:21 PM, Philipp Klaus Krause p...@spth.de wrote
On Thu, Sep 6, 2012 at 4:10 PM, Marek Olšák mar...@gmail.com wrote:
On Thu, Sep 6, 2012 at 8:34 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Thu, Sep 6, 2012 at 2:29 PM, Marek Olšák mar...@gmail.com wrote:
This looks good to me. It's funny to see the r300g architecture being
re-implemented
for evergreen
r600g: change programming of CB_SHADER_MASK on r600-r700
r600g: implement MSAA for r700
For the serie :
Reviewed-by: Jerome Glisse jgli...@redhat.com
What's wrong with r6xx ?
src/gallium/auxiliary/util/u_blitter.c | 46
src/gallium/auxiliary/util
On Fri, Aug 3, 2012 at 11:06 AM, Christian König
deathsim...@vodafone.de wrote:
Wait for VA use to end before reusing it.
Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=45018
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c
On Fri, Aug 3, 2012 at 11:06 AM, Christian König
deathsim...@vodafone.de wrote:
Wait for VA use to end before reusing it.
Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=45018
Signed-off-by: Christian König deathsim...@vodafone.de
Actually you right mesa can't free right away va, it
On Sun, Jul 29, 2012 at 1:50 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Jul 17, 2012 at 7:58 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
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
On Sun, Jul 22, 2012 at 8:58 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Jul 20, 2012 at 4:54 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Thu, Jul 19, 2012 at 10:25 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Thu
On Mon, Jul 23, 2012 at 5:28 PM, Marek Olšák mar...@gmail.com wrote:
On Mon, Jul 23, 2012 at 4:25 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Sun, Jul 22, 2012 at 8:58 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Jul 20, 2012 at 4:54 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Thu
On Mon, Jul 23, 2012 at 5:28 PM, Marek Olšák mar...@gmail.com wrote:
On Mon, Jul 23, 2012 at 4:25 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Sun, Jul 22, 2012 at 8:58 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Jul 20, 2012 at 4:54 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Thu
On Thu, Jul 19, 2012 at 9:00 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Jul 20, 2012 at 1:34 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Thu, Jul 19, 2012 at 6:07 PM, Marek Olšák mar...@gmail.com wrote:
I have these issues with the patch:
1) On GPUs without a vertex cache, you flush
On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák mar...@gmail.com wrote:
I actually care a lot about lockups. Well, you are complaing about
lockups, yet you have quite obvious bugs in your hyperz code, so let's
fix them first. (I wouldn't even try and run the hyperz code in its
current state.
On Thu, Jul 19, 2012 at 10:25 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák mar...@gmail.com wrote:
I actually care a lot about lockups. Well, you are complaing about
lockups, yet
On Sat, Jul 14, 2012 at 9:56 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Fri, Jul 13, 2012 at 8:11 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Fri, Jul 13, 2012 at 8:08 PM, Marek Olšák mar...@gmail.com wrote:
Hi Jerome,
I couldn't open the patch, because freedesktop.org doesn't seem
On Fri, Jul 13, 2012 at 8:08 PM, Marek Olšák mar...@gmail.com wrote:
Hi Jerome,
I couldn't open the patch, because freedesktop.org doesn't seem to
work for me today, it always times out.
Anyway, non-working code shouldn't be merged into Mesa master, because
it decreases the quality of the
On Tue, Jul 10, 2012 at 2:10 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Jul 10, 2012 at 6:40 AM, Vadim Girlin vadimgir...@gmail.com wrote:
On Sat, 2012-07-07 at 01:48 +0200, Marek Olšák wrote:
On Wed, Jun 27, 2012 at 1:34 AM, Vadim Girlin vadimgir...@gmail.com wrote:
Use
On Tue, Jul 10, 2012 at 5:16 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Jul 10, 2012 at 10:00 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Jul 10, 2012 at 2:10 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Jul 10, 2012 at 6:40 AM, Vadim Girlin vadimgir...@gmail.com wrote:
On Sat
On Tue, Jun 26, 2012 at 5:45 AM, Vadim Girlin vadimgir...@gmail.com wrote:
On Fri, 2012-06-22 at 14:24 -0400, Jerome Glisse wrote:
On Fri, Jun 22, 2012 at 10:02 AM, Vadim Girlin vadimgir...@gmail.com wrote:
r600g: avoid unnecessary shader exports
r600g: enable DUAL_EXPORT mode when
we are doing less exports, which are very costly.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c | 10 +++---
src/gallium/drivers/r600/r600_shader.c | 25
vadimgir...@gmail.com
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c | 46
++
src/gallium/drivers/r600/evergreend.h | 7
src/gallium/drivers/r600/r600_pipe.h | 5 +++
src/gallium/drivers/r600
On Fri, Jun 22, 2012 at 10:02 AM, Vadim Girlin vadimgir...@gmail.com wrote:
r600g: avoid unnecessary shader exports
r600g: enable DUAL_EXPORT mode when possible
First patch fixes the lockups with DUAL_EXPORT mode for me, also AFAICS it
fixes some depth/stencil tests, though I'm not sure
On Tue, Jun 19, 2012 at 2:06 PM, Tom Stellard thomas.stell...@amd.com wrote:
On Tue, Jun 19, 2012 at 07:57:50PM +0200, Marek Olšák wrote:
Hi Tom,
This adds new calls to r600_inval_xxx_cache, which justs sets the
dirty flag in the atom surface_sync_cmd to true, but I couldn't find
where the
On Mon, Jun 18, 2012 at 8:33 PM, Fredrik Höglund fred...@kde.org wrote:
On Tuesday 19 June 2012, Brian Paul wrote:
On 06/18/2012 02:50 PM, Fredrik Höglund wrote:
Reviewed-by: Brian Paulbri...@vmware.com
---
v2: Change baseinstance to base_instance in _mesa_prims
and to
On Tue, Jun 19, 2012 at 4:46 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Mon, Jun 18, 2012 at 8:33 PM, Fredrik Höglund fred...@kde.org wrote:
On Tuesday 19 June 2012, Brian Paul wrote:
On 06/18/2012 02:50 PM, Fredrik Höglund wrote:
Reviewed-by: Brian Paulbri...@vmware.com
---
v2
On Tue, Jun 12, 2012 at 8:39 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 06/12/2012 02:25 PM, Olivier Galibert wrote:
On Tue, Jun 12, 2012 at 01:50:08PM +0200, Christoph Bumiller wrote:
First question: how many depths should be computed, and for which
coordinates? Which of
On Tue, Jun 12, 2012 at 1:34 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 06/12/2012 06:52 PM, Jerome Glisse wrote:
On Tue, Jun 12, 2012 at 8:39 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 06/12/2012 02:25 PM, Olivier Galibert wrote:
On Tue, Jun 12, 2012
On Thu, 2012-03-01 at 13:56 -0600, Patrick Baggett wrote:
Now I'm curious. Is it the case that every DRI1 driver could be a DRI2
driver with enough effort? Not talking about emulating hardware
features.
Patrick
DRI2 impose nothing on hw capabilities. So any hw can do DRI2 even hw
without
On Tue, Feb 21, 2012 at 7:55 PM, Marek Olšák mar...@gmail.com wrote:
Hi everyone,
Besides the cleanups, there are fixes for create_context fail paths and
rework of queries. The rework is the most important, because it eliminates
buffer_map calls (and therefore buffer_wait) in begin_query.
Hi,
So tiling work is i believe done. I have run piglit accross wide range
of hw and sw combination. Bottom line is new mesa on top of either old
kernel or old ddx won't regress anything. New mesa on top of proper
kernel will get you 2D tiling for texture and anything allocated by
mesa, and if
On Mon, Jan 30, 2012 at 09:23:03PM +0100, Marek Olšák wrote:
Hi everyone,
This patch series is a follow-up to the previous one (Remove all uses of the
register mask). First, it cleans up some code and merges r600_context into
r600_pipe_context. The split of functionality between the two
On Mon, Jan 16, 2012 at 12:08:17PM +, Simon Farnsworth wrote:
(resending due to my inability to work my e-mail client - I neither cc'd
Jerome, nor used the correct identity, so the original appears to be held in
moderation).
On Thursday 12 January 2012, Jerome Glisse j.gli...@gmail.com
On Fri, Jan 13, 2012 at 11:59:28AM +0100, Michel Dänzer wrote:
On Don, 2012-01-12 at 14:50 -0500, Jerome Glisse wrote:
Attached is kernel, libdrm, ddx, mesa/r600g patches to enable 2D tiling
on r600 to cayman. I haven't yet done a full regression testing but 2D
tiling seems to work ok
On Tue, Nov 29, 2011 at 10:12 AM, Jose Fonseca jfons...@vmware.com wrote:
The bulk is there but there are a few places missing.
I'll update those, do some sanity checks and commit.
Jose
Is there a good reason to delete i965g ? Maybe some people are interested in it.
Cheers,
Jerome
On Fri, Sep 23, 2011 at 3:18 AM, jaco...@viatech.com.cn wrote:
Hi all,
In our mesa code, there is a pipe driver named failover which is not used
at all. I think the failover pipe driver is a good solution of the hardware
without full capability to support GL2.0. But why it’s discarded?
On Mon, Jun 27, 2011 at 8:38 AM, Roland Scheidegger srol...@vmware.com wrote:
Am 25.06.2011 00:22, schrieb Vadim Girlin:
On 06/24/2011 11:38 PM, Jerome Glisse wrote:
On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlinvadimgir...@gmail.com
wrote:
Fixes https://bugs.freedesktop.org/show_bug.cgi?id
On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlin vadimgir...@gmail.com wrote:
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38440
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
As discussed previously, there is better to handle this. I think best
solution is to always add the instruction
On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlin vadimgir...@gmail.com wrote:
#1 fixes slots order for x y writes in the LIT implementation.
Without this patch fp-lit-mask piglit test fails after patch 3. It seems
wrong order causes wrong PV.* values for the next instruction.
#2 reduces
On Wed, Jun 22, 2011 at 10:49 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Jun 22, 2011 at 10:12 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 21.06.2011 20:59, schrieb Sven Arvidsson:
This change broke a whole lot of stuff on r600g, for example Unigine
Heaven:
shader
On Thu, Jun 23, 2011 at 10:38 AM, Roland Scheidegger srol...@vmware.com wrote:
Am 23.06.2011 16:09, schrieb Jerome Glisse:
On Wed, Jun 22, 2011 at 10:49 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Jun 22, 2011 at 10:12 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 21.06.2011
On Thu, Jun 16, 2011 at 10:08 AM, Brian Paul bri...@vmware.com wrote:
On 06/15/2011 03:38 PM, Bryan Cain wrote:
My work on the GLSL IR to TGSI translator I announced on the list this
April is now at the point where I think it is ready to be merged into
Mesa. It is stable and doesn't regress
On Tue, May 24, 2011 at 8:09 PM, Bryan Cain bryanca...@gmail.com wrote:
Hi,
In the past few days, I've been working on native integer support in my
GLSL to TGSI translator. Something that's come to my attention is that
supporting Gallium targets with and without integer support using a
On Wed, May 25, 2011 at 9:41 AM, Keith Whitwell kei...@vmware.com wrote:
On Wed, 2011-05-25 at 09:32 -0400, Jerome Glisse wrote:
On Tue, May 24, 2011 at 8:09 PM, Bryan Cain bryanca...@gmail.com wrote:
Hi,
In the past few days, I've been working on native integer support in my
GLSL
On Tue, May 17, 2011 at 11:22 PM, Eric Anholt e...@anholt.net wrote:
One of the pain points of working on compiler optimizations has been
justifying them -- sometimes I come up with something I think is
useful and spend a day or two on it, but the value doesn't show up as
fps in the
On Wed, May 18, 2011 at 3:16 PM, Eric Anholt e...@anholt.net wrote:
On Wed, 18 May 2011 11:05:39 -0400, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, May 17, 2011 at 11:22 PM, Eric Anholt e...@anholt.net wrote:
One of the pain points of working on compiler optimizations has been
justifying
Please resend by attaching the patch not pasting it
On Fri, May 6, 2011 at 4:53 PM, Carl-Philip Haensch
carl-philip.haen...@mailbox.tu-dresden.de wrote:
From b5ad4e6fb399203afcfe2a5ccb35bb8ccad28b65 Mon Sep 17 00:00:00 2001
From: Carl-Philip Haensch carli@carli-laptop.(none)
Date: Fri, 6 May
On Wed, Apr 20, 2011 at 8:01 AM, Martin Gräßlin mgraess...@kde.org wrote:
On Wed, 20 Apr 2011 04:32:25 +0200, Henri Verbeet hverb...@gmail.com
wrote:
On 19 April 2011 16:52, Martin Gräßlin mgraess...@kde.org wrote:
Hi Mesa-devs,
yesterday I published a rant about Mesa breaking KWin and
On Wed, Apr 20, 2011 at 9:43 AM, Martin Gräßlin mgraess...@kde.org wrote:
On Wed, 20 Apr 2011 09:34:01 -0400, Jerome Glisse j.gli...@gmail.com
wrote:
Your issue is right there, gnome-shell have been successful dealing
with that because they target a particular mesa version and they set
On Tue, Apr 19, 2011 at 10:52 AM, Martin Gräßlin mgraess...@kde.org wrote:
Hi Mesa-devs,
yesterday I published a rant about Mesa breaking KWin and given some
comments on Phoronix Forums it seems like there is the wish for more
communication between our development groups and so I want to
1 - 100 of 162 matches
Mail list logo
