I just wanted to say "thanks!" to everyone who has been taking part of
Mesa3D. I have an R500-based card and it is good to know that it still
functions on Linux even after ATI/AMD decided it was too old too support.
Not only that, it still receives improvements from Mesa. I even hear
whispers that
Marek,
On Tuesday, May 03, 2011 01:33:17 you wrote:
> 2011/5/2 Mathias Fröhlich :
> > I have again spent some more tries with different kinds of flushes on the
> > rv635. What helps for the mipmap problem here is emitting a
> > texture_barrier as well as flushing anything that covers the whole
>
-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 b/bin
-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
> --- a/bin/ext
https://bugs.freedesktop.org/show_bug.cgi?id=36738
--- Comment #3 from Iaroslav 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 llvm_pipeline_generic (middle=
On May 2, 2011 11:09 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
> --- a/bin/extract_git_sha1
> +++ b/bin/extract_git_sha1
On May 2, 2011 11:08 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 b/bin/extract_git_sha1
> index e6e6731..5e635d4
On Mon, May 2, 2011 at 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
>> wrote:
>>> Am 02.05.2011 19:20, schrieb Marek Olšák:
On Mon, May 2, 2011 at 5:53 PM, Brian Paul wrote:
> On 05/02/2011 08:40 A
2011/5/2 Mathias Fröhlich :
> I have again spent some more tries with different kinds of flushes on the
> rv635.
> What helps for the mipmap problem here is emitting a texture_barrier as well
> as flushing anything that covers the whole memory range and more than two
> arbitrary color buffers. !?!
On 05/02/11 22:20, Mathias Fröhlich wrote:
> Hi,
>
> On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote:
>>> So, I know that this patch is not applicable, since it does not account
>>> for sufficient cs space for this additional flush. Also it is probably
>>> too croase in face of the fineg
---
src/mesa/main/errors.c | 24 +---
1 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index ed0e7b7..d910092 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -543,6 +543,17 @@ _mesa_init_errors
This state is needed for deciding whether or not to log
application messages with IDs that haven't been specifically
passed to glDebugMessageControlARB yet.
State for each individual ID number ever passed to
glDebugMessageControlARB (per-context) still needs to be added.
---
src/mesa/main/errors.
---
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,
OT
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/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
+++ b/src/mesa/main/error
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 b/src/mesa/main/a
---
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 +++
src/mesa/
---
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 insertions(+
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
--- a/s
---
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
dif
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/gl_AP
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 n
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
>> wrote:
>>> Am 02.05.2011 19:20, schrieb Marek Olšák:
On Mon, May 2, 2011 at 5:53 PM, Brian Paul wrote:
> On 05/02/2011 08:40 AM, Marek O
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
> 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. Althoug
Am 02.05.2011 20:26, schrieb Marek Olšák:
> On Mon, May 2, 2011 at 7:49 PM, Roland Scheidegger wrote:
>> Am 02.05.2011 19:20, schrieb Marek Olšák:
>>> On Mon, May 2, 2011 at 5:53 PM, Brian Paul wrote:
On 05/02/2011 08:40 AM, Marek Olšák wrote:
>
> On Mon, May 2, 2011 at 3:47 PM, Bria
2011/5/2 Mathias Fröhlich :
>
> Hi,
>
> On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote:
>> > So, I know that this patch is not applicable, since it does not account
>> > for sufficient cs space for this additional flush. Also it is probably
>> > too croase in face of the finegrained bo
Hi,
On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote:
> > So, I know that this patch is not applicable, since it does not account
> > for sufficient cs space for this additional flush. Also it is probably
> > too croase in face of the finegrained bo flush logic.
>
> Actually I think it
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
>
> Begin implementing HiZ for Gen >= 5. Since it's i
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
https://bugs.freedesktop.org/show_bug.cgi?id=36738
--- Comment #2 from Iaroslav 2011-05-02 12:36:20 PDT ---
run with gdb
(gdb) up
#1 0xadc22a91 in llvm_pipeline_generic (middle=0xac40f000,
fetch_info=,
prim_info=0xbfff62fc) at draw/draw_pt_fetch_shade_pipeline_llvm.c:246
246 in draw/d
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_crt
On Mon, May 02, 2011 at 03:11:00PM +0200, Daniel Vetter wrote:
> On Mon, May 2, 2011 at 2:56 PM, Benjamin Franzke
> 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 &
On 05/02/2011 08:57 AM, Brian Paul wrote:
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
On Mon, May 2, 2011 at 7:49 PM, Roland Scheidegger wrote:
> Am 02.05.2011 19:20, schrieb Marek Olšák:
>> On Mon, May 2, 2011 at 5:53 PM, Brian Paul wrote:
>>> On 05/02/2011 08:40 AM, Marek Olšák wrote:
On Mon, May 2, 2011 at 3:47 PM, Brian Paul wrote:
>
> On 05/02/2011 07:03 AM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2011 08:50 AM, Marek Olšák wrote:
> It's just an alias of the ARB variant with some GLSL compiler changes.
Other than the test suggestion (below) and Brian's comment about the
stand-alone compiler:
Reviewed-by: Ian Romanick
> ---
> src/gl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2011 08:57 AM, Brian Paul wrote:
> 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_ext
---
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
+++ b/bin/extract_git_sha1
@@ -3,6 +3,10 @@ if [ ! -f src/mesa/main/git_sha1.h ]; then
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 e6e6731..5e635d4 100755
--- a/bin/extract_git_sha1
+++ b/bin/extract_git_sha1
@@ -1
On Mon, 2 May 2011 10:56:55 -0700
Corbin Simpson wrote:
> I think that perhaps a good question to consider would be: What other
> filters might go into the PP queue? Is there anything besides
> anti-aliasing and color correction? (I'm trying to get a discussion
> started...)
>
> ~ C.
Well, I th
On Mon, May 02, 2011 at 06:25:31AM -0700, Dan Nicholson wrote:
> On Sun, May 1, 2011 at 2:53 PM, Marcin Slusarz
> wrote:
> > Less recompiles...
>
> Good idea. Couple nits.
>
> > ---
> > bin/extract_git_sha1 | 8 ++--
> > 1 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --gi
On Mon, May 2, 2011 at 4:01 AM, Lauri Kasanen 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 ways:
>
Am 02.05.2011 19:20, schrieb Marek Olšák:
> On Mon, May 2, 2011 at 5:53 PM, Brian Paul wrote:
>> On 05/02/2011 08:40 AM, Marek Olšák wrote:
>>>
>>> On Mon, May 2, 2011 at 3:47 PM, Brian Paul wrote:
On 05/02/2011 07:03 AM, Marek Olšák wrote:
>
> ---
> src/gallium/include/pip
Am 02.05.2011 19:13, schrieb Ian Romanick:
> On 05/02/2011 09:19 AM, Roland Scheidegger wrote:
>> Am 02.05.2011 16:40, schrieb Marek Olaák:
>>> On Mon, May 2, 2011 at 3:47 PM, Brian Paul wrote:
On 05/02/2011 07:03 AM, Marek Olaák wrote:
>
> ---
> src/gallium/include/pipe/p_define
https://bugs.freedesktop.org/show_bug.cgi?id=36738
Iaroslav changed:
What|Removed |Added
Severity|major |normal
Component|Drivers/Gallium/r30
On Mon, May 2, 2011 at 5:53 PM, Brian Paul wrote:
> On 05/02/2011 08:40 AM, Marek Olšák wrote:
>>
>> On Mon, May 2, 2011 at 3:47 PM, Brian Paul wrote:
>>>
>>> On 05/02/2011 07:03 AM, Marek Olšák wrote:
---
src/gallium/include/pipe/p_defines.h | 1 +
src/gallium/incl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2011 08:29 AM, Marek Olšák wrote:
> On Mon, May 2, 2011 at 3:47 PM, Brian Paul 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/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2011 09:19 AM, Roland Scheidegger wrote:
> Am 02.05.2011 16:40, schrieb Marek Olšák:
>> On Mon, May 2, 2011 at 3:47 PM, Brian Paul wrote:
>>> On 05/02/2011 07:03 AM, Marek Olšák wrote:
---
src/gallium/include/pipe/p_defines.h
-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/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/27/2011 08:23 PM, Brian Paul wrote:
> On Tue, Apr 26, 2011 at 12:26 AM, Bryan Cain 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. Although it is sti
-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
> wrote:
>> Less recompiles...
>
> Good idea. Couple nits.
I never noticed this before. I use ccache. Since the preprocessed file
doesn't change, it doe
https://bugs.freedesktop.org/show_bug.cgi?id=36761
Lauri Kasanen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Am 02.05.2011 16:40, schrieb Marek Olšák:
> On Mon, May 2, 2011 at 3:47 PM, Brian Paul 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
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
src/mesa/main/exten
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 li
On 05/02/2011 09:29 AM, Marek Olšák wrote:
On Mon, May 2, 2011 at 3:47 PM, Brian Paul 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
On 05/02/2011 08:40 AM, Marek Olšák wrote:
On Mon, May 2, 2011 at 3:47 PM, Brian Paul 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
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 insert
https://bugs.freedesktop.org/show_bug.cgi?id=36761
--- Comment #5 from Brian Paul 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 the count parameter is un
On Mon, May 2, 2011 at 3:47 PM, Brian Paul 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 insertions(+), 0
https://bugs.freedesktop.org/show_bug.cgi?id=36761
--- Comment #4 from Lauri Kasanen 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 working (I
can see the effe
https://bugs.freedesktop.org/show_bug.cgi?id=36761
--- Comment #3 from Brian Paul 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 to be done when 'progra
https://bugs.freedesktop.org/show_bug.cgi?id=36761
--- Comment #2 from Lauri Kasanen 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 8.
To check this I
On Mon, May 2, 2011 at 3:47 PM, Brian Paul 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 +-
>> src/mesa/stat
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
b/src/gal
On Mon, May 2, 2011 at 10:05 AM, Jeffrey Collins 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
> numerous change
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 xf86-vide
https://bugs.freedesktop.org/show_bug.cgi?id=36761
--- Comment #1 from Brian Paul 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,
GLsizei *count, GLuint
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 b/src/mesa/main/en
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 Sun, May 1, 2011 at 2:53 PM, Marcin Slusarz 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 e6e6731..fc7bf85 100755
> ---
On Mon, May 2, 2011 at 2:56 PM, Benjamin Franzke
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 re-checking the code. On
---
src/mesa/main/extensions.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index e0562cc..beec70a 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -259,6 +259,7 @@ static const struct ex
---
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 src/mapi/glapi/gen/AMD_draw_buff
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/
---
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
--- a/src/galli
---
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 a/src/ga
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
--- a/src/m
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
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 :
> On Sun, May 1, 2011 at 11:59 PM, Marcin Slusarz
> wrote:
>> We need to distinguish sur
On Sun, May 1, 2011 at 11:59 PM, Marcin Slusarz
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 Vetter
--
Daniel Vetter
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 objec
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 o
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: me
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
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
85 matches
Mail list logo
