On 10/31/2013 04:13 PM, Keith Packard wrote:
Instead of assuming that the size will be height * pitch, have the caller pass
in the size explicitly.
Signed-off-by: Keith Packard kei...@keithp.com
One nit below. With that changed,
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 09/11/2012 09:40 AM, Sedat Dilek wrote:
Hi,
I can't see it in [1], forgotten?
Mesa 9.0 hasn't been released yet, so of course there isn't a release tag.
Regards,
- Sedat -
[1] http://cgit.freedesktop.org/mesa/mesa/refs/tags
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/31/2011 02:51 PM, kristof.ralov...@gmail.com wrote:
Please apply!
Send patches using git-send-email. People cannot reply with review
comments to patches sent as attachments.
patch 1:
+ if (!gbm)
+ {
+ free(dri2_dpy);
+ return
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/21/2011 12:41 PM, Philipp Klaus Krause wrote:
FYI, there now is a good (no textures or arrays) implementation of GLSL
simplex noise. Unfortunately it's currently under the Artistic license,
but if the author could be convinced to release it
this to
73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
Author: Ian Romanick ian.d.roman...@intel.com
mailto:ian.d.roman...@intel.com
Date: Mon Feb 8 10:34:52 2010 -0800
intel: Stop exposing useless 24 depth/0 stencil configs
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
It looks like a few bug fixes have accumulated on the branch. Could
folks spend some time this week to cherry-pick stable patches from
master, update the release notes, etc. so that we can do a release
either on Friday
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It looks like a few bug fixes have accumulated on the branch. Could
folks spend some time this week to cherry-pick stable patches from
master, update the release notes, etc. so that we can do a release
either on Friday or Monday?
This will be our
, GLX_PIXMAP_BIT | GLX_PBUFFER_BIT,
as glxpbdemo does, will match fbconfigs that don't support pbuffer
rendering, as long as they support pixmap rendering.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
This should go into master, 7.8, and mesa_7_7_branch. Are there any
specific bugs associated
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This change isn't correct. This causes the test to read from the back
buffer after the call to glutSwapBuffers. The swap buffer call can,
especially on DRI2, cause the backbuffer to be filled with garbage.
This can cause the test to fail when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mesa 7.8.1 has been released. The primary purpose of this release is to
fix a significant error in Mesa's copy of glxext.h and the libGL code
that uses it. The release also contains some other bug fixes.
The tag in the GIT repository for Mesa 7.8.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
Sorry about that, now I know I shouldn't have edited that files. For
future reference those creating new extensions should:
- add temporary values to glx.h with an 'X' appended to indicate a
temporary value (e.g.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
Over the weekend I was alerted that some values in Mesa's glxext.h do
not match the values in the OpenGL registry. Specifically, the value of
GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK is wrong both in name and in value.
I am going to fix this by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Corbin Simpson wrote:
On Mon, Mar 29, 2010 at 5:50 PM, Ian Romanick i...@freedesktop.org wrote:
Philipp Klaus Krause wrote:
Well, there is TexSubImage2D. Assuming we have a compressed texture
stored internally as some S3TC format
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin wrote:
The core issue is that some people do not want to see this code in mesa
in whatever form, because they're afraid of lawsuits. Rumour has it that
VIA told them that they would sue. And the same things happened with SGI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SpliFF wrote:
So to clarify, you're saying a partial implementation (decoder only)
isn't an option at all? If you expose an extension it must be complete?
See the documentation for glGetCompressedTexImage.
-BEGIN PGP SIGNATURE-
Version:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Final versions of both Mesa 7.8 and 7.7.1 have been released. Links on
the Mesa website will still need to be updated, but I think Brian has to
do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SpliFF wrote:
On 03/29/10 17:06, Ian Romanick wrote:
SpliFF wrote:
So to clarify, you're saying a partial implementation (decoder only)
isn't an option at all? If you expose an extension it must be complete?
See the documentation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp Klaus Krause wrote:
Corbin Simpson schrieb:
After re-reading ARB_texture_compression, it does seem like it is
legal for extensions such as EXT_texture_compression_s3tc to fall
back, using a basic mechanism: glGetTexLevelParameter can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Nicholson wrote:
On Mon, Mar 29, 2010 at 11:03 AM, Brian Paul bri...@vmware.com wrote:
Brian Paul wrote:
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp Klaus Krause wrote:
Well, there is TexSubImage2D. Assuming we have a compressed texture
stored internally as some S3TC format and then the application replaces
part of it using TexSubImage2D. According to ARB_texture_compression we
may
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SpliFF wrote:
In short, if anyone on these lists can see a way to decompress an s3tc
image without doing just 1 of the items from EACH of the following 4
claims then a legal s3tc decoder should be possible.
The problem is that, for OpenGL, just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Final versions of both Mesa 7.8 and 7.7.1 have been released. Links on
the Mesa website will still need to be updated, but I think Brian has to
do that.
The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'. I had
originally intended to just use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tom fogal wrote:
Brian Paul bri...@vmware.com writes:
Tom wrote:
tom fogal wrote:
$ lib nm libOSMesa.so | grep EGL
U glEGLImageTargetRenderbufferStorageOES
U glEGLImageTargetTexture2DOES
this prevents
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
RALOVICH wrote:
Brian,
that was fast! Who do you think I should bug, to get these working on i965?
As always, if you find a bug, submit a bug report:
http://intellinuxgraphics.org/how_to_report_bug.html
Anything else will get lost and / or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luc Verhaegen wrote:
On Fri, Mar 19, 2010 at 11:33:02AM -0700, Ian Romanick wrote:
I've been busy trying to get a release out the door, so I haven't looked
at these patches yet. I won't have a chance to look at the patches
until at least late
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
2010/2/8 Francisco Jerez curroje...@riseup.net:
The spec says (regarding glXCreateWindow): If there is already a
GLXFBConfig associated with win (as a result of a previous
glXCreateWindow call), then a BadAlloc error is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
2010/3/22 Ian Romanick i...@freedesktop.org:
Kristian Høgsberg wrote:
2010/2/8 Francisco Jerez curroje...@riseup.net:
The spec says (regarding glXCreateWindow): If there is already a
GLXFBConfig associated with win
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicolai Haehnle wrote:
On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen l...@skynet.be wrote:
So, identify the volatile interfaces, and the more stable interfaces,
and then isolate the volatile ones, and then you come to only one
conclusion.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jose Fonseca wrote:
The most worrysome thing here is not quake3 by itself, but the
thought that other GL apps out there may too truncate the GL
extension string.
Yes. I have heard other people in the ARB mention that some apps do
that. I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xavier Chantry wrote:
Patrice also pointed me to the workaround that nvidia driver provides itself :
http://us.download.nvidia.com/freebsd/190.42/README/chapter-09.html
Their solution is roughly analogous to a driconf variable. I think we
should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mesa 7.7.1-rc1 available for testing at
ftp://freedesktop.org/pub/mesa/7.7/RC/
md5sums:
8d9793b12cab73e0f5064d5a509bceea MesaLib-7.7.1-rc1.tar.gz
d0f5622ac53b20b3761dd97c9788211f MesaLib-7.7.1-rc1.tar.bz2
29bc93f32d337b803dfc867eaf62852b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Sapountzis wrote:
Hi,
I put some patches at
http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do
the plumbing in order to build the swrast_dri wrapper around gallium
instead of classic mesa. For reference, swrast_dri is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Karl Schultz wrote:
Am getting these warnings in the Windows build:
2Compiling...
2lex.yy.c
2program_lexer.l(327) : warning C4244: '=' : conversion from 'double'
to 'float', possible loss of data
2program_lexer.l(331) : warning C4244: '=' :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gonsolo wrote:
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 56e8195..d77b36c 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -810,6 +810,13 @@ _mesa_strtod( const char *s, char **end )
#endif
}
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Sapountzis wrote:
I made a small test to test code genration for dynamic extensions in
http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-test
When using libGL + swrast_dri.so from getproc-test, the dynamic
extensions code is not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
Module: Mesa
Branch: master
Commit: 7cbc4c07ee85782d5da3e2db3c4e072ca498ff07
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=7cbc4c07ee85782d5da3e2db3c4e072ca498ff07
Author: Eric Anholt e...@anholt.net
Date: Thu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Török Edwin wrote:
I've run the piglit tests using tests/r500.tests, with glean in quick mode.
With patch: 620/686 pass
Without patch: 614/679 pass (I opened a bugreport about these failures
here:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Corbin Simpson wrote:
2010/3/8 Ian Romanick i...@freedesktop.org:
Okay. I'm convinced. I'll leave it up to the r600 maintainers to make
the final call. However, they really need to do it before RC1 (March 12th).
Thread hijack! Are docs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Török Edwin wrote:
Hi Andre,
I've been using your patch that enables pbo on r600:
http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-testid=6ee755760d124c85bdfd121fd491f68fccca84f7
Are you considering enabling it in Mesa 7.8?
At this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
On Fri, 05 Mar 2010 07:48:06 -0700, Brian Paul bri...@vmware.com wrote:
Chris Wilson wrote:
Please review and include in 7.7! :)
This will go into Mesa 7.8, actually.
I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
Thanks to Intel QA providing a few piglit cases to test the API, this has
had a cursory test and identified the silly cases of using the wrong
lookup functions.
The ugly part is that I've used 3 different driver functions to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Folks,
I just created the Mesa 7.8 release branch. It is called 7.8 instead
of mesa_7_8_branch. Please return to the process of committing bug
fixes to the release branch and merging to master.
My current plan is to have release candidates for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: 744994a9c6b972a737e432cf1b699f232e2c5bfd
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=744994a9c6b972a737e432cf1b699f232e2c5bfd
Author: José Fonseca jfons...@vmware.com
Date:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What is the benefit of adding all these NULL pointer assertions? I
don't see a big benefit of an assertion failure vs. a segfault.
I'm just curious.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vinson Lee wrote:
Module: Mesa
Branch: master
Commit: a05fdbcb719ac64e6be842372813f0f4ca2f4f93
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=a05fdbcb719ac64e6be842372813f0f4ca2f4f93
Author: Vinson Lee v...@vmware.com
Date: Mon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This should already be fixed. Sorry for the noise.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuPG/AACgkQX1gOwKyEAw/bqgCffi8cMZUH0+nePKUphtUInOMz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There are a few places in Mesa where we check the GCC version and have
alternate code paths. It looks like almost all of the checks go away if
we require GCC version of at least 3.3.0. The last 3.2 (or earlier)
release was in April of 2003. It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
While we're on the topic of removing dead weight, can we remove support
for color index rendering? None of the hardware drivers support color
index rendering, and color index rendering is deprecated in OpenGL 3.0
(and removed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Starting a new thread on this...
Here's a proposal of things to remove from the Mesa tree.
GLU:
glu/mini
glu/mesa
GLUT:
glut/fbdev
glut/ggi
glut/directfb
glut/dos
glut/mini
glut/os2
non-DRI drivers:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Sapountzis wrote:
Hi,
I put 3 patches in http://people.freedesktop.org/~gsap7/glapi/ that mv
the code generation functionality in the gen subdir.
Please review,
I'm curious... what is the reason for these changes?
I do like the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
Brian Paul wrote:
I think we could get by with a shorter beta period. There's a few
more things that would be nice to do for 7.8 which I doubt I'd get to
before the 26th:
Part of the reason for the long lead time
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Patrice Mandin wrote:
Le Fri, 19 Feb 2010 16:16:32 -0800
Ian Romanick i...@freedesktop.org a écrit:
While we're on the topic of removing dead weight, can we remove support
for color index rendering? None of the hardware drivers support color
for some of the FBO rendering problems
that have been reported over the years.
Posting from a mobile, pardon my terseness. ~ C.
On Feb 19, 2010 5:19 PM, Ian Romanick i...@freedesktop.org
mailto:i...@freedesktop.org wrote:
While we're on the topic of removing dead weight, can we remove support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kenneth Graunke wrote:
These patches remove various _mesa_foo() wrappers in favor of simply
calling foo() directly. I've split them out by function so it's
possible to pick and choose which ones to apply. Sorry for the spam.
I figured I'd
build. I think it will just cause a bunch of spurious warnings.
I'm okay with that. You can add
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
on the whole series except 9 and 10. I think those patches should also
eliminate the MEMCPY and MEMSET macros that wrap the wrappers. Unless
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
While we're on the topic of removing dead weight, can we remove support
for color index rendering? None of the hardware drivers support color
index rendering, and color index rendering is deprecated in OpenGL 3.0
(and removed in 3.1).
Can it please
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 0e6f69f..475aeab 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1008,6 +1008,30 @@ renderbuffer_storage(GLenum target,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
2010/2/12 Ian Romanick i...@freedesktop.org:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
Hello,
Here's a patch series to implement a handful of EGLImage extensions in
the DRI2 EGL driver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index d58ffd9..f816d8c 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@
that aren't as familiar with some of the inner workings. :)
Other than that and the trivial comment below, this looks good to me.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/intel/intel_regions.c | 24
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index f7ce87e..c2c8c6e 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 5d36c49..1590190 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -42,7 +42,6 @@
#include
From: Ian Romanick ian.d.roman...@intel.com
Pass either the fbconfig ID or the visual ID, as appropriate, to
CreateContext. Now CreateContext does not derefernce fbconfig or vis
(which no longer exists as a parameter).
---
src/glx/glxcmds.c | 20 ++--
1 files changed, 10
From: Ian Romanick ian.d.roman...@intel.com
Passing the opcode directly instead of having CreateContext infer it
from the value of fbconfig and the use_glx_1_3 flag will simplify some
changes that are coming.
---
src/glx/glxcmds.c | 31 +++
1 files changed, 23
From: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxcmds.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 504d17f..19538f2 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1636,7 +1636,6 @@ static int
From: Ian Romanick ian.d.roman...@intel.com
---
progs/xdemos/glxgears_fbconfig.c | 44 +
1 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/progs/xdemos/glxgears_fbconfig.c b/progs/xdemos/glxgears_fbconfig.c
index 316480c..36bf731 100644
From: Ian Romanick ian.d.roman...@intel.com
---
progs/xdemos/glxgears_fbconfig.c | 34 +++---
1 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/progs/xdemos/glxgears_fbconfig.c b/progs/xdemos/glxgears_fbconfig.c
index 2dac00b..316480c 100644
From: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxcmds.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index a4e626b..504d17f 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1090,7 +1090,7
From: Ian Romanick ian.d.roman...@intel.com
Passing the screen parameter to CreateContext will simplify a couple
of changes that are coming.
---
src/glx/glxcmds.c | 23 ---
1 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
From: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxcmds.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 1be6ff3..9b4a6da 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -371,8 +371,6 @@ CreateContext
From: Ian Romanick ian.d.roman...@intel.com
For the direct rendering case, the DRI createContext function wants an
fbconfig. When glXCreateContext is called, we have to convert the
visual to an fbconfig. This work was done in CreateContext, but it
makes more sense for it to be done
There are a couple of things in this patch series.
Patches 01 through 04 eliminate a bunch of annoying warnings that I
get when building Mesa.
Patch 05 fixes an inconsistency between the implementation of
glXSwapIntervalMESA and the spec. I chose to favor the code over the
spec in this case.
From: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxcmds.c | 191 ++---
1 files changed, 95 insertions(+), 96 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 48f7049..b08cad8 100644
--- a/src/glx/glxcmds.c
+++ b/src
From: Ian Romanick ian.d.roman...@intel.com
A long time ago I was a bit over-agressive in refactoring context
creation into a single function. The creation code for
glXImportContextEXT does not belong in CreateContext because it does
not use any GLX protocol. The big if-statement
From: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glxcmds.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 4922406..a4e626b 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -65,6 +65,8 @@ static Bool
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Eric Anholt wrote:
On my system, swrast fails a lot because it exposes ARGB visuals on
a depth 24 buffer, which means the alpha bits get dropped when
putimaging them to X. It seems like we need to fix up its visuals list
to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Olivier Galibert wrote:
On Mon, Feb 08, 2010 at 05:09:58PM -0800, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Modify the interface to driCreateConfigs allowing drivers to not
expose configs with an accumuation buffer. All
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Corbin Simpson wrote:
From what I understand from my research, accumulation buffers are
typically specific to fixed-function chipsets, right? So not all of
these drivers will prefer to expose the accumbuf visuals, and those
that do probably don't
From: Ian Romanick ian.d.roman...@intel.com
We can't always guarantee that the swap will happen by exchange, so we
can't expose this mode. GLX_SWAP_UNDEFINED_OML already covers the
case where the swap *might be* by exchange.
---
src/mesa/drivers/dri/intel/intel_screen.c |3 +--
1 files
From: Ian Romanick ian.d.roman...@intel.com
Expose one config per color depth that includes accumulation buffer.
We could probably expose only one config with accumulation buffer, but
that would require figuring out the actual color depth. This is
easier and only exposes 2 useless configs
From: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index c9ef164..1acd7a5 100644
--- a/src
From: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index bda94e0..b308ae1 100644
From: Ian Romanick ian.d.roman...@intel.com
Modify the interface to driCreateConfigs allowing drivers to not
expose configs with an accumuation buffer. All of the drivers calling
function have been updated to pass true for the accumulation
selector. This maintains the current behavior.
---
src
From: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 1acd7a5..bda94e0 100644
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd like to remove a bunch of the visuals and fbconfigs exposed by the
Intel drivers. There are several categories of visuals that are likely
not useful to anyone. A couple of our test suites (e.g., glean) like to
run over every possible visual. As
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pauli Nieminen wrote:
PXOR user in code were causing the lowest SP float register to have NaN
values which made all math operations in that slot fail. Correct istruction
to clear float registers is XORPS which handles single precission floats
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Bumiller wrote:
I just noticed that alienarena fails to create an FBO for depth rendering
because on st_validate_framebuffer, the depth attachment contains a pt
in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp)
reports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin wrote:
On Tue, Jan 26, 2010 at 15:13, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
mesa_7_7_branch and master are becoming quite different, because of all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
Hey,
Stuck at home today minding sick (on the mend now baby) with only my 965
laptop, and someone mentioned this morning on irc that we don't do
ARB_half_float_vertex, and after reading that patent stuff doesn't apply
to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jakob Bornecrantz wrote:
On 12 jan 2010, at 16.16, Chia-I Wu wrote:
On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz
ja...@vmware.com wrote:
* Non-working
* src/egl/drivers/dri/
Having the dri driver working would be desirable since it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
It's time again to plan what version or versions of Mesa we want to
release in Q1 (end of March). It seems like 7.7.1 is a no-brainer. Do
we also want to release Mesa 7.8? I haven't been keeping track of
master, so I don't know what its state
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
+static GLenum
+_mesa_BufferObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
I think you missed a review comment from before. :) In Mesa's coding
standard _mesa_FooBar implies that there is a glFooBar, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
Attached is a patch that generalizes the ALIGN16/8_XXX macros in
p_compiler.h to work on MSVC and handle alignments beyond 8 and 16
bytes.
There is more than one way to have cross-platform alignment macros --
all quite ugly.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zack Rusin wrote:
On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote:
On 11 jan 2010, at 17.49, Zack Rusin wrote:
I think the other stuff is acceptable. Take a look at the docs and
let me know
what you think.
Hmm I don't think you should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
I thought MSVC supported C99, but that seems not to be the case.
However, it seems to have partial C99 support, and according to MSDN
the particular case of for loop initializers C99 behaviour may be
selected with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chia-I Wu wrote:
Hi Brian,
The attached patches are trivial fixes to a distribution problem and
cofigure.ac. I've done a clean build test
$ make tarballs
$ tar xf MesaLib-7.7-devel.tar.gz
$ cd Mesa-7.7-devel/
$ ./configure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Alan Hourihane wrote:
Module: Mesa
Branch: master
Commit: 1baaf111c8c42ed7f7218c46038f32eb51b9c6eb
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1baaf111c8c42ed7f7218c46038f32eb51b9c6eb
Author: Alan Hourihane
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julien Cristau wrote:
Hi Ian,
On Mon, Dec 21, 2009 at 18:43:41 -0800, Ian Romanick wrote:
The official notification will be posted to the Mesa website shortly.
Mesa 7.6.1 available for download at
ftp://freedesktop.org/pub/mesa/7.6.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The official notification will be posted to the Mesa website shortly.
Mesa 7.6.1 available for download at
ftp://freedesktop.org/pub/mesa/7.6.1/
md5sums:
e80fabad2e3eb7990adae773d6aeacba MesaLib-7.6.1.tar.gz
7db4617e9e10ad3aca1b64339fd71b7d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
This patch changes most of the progs/demos/ so that
1. windows aren't hard-positioned at 0,0
2. the -geometry option can be used to override the default window
size/position
I'll commit this later if there's no concerns.
Is
1 - 100 of 425 matches
Mail list logo
