From: Ian Romanick
Nothing in Mesa supports color-index textures, and most of the other
infrastructure that could allow such support has already been removed.
This puts the final nail in the coffin.
---
src/mesa/drivers/dri/common/texmem.c |1 -
src/mesa/drivers/dri/r200/r200_texsta
From: Ian Romanick
This came from the "kill it with fire" discussion at XDS 2010.
---
src/mesa/drivers/dri/nouveau/nouveau_texture.c |9 -
src/mesa/drivers/dri/nouveau/nv04_surface.c|4
src/mesa/drivers/dri/nouveau/nv10_state_tex.c |3 ---
src/mesa/drivers/dri/nouve
https://bugs.freedesktop.org/show_bug.cgi?id=40401
Pavel Ondračka changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NOTOURBUG
https://bugs.freedesktop.org/show_bug.cgi?id=40401
Pavel Ondračka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Fri, Aug 26, 2011 at 4:03 PM, Christopher James Halse Rogers
wrote:
> Eric was wondering why the --enable-shared-dricore option also built
> libglsl.so.
> This provided the activation energy to fix it, and also extend dricore to the
> gallium drivers.
I wonder if libdricore.so can also be shar
On Sat, Aug 27, 2011 at 9:53 AM, Chad Versace wrote:
> In order that the autoconf and Android build can share the same source
> lists, move the lists from
> src/mesa/drivers/dri/Makefile.defines
> into
> src/mesa/drivers/dri/common/Makefile.sources
>
> I would like for Android to just reuse Make
On Sat, Aug 27, 2011 at 9:54 AM, Chad Versace wrote:
> This just gets the driver to build. I have not yet tested if the driver
> actually works.
>
> Signed-off-by: Chad Versace
> ---
> Android.mk | 3 +-
> src/mesa/drivers/dri/Android.mk | 61
> ++
On Sat, Aug 27, 2011 at 9:54 AM, Chad Versace wrote:
> libmesa_dri_common is a static library that contains the sources in
> src/mesa/drivers/dri/common. Each DRI driver should link to it.
>
> Signed-off-by: Chad Versace
> ---
> Android.mk | 1 +
> src/mesa/drivers
On Sat, Aug 27, 2011 at 9:53 AM, Chad Versace wrote:
> In src/mesa/Android.mk, it is non-trivial to determine which variables are
> imported by `include sources.mak`. So document them.
>
> Signed-off-by: Chad Versace
> ---
> src/mesa/Android.mk | 5 +
> 1 files changed, 5 insertions(+), 0
On Sat, Aug 27, 2011 at 9:53 AM, Chad Versace wrote:
> libmesa_dricore is analogous to the libdricore built by the Autoconf
> build.
>
> Signed-off-by: Chad Versace
With the visibility change, this patch is
Reviewed-by: Chia-I Wu
> ---
> src/mesa/Android.mk | 35 +
On Sat, Aug 27, 2011 at 9:53 AM, Chad Versace wrote:
> If you attempt to link together libmesa_dricore.so from object files built
> with
> visibility=hidden, then the library is useless. It exposes no symbols.
>
> Signed-off-by: Chad Versace
> ---
> Android.common.mk | 1 -
> 1 files changed
On Sat, Aug 27, 2011 at 3:12 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> When generating dispatch templates, emit the '(void) blah;' magic to
> make GCC happy. This reduces a lot of warning spam if you build with
> -Wunused-parameter or -Wextra.
It looks good to me.
> Cc: Chia-I Wu
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=40397
Michael Zhou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
This fixes all of the piglit regressions in softpipe when native integers are
enabled.
---
src/mesa/main/uniforms.c |8 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 45 ++--
2 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/src/m
This just gets the driver to build. I have not yet tested if the driver
actually works.
Signed-off-by: Chad Versace
---
Android.mk |3 +-
src/mesa/drivers/dri/Android.mk | 61 ++
src/mesa/drivers/dri/i965/Android.mk | 61
libmesa_dri_common is a static library that contains the sources in
src/mesa/drivers/dri/common. Each DRI driver should link to it.
Signed-off-by: Chad Versace
---
Android.mk |1 +
src/mesa/drivers/dri/common/Android.mk | 49
2 f
Add $(TOP)/src/mesa to include paths and replace each occurence of
#include "../glsl/*.h"
with
#include "glsl/*.h"
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/Makefile |1 +
src/mesa/drivers/dri/i965/brw_clip.c |2 +-
src/mesa/drivers/dri/i
Stop building driverfuncs.c twice for each DRI driver. driverfuncs.c is
included in both libmesa.a and in
src/mesa/drivers/dri/Makefiles.defines:COMMON_SOURCES, so remove it from
COMMON_SOURCES.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/Makefile.defines |1 -
1 files changed, 0 in
In order that the autoconf and Android build can share the same source
lists, move the lists from
src/mesa/drivers/dri/Makefile.defines
into
src/mesa/drivers/dri/common/Makefile.sources
I would like for Android to just reuse Makefile.defines, but the file is
unsuitable for Android.
Signed-off
libmesa_dricore is analogous to the libdricore built by the Autoconf
build.
Signed-off-by: Chad Versace
---
src/mesa/Android.mk | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/src/mesa/Android.mk b/src/mesa/Android.mk
index 67808d4..ff7
In src/mesa/Android.mk, it is non-trivial to determine which variables are
imported by `include sources.mak`. So document them.
Signed-off-by: Chad Versace
---
src/mesa/Android.mk |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/Android.mk b/src/mesa/Android.
If you attempt to link together libmesa_dricore.so from object files built with
visibility=hidden, then the library is useless. It exposes no symbols.
Signed-off-by: Chad Versace
---
Android.common.mk |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Android.common.mk b/An
This series builds libmesa_dricore.so and i965_dri.so for Android. Along the
way, a few cleanups are necessary.
This just gets the driver to build. I have not tested it yet.
Chad Versace (8):
android: Remove -fvisibility=hidden from CFLAGS so that we can build
a shared dricore
mesa: Build
On Fri, Aug 26, 2011 at 5:54 PM, Zack Rusin wrote:
> On Friday, August 26, 2011 05:12:52 PM Younes Manton wrote:
>> On Fri, Aug 26, 2011 at 4:31 PM, Brian Paul wrote:
>> > Two things that should probably be fixed in the src/gallium/auxiliary/vl/
>> > code:
>> >
>> > 1. The copyright statements re
https://bugs.freedesktop.org/show_bug.cgi?id=40401
--- Comment #1 from Vadim 2011-08-26 17:35:22 PDT ---
(In reply to comment #0)
> The game Cogs is very slow with the r300g (and r600g) driver. This was
> originally mentioned in bug 39572, however that bug was about different
> problem
> and is
On Fri, Aug 26, 2011 at 5:54 PM, Zack Rusin wrote:
> On Friday, August 26, 2011 05:12:52 PM Younes Manton wrote:
>> On Fri, Aug 26, 2011 at 4:31 PM, Brian Paul wrote:
>> > Two things that should probably be fixed in the src/gallium/auxiliary/vl/
>> > code:
>> >
>> > 1. The copyright statements re
On Friday, August 26, 2011 05:12:52 PM Younes Manton wrote:
> On Fri, Aug 26, 2011 at 4:31 PM, Brian Paul wrote:
> > Two things that should probably be fixed in the src/gallium/auxiliary/vl/
> > code:
> >
> > 1. The copyright statements refer to Tungsten Graphics. That's probably
> > a copy & pa
Use ANGLE. It's there, it works well enough that Fx and Chromium are
both using it, and it'll do what you want.
...I kinda wish you didn't need it, but sadly, OGL on Win32 sucks a lot.
~ C.
On Fri, Aug 26, 2011 at 10:13 AM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
On Fri, Aug 26, 2011 at 4:31 PM, Brian Paul wrote:
> Two things that should probably be fixed in the src/gallium/auxiliary/vl/
> code:
>
> 1. The copyright statements refer to Tungsten Graphics. That's probably a
> copy & paste error. s/Tungsten Graphics/the authors/ or thereabouts.
>
> 2. #incl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2011 01:00 PM, Emil Velikov wrote:
> On Fri, 26 Aug 2011 16:36:50 +0100, Ian Romanick
> wrote:
>
> On 08/26/2011 05:37 AM, Alex Deucher wrote:
On Fri, Aug 26, 2011 at 4:11 AM, Chia-I Wu wrote:
> On Fri, Aug 26, 2011 at 3:52 PM, Ily
Two things that should probably be fixed in the
src/gallium/auxiliary/vl/ code:
1. The copyright statements refer to Tungsten Graphics. That's
probably a copy & paste error. s/Tungsten Graphics/the authors/ or
thereabouts.
2. #includes of gallium headers should use "" instead of <> just to
Hi Emil,
Would it be possible to get into details such as telling if a
particular glBlendFunc() or a certain GL_TEXTURE_ENV_MODE,
GL_COMBINE_RGB flags are h/w accelerated and so on (per driver)? This
is for fixed pipelines.
How is it best to represent such details?
Would be fun to implement a to
On 08/25/2011 02:26 PM, Lauri Kasanen wrote:
From a12122cf8bec360c03518e686f5fdae0c9cbf791 Mon Sep 17 00:00:00 2001
From: Lauri Kasanen
Date: Thu, 25 Aug 2011 23:23:08 +0300
Subject: [PATCH] docs: Add a page on post-processing
Signed-off-by: Lauri Kasanen
Thanks. I've pushed this with some
On Fri, 26 Aug 2011 16:36:50 +0100, Ian Romanick
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2011 05:37 AM, Alex Deucher wrote:
On Fri, Aug 26, 2011 at 4:11 AM, Chia-I Wu wrote:
On Fri, Aug 26, 2011 at 3:52 PM, Ilyes Gouta
wrote:
Thanks a lot Chia-l,
In general, do y
https://bugs.freedesktop.org/show_bug.cgi?id=40397
--- Comment #1 from Thomas Hellström 2011-08-26
12:27:29 PDT ---
Running vmwgfx with the xorg state tracker is obsolete.
Please instead enable and install the xa state tracker and use the
vmwgfx branch of xf86-video-vmware.
Thanks,
Thomas
--
On 26.08.2011 20:57, Ian Romanick wrote:
> On 08/26/2011 09:26 AM, Dave Airlie wrote:
> > I've involuntarily started looking into this when I tried to add TXF
> > support, so we need to expand TGSI to add support for texture offsets.
>
> > Requirements:
> > the extreme requirement so far is for tex
Thank you guys for the information!
-Ilyes
On Fri, Aug 26, 2011 at 4:36 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/26/2011 05:37 AM, Alex Deucher wrote:
>> On Fri, Aug 26, 2011 at 4:11 AM, Chia-I Wu wrote:
>>> On Fri, Aug 26, 2011 at 3:52 PM, Ilyes Gouta
From: Ian Romanick
When generating dispatch templates, emit the '(void) blah;' magic to
make GCC happy. This reduces a lot of warning spam if you build with
-Wunused-parameter or -Wextra.
Cc: Chia-I Wu
---
There's a follow-on patch that commits the resulting changes to the
various generated f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2011 09:26 AM, Dave Airlie wrote:
> I've involuntarily started looking into this when I tried to add TXF
> support, so we need to expand TGSI to add support for texture offsets.
>
> Requirements:
> the extreme requirement so far is for textur
https://bugs.freedesktop.org/show_bug.cgi?id=40401
Sven Arvidsson changed:
What|Removed |Added
CC||s...@whiz.se
--
Configure bugmail: htt
On 08/25/2011 01:30 PM, Chad Versace wrote:
> We weren't catching this? Embarrassing.
>
> Reviewed-by: Chad Versace
>
> We may also want to emit an error when a variable is declared as 'in'
> a VS and as 'out' in a FS. But I'm not sure that's actually illegal.
Ian mentioned the case of 'uniform
https://bugs.freedesktop.org/show_bug.cgi?id=40401
Summary: Cogs is slow
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Keywords: patch
Severity: normal
Priority: medium
Co
On Wed, Aug 24, 2011 at 7:46 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/24/2011 12:11 PM, Ian Romanick wrote:
>> I'd like to propose giving the ax to a bunch of old, unmaintained
>> drivers. I've been doing a bunch of refactoring and reworking of core
>> M
On Thu, Aug 25, 2011 at 1:46 AM, Ian Romanick wrote:
> I've put up an initial branch at
>
> git://people.freedesktop.org:~idr/mesa kill-old-drivers
Acked-by: Marek Olšák
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/25/2011 10:55 AM, Anonimo Veneziano wrote:
> Hi all
> I am a programmer but not very skilled in 3D graphics (so pardon me if I
> write something wrong).
> I need to build my own opengl32.dll to redirect my OpenGL application
> calls to DirectX (b
On 08/25/2011 11:19 PM, Chia-I Wu wrote:
> On Fri, Aug 26, 2011 at 2:05 PM, Chia-I Wu wrote:
>> On Fri, Aug 26, 2011 at 12:55 PM, Chad Versace wrote:
>>> [CC'ing krh because I learned much of this from him, so may have some
>>> insight to share with us.]
>>>
>>> On 08/25/2011 08:14 PM, Chia-I Wu
I've involuntarily started looking into this when I tried to add TXF
support, so we need to expand TGSI to add support for texture offsets.
Requirements:
the extreme requirement so far is for textureGatherOffsets which can
accept 4 x ivec2, the normal textureFetchOffset can accept an ivec3.
The ha
https://bugs.freedesktop.org/show_bug.cgi?id=40397
José Fonseca changed:
What|Removed |Added
CC||bri...@vmware.com,
|
https://bugs.freedesktop.org/show_bug.cgi?id=40397
Summary: vmwgfx 3D Glitchy
Product: Mesa
Version: 7.11
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Compo
On 26.08.2011 17:37, Lauri Kasanen wrote:
> On Fri, 26 Aug 2011 17:21:02 +0200
> Christoph Bumiller wrote:
>
>> We cannot rely on pipe drivers to default to non-zero.
>>
>> Fixes pp being a no-op on nv50.
> Reviewed-by: Lauri Kasanen
>
> Appears to be a no-op on anywhere but nv50 and nvc0. MSAA r
On Fri, Aug 26, 2011 at 2:05 AM, Chia-I Wu wrote:
> On Fri, Aug 26, 2011 at 12:55 PM, Chad Versace wrote:
>> [CC'ing krh because I learned much of this from him, so may have some
>> insight to share with us.]
>>
>> On 08/25/2011 08:14 PM, Chia-I Wu wrote:
>>> On Fri, Aug 26, 2011 at 4:09 AM, Chad
On Fri, 26 Aug 2011 17:21:02 +0200
Christoph Bumiller wrote:
> We cannot rely on pipe drivers to default to non-zero.
>
> Fixes pp being a no-op on nv50.
Reviewed-by: Lauri Kasanen
Appears to be a no-op on anywhere but nv50 and nvc0. MSAA related?
- Lauri
On Fri, Aug 26, 2011 at 8:36 PM, Kristensen, Kristian H
wrote:
[snip]
>> There is no pixmap in Android so it can be ignored. As for pbuffers,
>> which I plan to support as a follow-on commit, it works pretty much
>> the same as the windows except that the back buffer is also allocated
>> by EGL.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2011 05:37 AM, Alex Deucher wrote:
> On Fri, Aug 26, 2011 at 4:11 AM, Chia-I Wu wrote:
>> On Fri, Aug 26, 2011 at 3:52 PM, Ilyes Gouta wrote:
>>> Thanks a lot Chia-l,
>>>
>>> In general, do you guys keep a matrix (per driver, mesa version),
We cannot rely on pipe drivers to default to non-zero.
Fixes pp being a no-op on nv50.
---
src/gallium/auxiliary/postprocess/pp_program.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/postprocess/pp_program.c
b/src/gallium/auxiliary/postprocess/p
On Fri, 2011-08-26 at 11:07 -0400, Chia-I Wu wrote:
> On Fri, Aug 26, 2011 at 10:52 PM, Chia-I Wu wrote:
> [snip]
> >> I don't really have a lot of insight into how the Android build system
> >> works, but those files were originally added so that r300_dri.so would
> >> link correctly for Gallium
On Fri, Aug 26, 2011 at 10:52 PM, Chia-I Wu wrote:
[snip]
>> I don't really have a lot of insight into how the Android build system
>> works, but those files were originally added so that r300_dri.so would
>> link correctly for Gallium targets that didn't use GLSL, because without
>> GLSL those fi
>
> [*] keeping up with DRM in linux is hard work. you guys are
> very active.
Its all the hw manufactures fault really, they make GPUs too complex
and release them too quick :-)
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lis
On 08/26/11 01:52, matthew green wrote:
> [*] keeping up with DRM in linux is hard work. you guys are
> very active.
Absolutely agreed there, but the only working DRM module we ship
at the moment is a KMS/DRI2 version of i915, so I have no objections
to losing the Mesa support for the DRI1 module
On Fri, Aug 26, 2011 at 10:07 PM, Tom Stellard wrote:
> On Thu, 2011-08-25 at 22:28 -0400, Chia-I Wu wrote:
>> On Fri, Aug 26, 2011 at 5:29 AM, Tom Stellard
>> wrote:
>> > On Thu, 2011-08-25 at 00:55 -0400, Chia-I Wu wrote:
>> >> From: Chia-I Wu
>> >>
>> >> ---
>> >> src/gallium/drivers/r300/M
On Fri, Aug 26, 2011 at 3:04 PM, Brian Paul wrote:
> On 08/26/2011 04:50 AM, Dave Airlie wrote:
>>
>> From: Dave Airlie
>>
>> In order to implement the GLSL texelFetchOffset I needed to modify TXF
>> (which wasn't defined anyways). It now corresponds to the NV_gpu_shader4.
>>
>> I've limited thing
On Thu, 2011-08-25 at 22:28 -0400, Chia-I Wu wrote:
> On Fri, Aug 26, 2011 at 5:29 AM, Tom Stellard wrote:
> > On Thu, 2011-08-25 at 00:55 -0400, Chia-I Wu wrote:
> >> From: Chia-I Wu
> >>
> >> ---
> >> src/gallium/drivers/r300/Makefile | 63
> >> ++--
> >> src
On 08/26/2011 04:50 AM, Dave Airlie wrote:
From: Dave Airlie
In order to implement the GLSL texelFetchOffset I needed to modify TXF
(which wasn't defined anyways). It now corresponds to the NV_gpu_shader4.
I've limited things to a u8, since hw can only do about 4-5 bits, since
that is what DX s
2011/8/26 Kristian Høgsberg :
> On Fri, Aug 26, 2011 at 4:52 AM, matthew green wrote:
>>
>> hi folks,
>>
>>> - Remove all DRI1 drivers: i810, mach64, mga, r128, savage, sis, tdfx,
>>> and unichrome.
>>
>> over in netbsd land we're still lagging on DRI2 support[*]. of
>> the above cards, i've har
On Fri, Aug 26, 2011 at 4:52 AM, matthew green wrote:
>
> hi folks,
>
>> - Remove all DRI1 drivers: i810, mach64, mga, r128, savage, sis, tdfx,
>> and unichrome.
>
> over in netbsd land we're still lagging on DRI2 support[*]. of
> the above cards, i've hard successful reports on mach64, mga,
> r
On Fri, Aug 26, 2011 at 4:11 AM, Chia-I Wu wrote:
> On Fri, Aug 26, 2011 at 3:52 PM, Ilyes Gouta wrote:
>> Thanks a lot Chia-l,
>>
>> In general, do you guys keep a matrix (per driver, mesa version),
>> where supported and unsupported features are listed?
> Some of the driver developers do, but I
hi folks,
> - Remove all DRI1 drivers: i810, mach64, mga, r128, savage, sis, tdfx,
> and unichrome.
over in netbsd land we're still lagging on DRI2 support[*]. of
the above cards, i've hard successful reports on mach64, mga,
r128 and tdfx in the last couple of years, though the only cards i
kn
From: Dave Airlie
In order to implement the GLSL texelFetchOffset I needed to modify TXF
(which wasn't defined anyways). It now corresponds to the NV_gpu_shader4.
I've limited things to a u8, since hw can only do about 4-5 bits, since
that is what DX specifies, TGSI passes stuff in an immediate
On Fri, Aug 26, 2011 at 3:52 PM, Ilyes Gouta wrote:
> Thanks a lot Chia-l,
>
> In general, do you guys keep a matrix (per driver, mesa version),
> where supported and unsupported features are listed?
Some of the driver developers do, but I am not sure if they have
GLESv1 covered. I will let other
This is enabled iff libdricore is enabled.
Signed-off-by: Christopher James Halse Rogers
---
This could also be folded into libdricore, if that's considered more
appropriate.
configs/autoconf.in |3 +++
configure.ac |8 +++-
src/gallium/Makefile.t
Signed-off-by: Christopher James Halse Rogers
---
configs/autoconf.in |2 +-
configure.ac | 10 --
src/glsl/Makefile|9 +++--
src/mesa/Makefile|3 ++-
src/mesa/sources.mak |2 ++
5 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/confi
Fixes warning:
mv: `../../lib/libdricore.so' and `../../lib/libdricore.so' are the same file
Signed-off-by: Christopher James Halse Rogers
---
src/mesa/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index 3cfc285..f83ff15
Eric was wondering why the --enable-shared-dricore option also built libglsl.so.
This provided the activation energy to fix it, and also extend dricore to the
gallium drivers.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesk
This is useful for building convenience libraries before combining them into
shared libraries, like dricore
Signed-off-by: Christopher James Halse Rogers
---
bin/mklib | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/bin/mklib b/bin/mklib
Thanks a lot Chia-l,
In general, do you guys keep a matrix (per driver, mesa version),
where supported and unsupported features are listed?
Also, is there a reference renderer in mesa that I can toggle on at
runtime (such as using an env. variable) so that I can compare with
the hardware accelera
75 matches
Mail list logo
