On Mon, 2011-05-02 at 00:01 +0200, Marcin Slusarz wrote:
We need cursor data to land in destination buffer before drmModeSetCursor.
It fixes cursor lag at least on nv50.
---
src/gallium/state_trackers/xorg/xorg_crtc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
On Mon, 2011-05-02 at 00:00 +0200, Marcin Slusarz wrote:
It's not used for anything useful.
---
src/gallium/state_trackers/xorg/xorg_crtc.c| 13 -
src/gallium/state_trackers/xorg/xorg_driver.c |5 -
src/gallium/state_trackers/xorg/xorg_tracker.h |1 -
3 files
On Son, 2011-05-01 at 23:51 +0200, Marcin Slusarz wrote:
---
src/gallium/state_trackers/xorg/xorg_driver.c |6 +++---
src/gallium/state_trackers/xorg/xorg_exa.c|2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_driver.c
https://bugs.freedesktop.org/show_bug.cgi?id=36761
Summary: glGetAttachedObjects ignores maxcount
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority:
Hi everyone
I'm the student working on integrating MLAA for this summer. I'm mostly on irc,
but to get wider feedback on this, posting to the list.
What are your opinions on the post-prosessing queue?
I thought of two ways:
1) It's expected to be simple enough, in that there's only one sane
On Sam, 2011-04-30 at 08:07 +0200, Mathias Fröhlich wrote:
For creating and reusing already existing buffer objects,
take care of the placement domains.
Have a little more finegrained usage to placement mapping.
This change does not account for the real location of the
buffer object for
On Sun, May 1, 2011 at 11:59 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
We need to distinguish surfaces for mouse cursors from scanouts, because nv50
hardware display engine ignores tiling flags.
i915 seems to have similar needs, so fix it too.
For the i915g part:
Acked-by: Daniel
I think in i915g the CURSOR flag should be used in i9x5_scanout_layout
for the special case for cursors as well, instead of only checking
only pt-width0 == 64 pt-height0 == 64.
2011/5/2 Daniel Vetter dan...@ffwll.ch:
On Sun, May 1, 2011 at 11:59 PM, Marcin Slusarz
marcin.slus...@gmail.com
Hi,
this series adds ARB_seamless_cube_map to Gallium and implements one missing
piece in mesa/main. There is a new state seamless_cube_map in
pipe_rasterizer_state and a new CAP. It affects all samplers in all shader
stages (vertex, geometry, fragment). There is only r600g support for now and
Otherwise there would be no way to know whether the state has been changed.
---
src/mesa/main/enable.c |1 +
src/mesa/main/mtypes.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index 2ec19c8..dbc6d21 100644
---
---
src/gallium/include/pipe/p_defines.h|1 +
src/gallium/include/pipe/p_state.h |1 +
src/mesa/state_tracker/st_atom_rasterizer.c |6 +-
src/mesa/state_tracker/st_extensions.c |4
4 files changed, 11 insertions(+), 1 deletions(-)
diff --git
---
src/gallium/drivers/r600/r600_state.c |9 +++--
src/gallium/drivers/r600/r600d.h |3 +++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index 1c27f88..6a7a658 100644
---
The Gallium state bit is part of pipe_rasterizer_state, but the hardware
state is per-sampler. The idea here is to change the state bit in sampler
state registers based on the currently-bound rasterizer state.
---
src/gallium/drivers/r600/evergreen_state.c | 45 +-
---
src/mapi/glapi/gen/AMD_draw_buffers_blend.xml | 38 +
src/mapi/glapi/gen/Makefile |1 +
src/mapi/glapi/gen/gl_API.xml |1 +
3 files changed, 40 insertions(+), 0 deletions(-)
create mode 100644
On Mon, May 2, 2011 at 2:56 PM, Benjamin Franzke
benjaminfran...@googlemail.com wrote:
I think in i915g the CURSOR flag should be used in i9x5_scanout_layout
for the special case for cursors as well, instead of only checking
only pt-width0 == 64 pt-height0 == 64.
Oops, so much for actually
On Sun, May 1, 2011 at 2:53 PM, Marcin Slusarz marcin.slus...@gmail.com wrote:
Less recompiles...
Good idea. Couple nits.
---
bin/extract_git_sha1 | 8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1
index
On 05/02/2011 07:03 AM, Marek Olšák wrote:
---
src/gallium/include/pipe/p_defines.h|1 +
src/gallium/include/pipe/p_state.h |1 +
src/mesa/state_tracker/st_atom_rasterizer.c |6 +-
src/mesa/state_tracker/st_extensions.c |4
4 files changed, 11
On 05/02/2011 07:03 AM, Marek Olšák wrote:
Otherwise there would be no way to know whether the state has been changed.
---
src/mesa/main/enable.c |1 +
src/mesa/main/mtypes.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/enable.c
https://bugs.freedesktop.org/show_bug.cgi?id=36761
--- Comment #1 from Brian Paul brian.e.p...@gmail.com 2011-05-02 06:58:44 PDT
---
Are you sure about this? The code is as follows:
static void
get_attached_shaders(struct gl_context *ctx, GLuint program, GLsizei maxCount,
I am interested in Mesa running on a P2020 Power Architecture system. What is
the current state of Mesa for big endian systems? Is there a branch I should be
looking at? I have noticed on the main line branch there are numerous changes
for big endian systems, I have recent versions of
On Mon, May 2, 2011 at 10:05 AM, Jeffrey Collins tilde...@hotmail.com wrote:
I am interested in Mesa running on a P2020 Power Architecture system. What
is the current state of Mesa for big endian systems? Is there a branch I
should be looking at? I have noticed on the main line branch there are
On 05/01/2011 06:07 PM, Marek Olšák wrote:
sizeof(struct pipe_rasterizer_state):
Before: 32 bytes
After: 28 bytes
---
src/gallium/include/pipe/p_state.h | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/gallium/include/pipe/p_state.h
On Mon, May 2, 2011 at 3:47 PM, Brian Paul bri...@vmware.com wrote:
On 05/02/2011 07:03 AM, Marek Olšák wrote:
---
src/gallium/include/pipe/p_defines.h | 1 +
src/gallium/include/pipe/p_state.h | 1 +
src/mesa/state_tracker/st_atom_rasterizer.c | 6 +-
https://bugs.freedesktop.org/show_bug.cgi?id=36761
--- Comment #2 from Lauri Kasanen cur...@operamail.com 2011-05-02 07:44:26
PDT ---
Yes, gdb points the segfault to this line in Irrlicht source:
Driver-extGlDeleteObject(shaders[i]);
Which segfaults because it's trying to access the array beyond
https://bugs.freedesktop.org/show_bug.cgi?id=36761
--- Comment #3 from Brian Paul brian.e.p...@gmail.com 2011-05-02 07:48:27 PDT
---
Perhaps 'program' doesn't name an existing shader program. In that case the
count parameter will not get set. I'll have to check the spec to see what's
supposed
https://bugs.freedesktop.org/show_bug.cgi?id=36761
--- Comment #4 from Lauri Kasanen cur...@operamail.com 2011-05-02 08:10:52
PDT ---
You're right, when I set count = 0 before the call to GetAttachedObjects, it
stays 0.
However, this is the only shader program created, and it's very much
On Mon, May 2, 2011 at 3:47 PM, Brian Paul bri...@vmware.com wrote:
On 05/02/2011 07:03 AM, Marek Olšák wrote:
Otherwise there would be no way to know whether the state has been
changed.
---
src/mesa/main/enable.c | 1 +
src/mesa/main/mtypes.h | 1 +
2 files changed, 2
https://bugs.freedesktop.org/show_bug.cgi?id=36761
--- Comment #5 from Brian Paul brian.e.p...@gmail.com 2011-05-02 08:45:49 PDT
---
Can you call glGetError() before and after the call to glGetAttachedObjects()
to see if GL_INVALID_VALUE is generated? That's what Mesa and NVIDIA both do
(and
It's just an alias of the ARB variant with some GLSL compiler changes.
---
src/glsl/glsl_parser_extras.cpp | 10 ++
src/glsl/glsl_parser_extras.h |2 ++
src/glsl/ir_variable.cpp| 20
src/mesa/main/extensions.c |1 +
4 files changed, 33
On 05/02/2011 08:40 AM, Marek Olšák wrote:
On Mon, May 2, 2011 at 3:47 PM, Brian Paulbri...@vmware.com wrote:
On 05/02/2011 07:03 AM, Marek Olšák wrote:
---
src/gallium/include/pipe/p_defines.h|1 +
src/gallium/include/pipe/p_state.h |1 +
On 05/02/2011 09:29 AM, Marek Olšák wrote:
On Mon, May 2, 2011 at 3:47 PM, Brian Paulbri...@vmware.com wrote:
On 05/02/2011 07:03 AM, Marek Olšák wrote:
Otherwise there would be no way to know whether the state has been
changed.
---
src/mesa/main/enable.c |1 +
src/mesa/main/mtypes.h
On Sun, 2011-05-01 at 15:28 -0400, Alex Deucher wrote:
Please file bugs. Also, test the latest r600g code from git if you
haven't already.
Great, will do! :)
--
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22
___
mesa-dev mailing
On 05/02/2011 09:50 AM, Marek Olšák wrote:
It's just an alias of the ARB variant with some GLSL compiler changes.
---
src/glsl/glsl_parser_extras.cpp | 10 ++
src/glsl/glsl_parser_extras.h |2 ++
src/glsl/ir_variable.cpp| 20
Am 02.05.2011 16:40, schrieb Marek Olšák:
On Mon, May 2, 2011 at 3:47 PM, Brian Paul bri...@vmware.com wrote:
On 05/02/2011 07:03 AM, Marek Olšák wrote:
---
src/gallium/include/pipe/p_defines.h|1 +
src/gallium/include/pipe/p_state.h |1 +
https://bugs.freedesktop.org/show_bug.cgi?id=36761
Lauri Kasanen cur...@operamail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2011 06:25 AM, Dan Nicholson wrote:
On Sun, May 1, 2011 at 2:53 PM, Marcin Slusarz marcin.slus...@gmail.com
wrote:
Less recompiles...
Good idea. Couple nits.
I never noticed this before. I use ccache. Since the preprocessed file
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2011 06:47 AM, Brian Paul wrote:
On 05/02/2011 07:03 AM, Marek Olšák wrote:
---
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index 0c1f509..26e8a8e 100644
--- a/src/gallium/include/pipe/p_state.h
On Mon, May 2, 2011 at 4:01 AM, Lauri Kasanen c...@gmx.com wrote:
Hi everyone
I'm the student working on integrating MLAA for this summer. I'm mostly on
irc, but to get wider feedback on this, posting to the list.
What are your opinions on the post-prosessing queue?
I thought of two
On Mon, May 02, 2011 at 08:57:25AM +0200, Michel Dänzer wrote:
On Mon, 2011-05-02 at 00:01 +0200, Marcin Slusarz wrote:
We need cursor data to land in destination buffer before drmModeSetCursor.
It fixes cursor lag at least on nv50.
---
src/gallium/state_trackers/xorg/xorg_crtc.c |1
https://bugs.freedesktop.org/show_bug.cgi?id=36738
--- Comment #2 from Iaroslav pontost...@gmail.com 2011-05-02 12:36:20 PDT ---
run with gdb
(gdb) up
#1 0xadc22a91 in llvm_pipeline_generic (middle=0xac40f000,
fetch_info=optimized out,
prim_info=0xbfff62fc) at
Hi,
Thanks for the comments.
On Monday, May 02, 2011 13:14:02 Michel Dänzer wrote:
+ if(bo-domains != domains) {
+ return 0;
+ }
I wonder if this test isn't too strict, i.e. if there aren't cases where
the values aren't identical, but where the BO should
I'm NAK'ing this patchset. I'm removing the context-global hiz
enablement field (intel_context.use_hiz) and making hiz enablement a
property of individual renderbuffers.
On 04/29/2011 06:04 PM, c...@chad-versace.us wrote:
From: Chad Versace chad.vers...@intel.com
Begin implementing HiZ for
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 should
2011/5/2 Mathias Fröhlich mathias.froehl...@gmx.net:
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
Am 02.05.2011 20:26, schrieb Marek Olšák:
On Mon, May 2, 2011 at 7:49 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 02.05.2011 19:20, schrieb Marek Olšák:
On Mon, May 2, 2011 at 5:53 PM, Brian Paul bri...@vmware.com wrote:
On 05/02/2011 08:40 AM, Marek Olšák wrote:
On Mon, May 2, 2011
On 05/02/2011 11:55 AM, Ian Romanick wrote:
On 04/27/2011 08:23 PM, Brian Paul wrote:
On Tue, Apr 26, 2011 at 12:26 AM, Bryan Cain bryanca...@gmail.com
wrote:
Hi,
In the last week or so, I've been working on a direct translator from
GLSL IR to TGSI that does not go through Mesa IR.
On 05/02/2011 11:35 PM, Roland Scheidegger wrote:
Am 02.05.2011 20:26, schrieb Marek Olšák:
On Mon, May 2, 2011 at 7:49 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 02.05.2011 19:20, schrieb Marek Olšák:
On Mon, May 2, 2011 at 5:53 PM, Brian Paul bri...@vmware.com wrote:
On
git repo:
https://github.com/nobled/mesa.git
(branch: arb_debug_output, rebased on bd661a933b18fccd7102d05932774ee61a90ec9e)
web interface:
https://github.com/nobled/mesa/commits/arb_debug_output
spec:
http://www.opengl.org/registry/specs/ARB/debug_output.txt
This series adds almost everything
glGetTexImage, for example, has no width/height/depth parameters.
Also, copy some missing parameter info from the original versions
of certain functions over to their ARB_robustness counterparts.
---
src/mapi/glapi/gen/ARB_robustness.xml | 26 +-
---
src/mapi/glapi/gen/ARB_debug_output.xml | 93 +++
src/mapi/glapi/gen/Makefile |1 +
src/mapi/glapi/gen/gl_API.xml |2 +
3 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 src/mapi/glapi/gen/ARB_debug_output.xml
This lets code outside of imports.c use vsnprintf's functionality.
---
src/mesa/main/imports.c |7 +++
src/mesa/main/imports.h |3 +++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index f262b25..f971338 100644
---
---
src/mesa/SConscript |1 +
src/mesa/main/descrip.mms |3 +
src/mesa/main/errors.c| 276 +
src/mesa/main/imports.c | 238 --
src/mesa/sources.mak |1 +
5 files changed, 281
---
src/mesa/main/context.c|1 +
src/mesa/main/enable.c |5 +
src/mesa/main/errors.c | 10 ++
src/mesa/main/extensions.c |1 +
src/mesa/main/get.c|7 +++
src/mesa/main/getstring.c |6 ++
src/mesa/main/imports.h|3 +++
They're not actually exported yet.
---
src/mesa/main/api_exec.c | 12 ++-
src/mesa/main/errors.c | 262 ++
src/mesa/main/errors.h |4 +
3 files changed, 274 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/api_exec.c
---
src/mesa/main/errors.c |2 +-
src/mesa/main/mtypes.h | 32 +++-
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index c953fbf..9d74a05 100644
--- a/src/mesa/main/errors.c
+++
Controlling the output of client-provided messages
isn't done yet.
---
src/mesa/main/errors.c | 110
1 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index 9d74a05..e304184 100644
---
---
src/mesa/main/mtypes.h | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 41f6470..d381719 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3194,6 +3194,13 @@ OTHER_ERROR_OUT_OF_MEMORY,
On May 2, 2011 11:08 AM, Marcin Slusarz marcin.slus...@gmail.com wrote:
Less recompiles...
---
bin/extract_git_sha1 | 10 --
src/mesa/main/.gitignore |1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1
index
On May 2, 2011 11:09 AM, Marcin Slusarz marcin.slus...@gmail.com wrote:
---
bin/extract_git_sha1 |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1
index 5e635d4..8283870 100755
--- a/bin/extract_git_sha1
+++
https://bugs.freedesktop.org/show_bug.cgi?id=36738
--- Comment #3 from Iaroslav pontost...@gmail.com 2011-05-02 22:44:22 PDT ---
with llvmpipe
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xabf7aef5 in ?? ()
(gdb) bt
#0 0xabf7aef5 in ?? ()
#1 0xadb41271 in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2011 11:07 AM, Marcin Slusarz wrote:
---
bin/extract_git_sha1 |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1
index 5e635d4..8283870 100755
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2011 11:06 AM, Marcin Slusarz wrote:
Less recompiles...
---
bin/extract_git_sha1 | 10 --
src/mesa/main/.gitignore |1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/bin/extract_git_sha1
Marek,
On Tuesday, May 03, 2011 01:33:17 you wrote:
2011/5/2 Mathias Fröhlich mathias.froehl...@gmx.net:
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
63 matches
Mail list logo
