On Wed, Aug 10, 2011 at 7:11 AM, Rudolf Polzer wrote:
> On Tue, Aug 09, 2011 at 11:45:23PM +0200, Marek Olšák wrote:
>> On Tue, Aug 9, 2011 at 12:25 PM, Jose Fonseca wrote:
>> > I don't have time for a longer reply now, but I do think your S2TC work is
>> > interesting, and that you've successfu
On Wed, Aug 10, 2011 at 12:21 PM, Benjamin Franzke
wrote:
> 2011/8/10 Chia-I Wu :
>> I'd prefer to leave out the second patch for now. One comment below
>>
>> On Tue, Aug 9, 2011 at 10:53 PM, Benjamin Franzke
>> wrote:
>>> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
>>> index 0ba7
The spec of DTV SoC was release. I got the HW spec. And I found the design
was not consider about "shader".
Our HW architecture was a VG pipe line, almost like
http://www.khronos.org/assets/uploads/apis/openvg_pipeline1.jpg
Is this means that it is not make sense to write a Gallium driver for GL/VG
On Tue, Aug 09, 2011 at 11:45:23PM +0200, Marek Olšák wrote:
> On Tue, Aug 9, 2011 at 12:25 PM, Jose Fonseca wrote:
> > I don't have time for a longer reply now, but I do think your S2TC work is
> > interesting, and that you've successfully contoured the patent claims, at
> > least for the decom
2011/8/10 Chia-I Wu :
> I'd prefer to leave out the second patch for now. One comment below
>
> On Tue, Aug 9, 2011 at 10:53 PM, Benjamin Franzke
> wrote:
>> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
>> index 0ba7794..5d186c6 100644
>> --- a/src/egl/main/eglapi.c
>> +++ b/src/egl
I'd prefer to leave out the second patch for now. One comment below
On Tue, Aug 9, 2011 at 10:53 PM, Benjamin Franzke
wrote:
> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> index 0ba7794..5d186c6 100644
> --- a/src/egl/main/eglapi.c
> +++ b/src/egl/main/eglapi.c
> @@ -301,7 +301,7
2011/8/10 Chia-I Wu :
> On Tue, Aug 9, 2011 at 10:53 PM, Benjamin Franzke
> wrote:
>> EGL doesnt define howto manage different native platforms.
>> So mesa has a builtime configurable default platform,
>> whith non-standard envvar (EGL_PLATFORM) overwrites.
>> This caused unneeded bugreports, when
On Tue, Aug 9, 2011 at 10:53 PM, Benjamin Franzke
wrote:
> EGL doesnt define howto manage different native platforms.
> So mesa has a builtime configurable default platform,
> whith non-standard envvar (EGL_PLATFORM) overwrites.
> This caused unneeded bugreports, when EGL_PLATFORM was forgotten.
>
On Tue, 9 Aug 2011 23:19:05 +0200, Vincent Lejeune wrote:
> From: vlj
>
> This optimisation pass will look for and pack together vector (up to
> vec3) and scalar in function body. It only concerns local variable,
> not temporary which should however be packed as a side effect. It
> should reduc
On 08/09/2011 03:33 PM, Ian Romanick wrote:
> On 08/09/2011 10:59 AM, Kenneth Graunke wrote:
>> It's the same as GL_AMD_conservative_depth. The specs have slight
>> differences in wording, but don't differ in content or behavior.
>
>> Signed-off-by: Kenneth Graunke
>
> Why do you add ARB_conser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/09/2011 02:19 PM, Vincent Lejeune wrote:
> From: vlj
>
> This optimisation pass will look for and pack together vector (up to vec3)
> and scalar in function body. It only concerns local variable, not temporary
> which should however be packed
On 10.8.2011 0:13, Ian Romanick wrote:
Two words: contributory infringement. The Mesa code would be doing
something that enables something else to infringe. No distro will ship
it because it makes them liable. Don't look for logic or reason or
sense in the legal system. You won't find it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/09/2011 10:59 AM, Kenneth Graunke wrote:
> It's the same as GL_AMD_conservative_depth. The specs have slight
> differences in wording, but don't differ in content or behavior.
>
> Signed-off-by: Kenneth Graunke
Why do you add ARB_conservative
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/09/2011 04:10 AM, Rudolf Polzer wrote:
> As for compression: the compressed format is basically "each 4x4 block is a
> 2-color optimum palette image". Similar schemes have existed way before S3TC
> (e.g. in some video codecs used by DOS games - s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/09/2011 02:29 AM, Rudolf Polzer wrote:
> On Tue, Aug 09, 2011 at 02:01:44AM -0700, Jose Fonseca wrote:
>> - Original Message -
>>> On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote:
- Original Message -
> The s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/07/2011 03:44 PM, Petr Sebor wrote:
> On 4.8.2011 12:19, Rudolf Polzer wrote:
>> On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote:
>>> On 08/03/2011 12:11 PM, Bryan Cain wrote:
Pardon my ignorance, but why do hardware drivers nee
On 9 August 2011 23:45, Marek Olšák wrote:
> texture, so we'd be noncompliant. Noncompliant is probably better than
> not working at all. So what do you guys think?
>
In the general case, no. A missing extension is something applications
can deal with if they care to, a broken extension isn't.
___
On Tue, Aug 9, 2011 at 12:25 PM, Jose Fonseca wrote:
> I don't have time for a longer reply now, but I do think your S2TC work is
> interesting, and that you've successfully contoured the patent claims, at
> least for the decompression, as I didn't look at the compression bits.
>
> But, there wa
From: vlj
This optimisation pass will look for and pack together vector (up to vec3) and
scalar in function body. It only concerns local variable, not temporary which
should however be packed as a side effect. It should reduce register pressure.
---
src/glsl/Makefile |1 +
sr
On Tue, 2011-08-09 at 19:49 +0200, Rudolf Polzer wrote:
> On Tue, Aug 09, 2011 at 10:46:12AM -0700, Corbin Simpson wrote:
> > I should point out something not immediately obvious about S3TC: It's
> > believed that the patents cover any complete pipeline which
> > decompresses S3TC textures accordin
https://bugs.freedesktop.org/show_bug.cgi?id=39588
--- Comment #9 from Benjamin Franzke
2011-08-09 11:43:14 PDT ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > Created an attachment (id=49902)
View: https://bugs.freedesktop.org/attachment.cgi?id=49902
It's the same as GL_AMD_conservative_depth. The specs have slight
differences in wording, but don't differ in content or behavior.
Signed-off-by: Kenneth Graunke
---
docs/GL3.txt|2 +-
src/glsl/glsl_parser.yy |4 ++--
src/glsl/glsl_parser_extras.cpp |1 +
https://bugs.freedesktop.org/show_bug.cgi?id=39588
--- Comment #8 from Ian Romanick 2011-08-09 10:51:42 PDT
---
(In reply to comment #7)
> (In reply to comment #6)
> > Created an attachment (id=49902)
View: https://bugs.freedesktop.org/attachment.cgi?id=49902
Review: https://bugs.freedesktop.o
On Tue, Aug 09, 2011 at 10:46:12AM -0700, Corbin Simpson wrote:
> I should point out something not immediately obvious about S3TC: It's
> believed that the patents cover any complete pipeline which
> decompresses S3TC textures according to the S3TC algorithm. It's
> stupidly broad that way.
Sure i
I should point out something not immediately obvious about S3TC: It's
believed that the patents cover any complete pipeline which
decompresses S3TC textures according to the S3TC algorithm. It's
stupidly broad that way.
On Tue, Aug 9, 2011 at 8:12 AM, Alan Coopersmith
wrote:
> On 08/09/11 02:29,
https://bugs.freedesktop.org/show_bug.cgi?id=39941
Bryan Cain changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
This looks like the right approach to me.
Note that RNDNE is in fact the default rounding mode for IEEE_754-2008
(in fact it was the default for earlier ieee-754 too).
So I see no reason to deviate from that unless there would be some very
good reason, even if it may look "wrong" for humans.
Rolan
On 08/09/11 02:29, Rudolf Polzer wrote:
> Is US patent law really that retarded?
US patent law shares a common feature with most other patent systems:
No matter how carefully you word the patent or read the patent, the
only way to really find out whether something is a patent violation
is to go to
Reviewed-by: Kristian Høgsberg
---
src/egl/main/egldisplay.c | 29 ++---
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c
index 5421f5f..27399c3 100644
--- a/src/egl/main/egldisplay.c
+++ b/src/egl/mai
With new autodetection the type may change, and a local
static variable isnt sufficient as cache anymore.
Reviewed-by: Kristian Høgsberg
---
src/egl/main/egldisplay.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisp
EGL doesnt define howto manage different native platforms.
So mesa has a builtime configurable default platform,
whith non-standard envvar (EGL_PLATFORM) overwrites.
This caused unneeded bugreports, when EGL_PLATFORM was forgotten.
Detection is grouped into basic types of NativeDisplays (which its
On Tue, Aug 09, 2011 at 03:16:34PM +0200, Philipp Klaus Krause wrote:
> Am 09.08.2011 13:10, schrieb Rudolf Polzer:
> > As for compression: the compressed format is basically "each 4x4 block is a
> > 2-color optimum palette image". Similar schemes have existed way before S3TC
> > […]
>
> See Beers
https://bugs.freedesktop.org/show_bug.cgi?id=39941
--- Comment #9 from Sven Arvidsson 2011-08-09 07:31:38 PDT ---
(In reply to comment #8)
> This patch helps for the issues I see in Wine.
It takes care of the problems in Fallout 3 too. Thanks!
--
Configure bugmail: https://bugs.freedesktop.org
On 08/09/2011 07:44 AM, Fabio Pedretti wrote:
The attached patch fixes the following swrast warnings:
swrast/s_span.c: In function 'interpolate_int_colors':
swrast/s_span.c:216:11: warning: unused variable 'i'
swrast/s_span.c:215:17: warning: unused variable 'n'
Pushed. Thanks.
-Brian
__
The attached patch fixes the following swrast warnings:
swrast/s_span.c: In function 'interpolate_int_colors':
swrast/s_span.c:216:11: warning: unused variable 'i'
swrast/s_span.c:215:17: warning: unused variable 'n'--- a/src/mesa/swrast/s_span.c 2011-07-21 09:57:48.183225983 +0200
+++ b/src/mesa/
Am 09.08.2011 13:10, schrieb Rudolf Polzer:
> As for compression: the compressed format is basically "each 4x4 block is a
> 2-color optimum palette image". Similar schemes have existed way before S3TC
> […]
See Beers et al., "Rendering from compressed textures" in the SIGGRAPH
'96 proceedings for
https://bugs.freedesktop.org/show_bug.cgi?id=39941
--- Comment #8 from Henri Verbeet 2011-08-09 06:31:06 PDT
---
Created an attachment (id=50070)
View: https://bugs.freedesktop.org/attachment.cgi?id=50070
Review: https://bugs.freedesktop.org/review?bug=39941&attachment=50070
patch
This patch
On Tue, Aug 09, 2011 at 03:25:05AM -0700, Jose Fonseca wrote:
> - Original Message -
> > I was trying to help the Linux communtiy, but apparently I failed.
> >
> > Looks like all this work I did was for nothing. Nothing is
> > appreciated, all is
> > "Not Invented Here".
> >
> > How else s
- Original Message -
> On Tue, Aug 09, 2011 at 02:01:44AM -0700, Jose Fonseca wrote:
> > - Original Message -
> > > On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote:
> > > > - Original Message -
> > > > > The suggestion however is to include a S2TC-like method wi
The spec of DTV SoC was release. I got the HW spec. And I found the design
was not consider about "shader".
Our HW architecture was a VG pipe line, almost like
http://www.khronos.org/assets/uploads/apis/openvg_pipeline1.jpg
Is this means that it is not make sense to write a Gallium driver for GL/VG
On Tue, Aug 09, 2011 at 02:01:44AM -0700, Jose Fonseca wrote:
> - Original Message -
> > On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote:
> > > - Original Message -
> > > > The suggestion however is to include a S2TC-like method with
> > > > Mesa, to
> > > > basically
>
- Original Message -
> On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote:
> > - Original Message -
> > > The suggestion however is to include a S2TC-like method with
> > > Mesa, to
> > > basically
> > > make sure that in the long run NO distro has no support for S3TC
> >
2011/8/8 Christian König :
> Am Montag, den 08.08.2011, 15:00 +0200 schrieb Maarten Lankhorst:
>> On 08/08/2011 12:10 PM, Christian König wrote:
>> > Most modern players doesn't do it like this any more, but it still seems
>> > to cause a bunch of problems when seeking or fast forward both with
>>
On Die, 2011-08-09 at 06:42 +0200, Rudolf Polzer wrote:
> On Mon, Aug 08, 2011 at 02:03:59PM -0700, Corbin Simpson wrote:
> > Unless I missed something, we (the Mesa developers) do not endorse using
> > S3TC at all, anywhere in the stack, as long as it is patented.
>
> Here, you reference the "fu
44 matches
Mail list logo
