Re: [Mesa3d-dev] [PATCH 4/6] dri: Allow selective generation of accum. buffer configs
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 of the drivers calling function have been updated to pass true for the accumulation selector. This maintains the current behavior. What's the gain? You don't (and probably won't) remove code, so that's just removing functionality for the sake of removing functionality. So what's the point, short of the current x11/glx visual concept is outdated and a capability request would be better? OG. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Proposed gallium buffer/texture evolution
Instead of combining create/map and unmap/destroy it would be better to make map more powerful. If I understand correctly, you are proposing to add a subrectangle parameter to map/unmap, so that you can collect multiple rectangle updates in a single upload happening at transfer destruction time. This is interesting: I think a better effect can be obtained by merging the functions as described and also adding a validate_subrect and flush_subrect ranges that would respectively read back and upload a transfer subrectangle to/from the GPU object (and of course, destruction would no longer implicitly flush and creation no longer implicitly validate unless possibly told to so with a specific flag). At map/unmap time if you know the subset of data being read/written you can optimize the amount of data being transferred, especially in the write-only case where you can keep track of the dirty ranges and possibly combine them to fewer uploads. If you combine create+map and unmap+destroy you end up limiting yourself for no reason other than minor convenience. I think adding an explicit validate_subrect and flush_subrect allows to do this, and is actually better since it also allows efficient implementation of glFlushMappedBufferRange. However, I'm not sure whether, in the OpenGL case, this would be an optimization and not a pessimization. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] piglit: Pump requirement for vp-combined-image-units to vertex shader.
On Mon, Feb 8, 2010 at 5:45 PM, Brian Paul brian.e.p...@gmail.com wrote:
On Sun, Feb 7, 2010 at 3:16 PM, Pauli Nieminen suok...@gmail.com wrote:
Queried variables GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS are not part ARB_vertex_program.
Mesa only returns them if driver implements ARB_vertex_shader
which is correct according to extension specifications.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
tests/shaders/vp-combined-image-units.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/tests/shaders/vp-combined-image-units.c
b/tests/shaders/vp-combined-image-units.c
index 743fc3d..0dc4a42 100644
--- a/tests/shaders/vp-combined-image-units.c
+++ b/tests/shaders/vp-combined-image-units.c
@@ -74,5 +74,6 @@ piglit_display(void)
void
piglit_init(int argc, char **argv)
{
- piglit_require_extension(GL_ARB_vertex_program);
+ piglit_require_extension(GL_ARB_vertex_shader);
}
+
--
There's also a comment near the top of the file which should be
updated. Thanks.
Cleaned a a bit more the code and attached the patch. Here is change set also:
diff --git a/tests/shaders/vp-combined-image-units.c
b/tests/shaders/vp-combined-image-units.c
index 743fc3d..324e0df 100644
--- a/tests/shaders/vp-combined-image-units.c
+++ b/tests/shaders/vp-combined-image-units.c
@@ -27,7 +27,7 @@
/** @file vp-combined-image-units.c
*
- * Tests that ARB_vertex_program returns a not-impossible result for
+ * Tests that ARB_shader_program returns a not-impossible result for
* GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS. Catches a regression in wine caused
* by bug #25518.
*/
@@ -53,15 +53,13 @@ piglit_display(void)
pass = GL_FALSE;
}
- if (GLEW_ARB_fragment_program) {
- glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, fragment);
- if (combined fragment) {
- fprintf(stderr,
- Max fragment units (%d)
- combined units (%d)\n,
- fragment, combined);
- pass = GL_FALSE;
- }
+ glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, fragment);
+ if (combined fragment) {
+ fprintf(stderr,
+ Max fragment units (%d)
+ combined units (%d)\n,
+ fragment, combined);
+ pass = GL_FALSE;
}
pass = pass glGetError() == 0;
@@ -74,5 +72,6 @@ piglit_display(void)
void
piglit_init(int argc, char **argv)
{
- piglit_require_extension(GL_ARB_vertex_program);
+ piglit_require_extension(GL_ARB_vertex_shader);
}
Can you commit to piglit?
No.
-Brian
From 5e08bd4e3eb931b108cfee2be0c17c8ee99df71a Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Sun, 7 Feb 2010 05:57:11 +0200
Subject: [PATCH] piglit: Pump requirements for vp-combined-image-units to vertex shader.
Queried variables GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS are not part ARB_vertex_program.
Mesa only returns them if driver implements ARB_vertex_shader
which is correct according to extension specifications.
v2: Fix the test description. Also remove the test for gl extension
from test code.
---
tests/shaders/vp-combined-image-units.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/tests/shaders/vp-combined-image-units.c b/tests/shaders/vp-combined-image-units.c
index 743fc3d..324e0df 100644
--- a/tests/shaders/vp-combined-image-units.c
+++ b/tests/shaders/vp-combined-image-units.c
@@ -27,7 +27,7 @@
/** @file vp-combined-image-units.c
*
- * Tests that ARB_vertex_program returns a not-impossible result for
+ * Tests that ARB_shader_program returns a not-impossible result for
* GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS. Catches a regression in wine caused
* by bug #25518.
*/
@@ -53,15 +53,13 @@ piglit_display(void)
pass = GL_FALSE;
}
- if (GLEW_ARB_fragment_program) {
- glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, fragment);
- if (combined fragment) {
- fprintf(stderr,
-Max fragment units (%d)
-combined units (%d)\n,
-fragment, combined);
- pass = GL_FALSE;
- }
+ glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, fragment);
+ if (combined fragment) {
+ fprintf(stderr,
+ Max fragment units (%d)
+ combined units (%d)\n,
+ fragment, combined);
+ pass = GL_FALSE;
}
pass = pass glGetError() == 0;
@@ -74,5 +72,6 @@ piglit_display(void)
void
piglit_init(int argc, char **argv)
{
- piglit_require_extension(GL_ARB_vertex_program);
+ piglit_require_extension(GL_ARB_vertex_shader);
}
+
--
1.6.3.3
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans
[Mesa3d-dev] [Bug 26487] New: freeglut segfault because it receives a __GLcontextModes instead of a GLXFBConfig
http://bugs.freedesktop.org/show_bug.cgi?id=26487
Summary: freeglut segfault because it receives a __GLcontextModes
instead of a GLXFBConfig
Product: Mesa
Version: git
Platform: Other
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: GLX
AssignedTo: mesa3d-dev@lists.sourceforge.net
ReportedBy: ri...@free.fr
glXChooseFBConfig and friends happyly cast one structure to another, so I
believe they are supposed to be equal. This is not the case here, as gdb shows
it :
type = struct __GLcontextModesRec {
struct __GLcontextModesRec *next;
GLboolean rgbMode;
GLboolean floatMode;
GLboolean colorIndexMode;
GLuint doubleBufferMode;
GLuint stereoMode;
GLboolean haveAccumBuffer;
GLboolean haveDepthBuffer;
GLboolean haveStencilBuffer;
GLint redBits;
GLint greenBits;
GLint blueBits;
GLint alphaBits;
GLuint redMask;
GLuint greenMask;
GLuint blueMask;
GLuint alphaMask;
GLint rgbBits;
...
which comes from GL/internal/glcore.h from MESA, while the other is :
type = struct __GLXFBConfigRec {
int visualType;
int transparentType;
int transparentRed;
int transparentGreen;
int transparentBlue;
int transparentAlpha;
int transparentIndex;
int visualCaveat;
int associatedVisualId;
int screen;
int drawableType;
int renderType;
int maxPbufferWidth;
int maxPbufferHeight;
int maxPbufferPixels;
int optimalPbufferWidth;
int optimalPbufferHeight;
int visualSelectGroup;
unsigned int id;
...
This later definition comes not from MESA but aparently from
/use/include/GL/glxint.h on my host (which is a gentoo and this file is there
installed by a package named glproto BTW).
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Proposed gallium buffer/texture evolution
On Tue, Feb 9, 2010 at 8:34 AM, Luca Barbieri luca.barbi...@gmail.com wrote: Instead of combining create/map and unmap/destroy it would be better to make map more powerful. If I understand correctly, you are proposing to add a subrectangle parameter to map/unmap, so that you can collect multiple rectangle updates in a single upload happening at transfer destruction time. This is interesting: I think a better effect can be obtained by merging the functions as described and also adding a validate_subrect and flush_subrect ranges that would respectively read back and upload a transfer subrectangle to/from the GPU object (and of course, destruction would no longer implicitly flush and creation no longer implicitly validate unless possibly told to so with a specific flag). At map/unmap time if you know the subset of data being read/written you can optimize the amount of data being transferred, especially in the write-only case where you can keep track of the dirty ranges and possibly combine them to fewer uploads. If you combine create+map and unmap+destroy you end up limiting yourself for no reason other than minor convenience. I think adding an explicit validate_subrect and flush_subrect allows to do this, and is actually better since it also allows efficient implementation of glFlushMappedBufferRange. However, I'm not sure whether, in the OpenGL case, this would be an optimization and not a pessimization. I'm interested in exploring all of these options. My goal at this point is to make a first pass over the problem and fix the most significant architectural issues, specifically making transfers context-private, unifying the gpu-side aspects of buffers and textures, etc. Once that's done, looking at the details of how we're doing transfers, and indeed what a transfer really is, is completely feasible. One option would be to say that a transfer is really just an abstraction of piece of AGP/DMA memory, and that up/downloads from specific gpu-side entities can be made by copy-to/from-transfer commands. Another might be to say that transfers turn into something like DX staging resources, with internal structure like width, height, mipmaps etc, which can be mapped by the CPU but never bound to the GPU, and again copy-to/from-staging-resource commands mediate the up/downloads. Yet a third would be to drop the transfer map/unmap commands and make their lifetime explicitly limited to a single up/download. Once the current round of changes is done, it may be easier to see what the best path forwards is. Keith Keith -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: gallium-embedded
On Wed, Feb 3, 2010 at 1:41 PM, José Fonseca jfons...@vmware.com wrote: ... This reminds me there's a patch series from mesa3d-dev that removed a bunch of Mesa's std C wrappers (like _mesa_memcpy()). Mabye some of those could be applied after gallium-embedded but before the src/platform work. Great. It seems we have a plan then. What happened to the plan? Are we going to move the header files out to src/os or are they staying under src/gallium/auxillary/os? Is the idea that code under src/mesa can include the headers from src/gallium/auxillary/os? Kristian -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: gallium-embedded
On Tue, 2010-02-09 at 06:37 -0800, Kristian Høgsberg wrote: On Wed, Feb 3, 2010 at 1:41 PM, José Fonseca jfons...@vmware.com wrote: ... This reminds me there's a patch series from mesa3d-dev that removed a bunch of Mesa's std C wrappers (like _mesa_memcpy()). Mabye some of those could be applied after gallium-embedded but before the src/platform work. Great. It seems we have a plan then. What happened to the plan? Are we going to move the header files out to src/os or are they staying under src/gallium/auxillary/os? Is the idea that code under src/mesa can include the headers from src/gallium/auxillary/os? Kristian Kristian, Nothing happened to the plan -- I will move the header files out to src/platform or src/os or whatever name people feel comfortable with. But I don't have time to do it this week or likely the next. It just not a matter of moving files -- it's also necessary to break the dependency of the os stuff from p_config.h and p_compiler.h somehow. I don't want gallium interfaces to depend on this new shared module nor vice-versa. It's not very hard but getting it right needs more attention and time than I can dispense at the moment. If you prefer getting a start at this yourself immediately then I'm fine with you starting a feature branch to rehearse this. Jose -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: gallium-embedded
On Tue, Feb 9, 2010 at 9:49 AM, José Fonseca jfons...@vmware.com wrote: On Tue, 2010-02-09 at 06:37 -0800, Kristian Høgsberg wrote: On Wed, Feb 3, 2010 at 1:41 PM, José Fonseca jfons...@vmware.com wrote: ... This reminds me there's a patch series from mesa3d-dev that removed a bunch of Mesa's std C wrappers (like _mesa_memcpy()). Mabye some of those could be applied after gallium-embedded but before the src/platform work. Great. It seems we have a plan then. What happened to the plan? Are we going to move the header files out to src/os or are they staying under src/gallium/auxillary/os? Is the idea that code under src/mesa can include the headers from src/gallium/auxillary/os? Kristian Kristian, Nothing happened to the plan -- I will move the header files out to src/platform or src/os or whatever name people feel comfortable with. But I don't have time to do it this week or likely the next. It just not a matter of moving files -- it's also necessary to break the dependency of the os stuff from p_config.h and p_compiler.h somehow. I don't want gallium interfaces to depend on this new shared module nor vice-versa. It's not very hard but getting it right needs more attention and time than I can dispense at the moment. If you prefer getting a start at this yourself immediately then I'm fine with you starting a feature branch to rehearse this. Ok, cool, I might do that, but mainly I just wanted to understand if the plan was to leave the headers under src/gallium or move them out, which is now clear. thanks, Kristian -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 5002] indirect rendering of glDrawArrays() to an NVidia machine is broke.
http://bugs.freedesktop.org/show_bug.cgi?id=5002 --- Comment #6 from martin.v...@itwm.fraunhofer.de 2010-02-09 07:37:41 PST --- Created an attachment (id=33195) -- (http://bugs.freedesktop.org/attachment.cgi?id=33195) draws an empty window instead a quad -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 5002] indirect rendering of glDrawArrays() to an NVidia machine is broke.
http://bugs.freedesktop.org/show_bug.cgi?id=5002 --- Comment #7 from martin.v...@itwm.fraunhofer.de 2010-02-09 07:41:39 PST --- Hello, seems I hit the same problem. (3 years and a few month later its still present. :) I added my demo attachment. The problematic code is: // vertex test glEnableClientState(GL_VERTEX_ARRAY); glVertexPointer(3,GL_FLOAT,0,vertices); glDrawArrays(GL_QUADS,0,4); glDisableClientState(GL_VERTEX_ARRAY); This only draws an empty window. setting LIBGL_NO_DRAWARRAYS=1 fixes the problem for me. The latest nvidia driver which worked was: -173.14 The first one which didnt work for me was:(there may be earlier drivers) -185.18 This is still true for the current linux beta driver: -195.30 I have posted this to the mesa-devel mailinglist with the subject: mesa / nvidia indirect GLX question (OpenSuSE 11.1) This is the posting: http://sourceforge.net/mailarchive/forum.php?thread_name=4B700921.504%40itwm.fraunhofer.deforum_name=mesa3d-dev and the reply: http://sourceforge.net/mailarchive/forum.php?thread_name=4B705700.2000406%40freedesktop.orgforum_name=mesa3d-dev regards, Martin -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 5002] indirect rendering of glDrawArrays() to an NVidia machine is broke.
http://bugs.freedesktop.org/show_bug.cgi?id=5002 martin.v...@itwm.fraunhofer.de changed: What|Removed |Added CC||martin.v...@itwm.fraunhofer. ||de -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6] piglit relax precision requirements
Marek Olšák wrote: On Mon, Feb 8, 2010 at 6:48 PM, Eric Anholt e...@anholt.net mailto:e...@anholt.net wrote: On Sun, 7 Feb 2010 05:38:01 +0100, Marek Olšák mar...@gmail.com mailto:mar...@gmail.com wrote: The attached patch series relaxes precision requirements for 6 tests to pass on r300g. Please review/push. Have you tried getting the glean components pushed to the glean project? I'd rather not carry functional differences from glean where we don't have to. I was under the impression that glean has been merged into piglit. No, only a subset of glean is imported into piglit. Is there any reason to keep it separate? They're really separate projects. The glean project also has a number of tools for analysing and comparing test results which piglit does not have, for example. Intel has issues on the cubemap tests at 2x2 and lower as well. I'm wondering -- are closed drivers the same in this respect? Unfortunately yes, they are. Yeah, I've tested with a few NVIDIA drivers/GPUs in the past and they fail this part of the cubemap tests too. -Brian -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] piglit: Pump requirement for vp-combined-image-units to vertex shader.
Pauli Nieminen wrote:
On Mon, Feb 8, 2010 at 5:45 PM, Brian Paul brian.e.p...@gmail.com wrote:
On Sun, Feb 7, 2010 at 3:16 PM, Pauli Nieminen suok...@gmail.com wrote:
Queried variables GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS are not part ARB_vertex_program.
Mesa only returns them if driver implements ARB_vertex_shader
which is correct according to extension specifications.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
tests/shaders/vp-combined-image-units.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/tests/shaders/vp-combined-image-units.c
b/tests/shaders/vp-combined-image-units.c
index 743fc3d..0dc4a42 100644
--- a/tests/shaders/vp-combined-image-units.c
+++ b/tests/shaders/vp-combined-image-units.c
@@ -74,5 +74,6 @@ piglit_display(void)
void
piglit_init(int argc, char **argv)
{
- piglit_require_extension(GL_ARB_vertex_program);
+ piglit_require_extension(GL_ARB_vertex_shader);
}
+
--
There's also a comment near the top of the file which should be
updated. Thanks.
Cleaned a a bit more the code and attached the patch. Here is change set also:
diff --git a/tests/shaders/vp-combined-image-units.c
b/tests/shaders/vp-combined-image-units.c
index 743fc3d..324e0df 100644
--- a/tests/shaders/vp-combined-image-units.c
+++ b/tests/shaders/vp-combined-image-units.c
@@ -27,7 +27,7 @@
/** @file vp-combined-image-units.c
*
- * Tests that ARB_vertex_program returns a not-impossible result for
+ * Tests that ARB_shader_program returns a not-impossible result for
* GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS. Catches a regression in wine caused
* by bug #25518.
*/
@@ -53,15 +53,13 @@ piglit_display(void)
pass = GL_FALSE;
}
- if (GLEW_ARB_fragment_program) {
- glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, fragment);
- if (combined fragment) {
- fprintf(stderr,
- Max fragment units (%d)
- combined units (%d)\n,
- fragment, combined);
- pass = GL_FALSE;
- }
+ glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, fragment);
+ if (combined fragment) {
+ fprintf(stderr,
+ Max fragment units (%d)
+ combined units (%d)\n,
+ fragment, combined);
+ pass = GL_FALSE;
}
pass = pass glGetError() == 0;
@@ -74,5 +72,6 @@ piglit_display(void)
void
piglit_init(int argc, char **argv)
{
- piglit_require_extension(GL_ARB_vertex_program);
+ piglit_require_extension(GL_ARB_vertex_shader);
}
Can you commit to piglit?
No.
OK, I've committed this patch. Thanks.
-Brian
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 26483] Create Developer Account
http://bugs.freedesktop.org/show_bug.cgi?id=26483 Brian Paul brian.e.p...@gmail.com changed: What|Removed |Added AssignedTo|mesa3d- |sitewrangl...@lists.freedesk |d...@lists.sourceforge.net |top.org Component|Mesa core |New Accounts Product|Mesa|freedesktop.org Version|git |unspecified --- Comment #2 from Brian Paul brian.e.p...@gmail.com 2010-02-09 10:37:23 PST --- Approved. Reassigning to admins. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 4/6] dri: Allow selective generation of accum. buffer configs
-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 of the drivers calling function have been updated to pass true for the accumulation selector. This maintains the current behavior. What's the gain? You don't (and probably won't) remove code, so that's just removing functionality for the sake of removing functionality. So what's the point, short of the current x11/glx visual concept is outdated and a capability request would be better? Please refer to the previous thread for the rationale: http://marc.info/?l=mesa3d-devm=126540374515271w=2 No *functionality* is removed. If you look at patch 5 in the series, I've only reduced the number of visuals with accumulation buffer that are exposed. The accum visuals that are exposed a full featured (i.e., double buffered, depth, and stencil), so any applications that may require an accumulation buffer will not lose any capabilities. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktxrYkACgkQX1gOwKyEAw+hIACfaigJv4KfwdL+GT+o9ZDDd2t4 AhIAoIR3fzW6eB9UlWy00LljkglUzF4C =AT0c -END PGP SIGNATURE- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 4/6] dri: Allow selective generation of accum. buffer configs
-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 want to advertise them as CAVEAT_SLOW. Also, Gallium's dri state tracker needs to be changed to respect this when calling driCreateConfigs. Previous to OpenGL 3.1 and in OpenGL 3.1 with GL_ARB_compatibility, implementations are required to expose at least one configuration with an accumulation buffer. Marking them as slow has always been a bit dubious. They are marked this way because the accumulation operation is done in software, but everything else runs as normal. The GLX spec says: ...if it is set to GLX_SLOW_CONFIG then rendering to a drawable with this configuration may run at reduced performance (for example, the hardware may not support the color buffer depths described by the cnfiguration)... This isn't exactly the case with visual with accumulation buffer. It's just some operations that are slow, and that's always possible. Since these visuals have been marked like this since day-1, I'm not inclined to change them now. Otherwise this looks fine. Can I consider that a 'Reviewed-by:'? :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktxra8ACgkQX1gOwKyEAw9tBACgl/DE+d3oCjAPDGgXp87Ojli9 JXsAoJn5Gn3VTWr/I1M3oTJxwWKLDhck =rZ6v -END PGP SIGNATURE- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Number of supported texture units for drivers with ARB_vertex_shader suppot.
MAX_COMBINED_TEXTURE_IMAGE_UNITS fix[1] is not taking account drivers wihtout support for ARB_vertex_shader should support. Current implementation makes all older drivers to allow glActiveTexture call for up to 32 texture units which is clearly wrong. I don't know what specs says about number of texture units. But my guess is that it should match GL_MAX_TEXTURE_UNITS_ARB. [1] commit b2a30497cc8b107ea74c3d8fbb646e59a4d55a05 Author: Brian Paul bri...@vmware.com Date: Wed Feb 3 15:47:44 2010 -0700 mesa: increase number of texture units to MAX_COMBINED_TEXTURE_IMAGE_UNITS We were misinterpretting GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS previously. It's the number of texture units for which we need to keep state; not just the total number of texture units addressable by the vertex shader plus fragment shader. Since sw Mesa independently supports 16 texture units in vertex shaders and 16 texture units in fragment shaders, the max combined units is 32. Note that the docs for glActiveTexture() indicate the max legal unit is MAX(GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS, MAX_TEXTURE_COORDS) - 1. A new piglit test (texunits.c) tests the various texture unit limits. I'm pretty sure I've got this all right now, but additional reviews are welcome... -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Number of supported texture units for drivers with ARB_vertex_shader suppot.
Pauli Nieminen wrote: MAX_COMBINED_TEXTURE_IMAGE_UNITS fix[1] is not taking account drivers wihtout support for ARB_vertex_shader should support. Current implementation makes all older drivers to allow glActiveTexture call for up to 32 texture units which is clearly wrong. All drivers should set the ctx-Const.MaxCombinedTextureImageUnits constant. For older drivers, it should probably be equal to ctx-Const.MaxTextureCoordUnits. Perhaps you could submit a patch that fixes this? I don't know what specs says about number of texture units. But my guess is that it should match GL_MAX_TEXTURE_UNITS_ARB. Not necessarily. See the spec for details. -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 4/6] dri: Allow selective generation of accum. buffer configs
On Tue, Feb 9, 2010 at 10:47 AM, Ian Romanick i...@freedesktop.org wrote: Corbin Simpson wrote: Otherwise this looks fine. Can I consider that a 'Reviewed-by:'? :) Could I get a version that also fixes Gallium, or should I provide that? :3 Reviewed-by: Corbin Simpson mostawesomed...@gmail.com ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Number of supported texture units for drivers with ARB_vertex_shader suppot.
On Tue, Feb 9, 2010 at 10:48 PM, Brian Paul bri...@vmware.com wrote: Pauli Nieminen wrote: MAX_COMBINED_TEXTURE_IMAGE_UNITS fix[1] is not taking account drivers wihtout support for ARB_vertex_shader should support. Current implementation makes all older drivers to allow glActiveTexture call for up to 32 texture units which is clearly wrong. All drivers should set the ctx-Const.MaxCombinedTextureImageUnits constant. For older drivers, it should probably be equal to ctx-Const.MaxTextureCoordUnits. Perhaps you could submit a patch that fixes this? Looks like a lot of code duplication. Can we do it in single place in core mesa if driver doesn't set any value for MacCombined. Same for any other constant that is required by some updated or extension of OGL. possible code flow idea: 1. Common code sets optional constants to -1 2. Driver sets constant that it supports in context creation 3. Common code sets all remaining constant that are required internally by mesa to good defaults. 4. In debug build warn about missing constant that driver should set. (would help catching bugs like I just found from radeon that one of constants was not set in driver) This would remove requirement to change old drivers if core mesa requires a new (optional) constant for a new feature. In this case sensible default would 0 for drivers not supporting glsl. I don't know what specs says about number of texture units. But my guess is that it should match GL_MAX_TEXTURE_UNITS_ARB. Not necessarily. See the spec for details. yes -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Number of supported texture units for drivers with ARB_vertex_shader suppot.
Pauli Nieminen wrote: On Tue, Feb 9, 2010 at 10:48 PM, Brian Paul bri...@vmware.com wrote: Pauli Nieminen wrote: MAX_COMBINED_TEXTURE_IMAGE_UNITS fix[1] is not taking account drivers wihtout support for ARB_vertex_shader should support. Current implementation makes all older drivers to allow glActiveTexture call for up to 32 texture units which is clearly wrong. All drivers should set the ctx-Const.MaxCombinedTextureImageUnits constant. For older drivers, it should probably be equal to ctx-Const.MaxTextureCoordUnits. Perhaps you could submit a patch that fixes this? Looks like a lot of code duplication. Can we do it in single place in core mesa if driver doesn't set any value for MacCombined. Same for any other constant that is required by some updated or extension of OGL. possible code flow idea: 1. Common code sets optional constants to -1 2. Driver sets constant that it supports in context creation 3. Common code sets all remaining constant that are required internally by mesa to good defaults. 4. In debug build warn about missing constant that driver should set. (would help catching bugs like I just found from radeon that one of constants was not set in driver) This would remove requirement to change old drivers if core mesa requires a new (optional) constant for a new feature. In this case sensible default would 0 for drivers not supporting glsl. Yes, that could work. See _mesa_init_constants() and check_context_limits() in context.c. We could set some of those values to 0 in the former function then set real defaults in the later if they're still zero. Care to take a stab at that? BTW, I'm updating some code in those functions now... -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Number of supported texture units for drivers with ARB_vertex_shader suppot.
On Wed, Feb 10, 2010 at 3:07 AM, Brian Paul bri...@vmware.com wrote: Pauli Nieminen wrote: On Tue, Feb 9, 2010 at 10:48 PM, Brian Paul bri...@vmware.com wrote: Pauli Nieminen wrote: MAX_COMBINED_TEXTURE_IMAGE_UNITS fix[1] is not taking account drivers wihtout support for ARB_vertex_shader should support. Current implementation makes all older drivers to allow glActiveTexture call for up to 32 texture units which is clearly wrong. All drivers should set the ctx-Const.MaxCombinedTextureImageUnits constant. For older drivers, it should probably be equal to ctx-Const.MaxTextureCoordUnits. Perhaps you could submit a patch that fixes this? Looks like a lot of code duplication. Can we do it in single place in core mesa if driver doesn't set any value for MacCombined. Same for any other constant that is required by some updated or extension of OGL. possible code flow idea: 1. Common code sets optional constants to -1 2. Driver sets constant that it supports in context creation 3. Common code sets all remaining constant that are required internally by mesa to good defaults. 4. In debug build warn about missing constant that driver should set. (would help catching bugs like I just found from radeon that one of constants was not set in driver) This would remove requirement to change old drivers if core mesa requires a new (optional) constant for a new feature. In this case sensible default would 0 for drivers not supporting glsl. Yes, that could work. See _mesa_init_constants() and check_context_limits() in context.c. We could set some of those values to 0 in the former function then set real defaults in the later if they're still zero. Care to take a stab at that? ok. I add that to my todo list. BTW, I'm updating some code in those functions now... -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 26503] New: Compilation error git mesa master-branch
http://bugs.freedesktop.org/show_bug.cgi?id=26503 Summary: Compilation error git mesa master-branch Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: wol...@onsneteindhoven.nl Compilation error latest git mesa master-branch. make shows the following error: - r600_texstate.c: In function ‘r600SetTexBuffer’: r600_texstate.c:1119: error: ‘__DRM_TEXTURE_FORMAT_RGBA’ undeclared (first use in this function) r600_texstate.c:1119: error: (Each undeclared identifier is reported only once r600_texstate.c:1119: error: for each function it appears in.) make[6]: *** [r600_texstate.o] Error 1 make[6]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/mesa/drivers/dri/r600' make[5]: *** [lib] Error 2 make[5]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/mesa/drivers/dri/r600' make[4]: *** [subdirs] Error 1 make[4]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/mesa/drivers/dri' make[3]: *** [default] Error 1 make[3]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/mesa/drivers' make[2]: *** [driver_subdirs] Error 2 make[2]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/mesa' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src' make: *** [default] Error 1 - -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
