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, 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 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 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 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
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
+--
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
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
;
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 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
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 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 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
-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, 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
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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 Mon, Apr 19, 2010 at 03:38:54PM +0200, José Fonseca wrote:
On Mon, 2010-04-19 at 06:22 -0700, Keith Whitwell wrote:
On Mon, 2010-04-19 at 06:07 -0700, Marek Olšák wrote:
Unfortunately, this is supported only on r500 (i.e. not r300 nor r400)
and only when the DRM version is =2.3.0 (i.e.
On Sun, May 23, 2010 at 12:44:54PM +0200, Mathias Fröhlich wrote:
Hi,
On Monday 17 May 2010 20:51:09 Corbin Simpson wrote:
I'm going to be proactive here, and pull in both this patch and a docs
update.
Ok.
Now that the infrastructure is there.
My initial aim was to have something to
On Tue, May 25, 2010 at 12:35:45AM +0200, Bas Nieuwenhuizen wrote:
Hello,
I wrote two patches that fix various things to get r600g running on my
computer and to get r600_clear and depthtesting working.
I wrote them starting from Marek's r600g branch.
Feel free to criticize as this is my
On Tue, May 25, 2010 at 03:43:56PM +0200, Bas Nieuwenhuizen wrote:
On Tue, 2010-05-25 at 09:51 +0200, Jerome Glisse wrote:
On Tue, May 25, 2010 at 12:35:45AM +0200, Bas Nieuwenhuizen wrote:
Hello,
I wrote two patches that fix various things to get r600g running on my
computer
the depth buffer patch as it segfault for me and
haven't time to debug this before next week.
Happy hacking everyone.
Cheers,
Jerome Glisse
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
Some distribution (like Fedora) are thinking about making
new package for mesa demos but so far there is no release
for it.
Another issue is the versioning of mesa demos, i expect
that mesa demos will be more stable than mesa thus i don't
think we should follow mesa versioning but let it
Hi,
So after being of the grid i am resuming my epic on mesa demos.
I set version to 8.0 so it's easy for distro, and as fresh start for
demos on it's own. If no one object i will do the release by the end
of the week (this time i shouldn't find myself in a no connectivity
situation).
Cheers,
On 07/16/2010 03:18 PM, Chia-I Wu wrote:
On Sat, Jul 17, 2010 at 2:28 AM, Jakob Bornecrantzwallbra...@gmail.com wrote:
On Fri, Jul 16, 2010 at 11:10 AM, Chia-I Wuolva...@gmail.com wrote:
Hi all,
This patch series replaces
st_context::draw_arrays
st_context::draw_elements,
On 07/21/2010 04:29 PM, Carl Worth wrote:
Module: Mesa
Branch: master
Commit: c0ca2bfb2ad8cf7fb9d756b5ae52cb77236ff605
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=c0ca2bfb2ad8cf7fb9d756b5ae52cb77236ff605
Author: Carl Worthcwo...@cworth.org
Date: Wed Jul 21 13:17:05 2010 -0700
Just heads up on r600g plan, i removed the compiler stuff it was getting messy
and kind of stopped anyone else from working on other part of r600g. So now
there
is a very simple dumb tgsi - r600 assembler that does work and can run
glxgears
and couple others non textured demos. I want to
On 07/30/2010 04:32 PM, Brian Paul wrote:
On 07/30/2010 12:38 PM, Jerome Glisse wrote:
Hi Brian,
I am facing a strange segfault with r600g on top of lastest git,
git bisect pointed to gallium: implement bounds checking for constant buffers
My feeling is that it should only affect software
On 07/30/2010 05:02 PM, Jakob Bornecrantz wrote:
On 30 jul 2010, at 13.32, Brian Paul wrote:
On 07/30/2010 12:38 PM, Jerome Glisse wrote:
Hi Brian,
I am facing a strange segfault with r600g on top of lastest git,
git bisect pointed to gallium: implement bounds checking for constant buffers
My
On 07/24/2010 11:36 AM, Tom Stellard wrote:
On Fri, Jul 23, 2010 at 08:09:46PM -0400, Jerome Glisse wrote:
On 07/23/2010 07:11 PM, Corbin Simpson wrote:
On Fri, Jul 23, 2010 at 3:49 PM, Jerome Glissegli...@freedesktop.org wrote:
Just heads up on r600g plan, i removed
On 07/24/2010 09:46 AM, Stephan Schmid wrote:
Hello,
i've created a patch that implements the LIT instuction in r600g
Cheers,
Stephan Schmid
Avoid the // for comment otherwise looks good will test
on monday.
Please resend using git format-patch and make sure you
use proper GIT AUTHOR,
On Sun, Aug 22, 2010 at 08:13:45PM +0200, Marek Olšák wrote:
On Sun, Aug 22, 2010 at 6:58 PM, Corbin Simpson
mostawesomed...@gmail.comwrote:
I'm not so sure about this series, because (a) it should be possible
to come up with something that works for both EGL backends (b) we
haven't
On Fri, Sep 24, 2010 at 8:08 PM, Eric Anholt e...@anholt.net wrote:
One of the uglier bits of the classic drivers, in my opinion, is the
ChooseTexFormat hook. Most drivers are trying to get to a similar set
of formats, and using similar fallbacks for unavailable formats.
Worse, they need to
On Sat, Sep 25, 2010 at 10:11 AM, Bas Nieuwenhuizen
b...@basnieuwenhuizen.nl wrote:
These patches fix piglit test occlusion-query-discard in the new design of
r600g.
The evergreen code is only compile tested as I don't have one.
Bas Nieuwenhuizen (3):
r600g: set ENABLE_KILL in the shader
On Sat, Sep 25, 2010 at 4:08 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Sat, Sep 25, 2010 at 10:11 AM, Bas Nieuwenhuizen
b...@basnieuwenhuizen.nl wrote:
These patches fix piglit test occlusion-query-discard in the new design of
r600g.
The evergreen code is only compile tested as I don't
Hi,
So new design is on parity with old design from piglit point of view,
so i am now
switching new design to be default. If nothings come up in the coming day i will
remove the old design and do some renaming of files :
winsys r600_state2.c - r600_hw_context.c
winsys evergreen_state.c -
2010/9/29 Michel Dänzer mic...@daenzer.net:
On Mit, 2010-09-29 at 11:49 +0100, Keith Whitwell wrote:
On Wed, 2010-09-29 at 03:35 -0700, Michel Dänzer wrote:
On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote:
- use score for placing bo, bo placement will be recorded in bo
On Tue, Oct 5, 2010 at 12:10 PM, Bas Nieuwenhuizen
b...@basnieuwenhuizen.nl wrote:
Emitting the dirty blocks sometimes accounted for about 30% percent of the
time spent in r600_dri.so, so I made a seperate array with only the dirty
blocks.
---
src/gallium/drivers/r600/r600.h
On Wed, Oct 6, 2010 at 5:19 AM, Keith Whitwell kei...@vmware.com wrote:
Yes, I belive so (at work now, so can't double-check). I started with
the top of tree last night, which is well past this commit.
Keith
Strange i am using rv710 without issue, however my rs780 seems to have
similar issue
On Thu, Oct 14, 2010 at 12:00 PM, Keith Whitwell
keith.whitw...@gmail.com wrote:
Dave,
Sorry for being confusing, but this patch doesn't actually work - this
is what I think should be happening, but at the moment I have to
return early to avoid segfaults on unbinding constant buffers, ie:
+
On Fri, Oct 15, 2010 at 7:44 PM, John Kessenich jo...@lunarg.com wrote:
Hi,
LunarG has decided to work on an open source, long-term, highly-functional,
and modular shader and kernel compiler stack. Attached is our high-level
proposal for this compiler architecture (LunarGLASS). We would like
On Wed, Nov 10, 2010 at 2:36 AM, Russell Shaw rjs...@netspace.net.au wrote:
Hi,
I compiled mesa from sources.
In mesa/src/driclient/src/XF86dri.c, if i use the
api to make a drawable, how can i find the buffer
pixel format?
See my other reply on the wayland mailing list but i think you are
current context.
Agree.
Cheers,
Jerome Glisse
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
and remove SCons.
On MSVC CMake generates a Visual studio project, so we could remove the
existing (and broken) project files too.
Let me know if there any objections/suggestions.
Jose
Looks good to me
Cheers,
Jerome Glisse
___
mesa-dev mailing list
than any blit helped move.
Anyway this was my initial thinking when doing the code.
Cheers,
Jerome Glisse
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
always honor those placement
(ie if driver is told bo is in vram bo will always be in vram) of
course this lead to more frequent vram bo allocation failure but hey
we can't pretend we have Gigs of vram when we only have few hundred
megs.
Cheers,
Jerome Glisse
,
Jerome Glisse
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
on and i wouldn't want to loose it.
Cheers,
Jerome Glisse
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Nov 12, 2010 at 7:18 PM, Zack Rusin za...@vmware.com wrote:
On Friday 12 November 2010 14:55:08 Jerome Glisse wrote:
Hi Jerome,
It's a bit tough to answer your email because it's composed of several quite
distinct parts (benchmarking, gallium, new state trackers, ttm
On Fri, Nov 12, 2010 at 10:50 PM, Francisco Jerez curroje...@riseup.net wrote:
Jerome Glisse j.gli...@gmail.com writes:
Hi,
[...]
In order to find out which part of the stack is underperforming in
front of state changes I slowly disabled layer starting by the bottom
(which is the only way
, at least from number i gather with some
games).
Cheers,
Jerome Glisse
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Nov 16, 2010 at 2:38 PM, Roland Scheidegger srol...@vmware.com wrote:
On 16.11.2010 20:21, Jerome Glisse wrote:
Hi,
So i looked a bit more at what path we should try to optimize in the
mesa/gallium/pipe infrastructure. Here are some number gathers from
games :
drawcall / ps
On Tue, Nov 16, 2010 at 3:27 PM, Roland Scheidegger srol...@vmware.com wrote:
On 16.11.2010 20:59, Jerome Glisse wrote:
On Tue, Nov 16, 2010 at 2:38 PM, Roland Scheidegger srol...@vmware.com
wrote:
On 16.11.2010 20:21, Jerome Glisse wrote:
Hi,
So i looked a bit more at what path we should
On Tue, Nov 16, 2010 at 3:51 PM, Jakob Bornecrantz wallbra...@gmail.com wrote:
On Tue, Nov 16, 2010 at 7:21 PM, Jerome Glisse j.gli...@gmail.com wrote:
Hi,
So i looked a bit more at what path we should try to optimize in the
mesa/gallium/pipe infrastructure. Here are some number gathers from
On Tue, Nov 16, 2010 at 6:06 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
On Tue, Nov 16, 2010 at 9:17 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Nov 16, 2010 at 3:51 PM, Jakob Bornecrantz wallbra...@gmail.com
wrote:
On Tue, Nov 16, 2010 at 7:21 PM, Jerome Glisse j.gli
On Tue, Nov 16, 2010 at 9:15 PM, Zack Rusin za...@vmware.com wrote:
On Tuesday 16 November 2010 20:26:03 Jerome Glisse wrote:
Anyway my point is that here the gl state tracker is not to blame,
it's only the fact that real application lead to a lot of cso
activities and i am not convinced
On Tue, Nov 16, 2010 at 9:43 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Nov 16, 2010 at 9:15 PM, Zack Rusin za...@vmware.com wrote:
On Tuesday 16 November 2010 20:26:03 Jerome Glisse wrote:
Anyway my point is that here the gl state tracker is not to blame,
it's only the fact that real
1 - 100 of 162 matches
Mail list logo
