[Mesa-dev] [PATCH] i965: fix timer query on gen6+
on gen6+, render engine PIPE_CONTROL reported time stamp is a 64 bits
value (high 32 bits MBZ on snb), toggles every 80 ns.
Signed-off-by: Zou Nan hai nanhai@intel.com
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index b41d05d..85a2a61 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -47,7 +47,7 @@
/** Waits on the query object's BO and totals the results for this query */
static void
-brw_queryobj_get_results(struct brw_query_object *query)
+brw_queryobj_get_results(struct brw_query_object *query, int gen)
{
int i;
uint64_t *results;
@@ -58,7 +58,10 @@ brw_queryobj_get_results(struct brw_query_object *query)
drm_intel_bo_map(query-bo, GL_FALSE);
results = query-bo-virtual;
if (query-Base.Target == GL_TIME_ELAPSED_EXT) {
- query-Base.Result += 1000 * ((results[1] 32) - (results[0] 32));
+ if (gen = 6)
+ query-Base.Result += 80 * (results[1] - results[0]);
+ else
+ query-Base.Result += 1000 * ((results[1] 32) - (results[0]
32));
} else {
/* Map and count the pixels from the current query BO */
for (i = query-first_index; i = query-last_index; i++) {
@@ -200,17 +203,21 @@ brw_end_query(struct gl_context *ctx, struct
gl_query_object *q)
static void brw_wait_query(struct gl_context *ctx, struct gl_query_object *q)
{
struct brw_query_object *query = (struct brw_query_object *)q;
+ struct brw_context *brw = brw_context(ctx);
+ struct intel_context *intel = intel_context(ctx);
- brw_queryobj_get_results(query);
are are + brw_queryobj_get_results(query, intel-gen);
query-Base.Ready = GL_TRUE;
}
static void brw_check_query(struct gl_context *ctx, struct gl_query_object *q)
{
struct brw_query_object *query = (struct brw_query_object *)q;
+ struct brw_context *brw = brw_context(ctx);
+ struct intel_context *intel = intel_context(ctx);
if (query-bo == NULL || !drm_intel_bo_busy(query-bo)) {
- brw_queryobj_get_results(query);
+ brw_queryobj_get_results(query, intel-gen);
query-Base.Ready = GL_TRUE;
}
}
@@ -295,7 +302,7 @@ brw_emit_query_begin(struct brw_context *brw)
if (query-bo != brw-query.bo) {
if (query-bo != NULL)
-brw_queryobj_get_results(query);
+brw_queryobj_get_results(query, intel-gen);
drm_intel_bo_reference(brw-query.bo);
query-bo = brw-query.bo;
query-first_index = brw-query.index;
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36384] configure tips (last TODO: rename swrastg to swrast)
https://bugs.freedesktop.org/show_bug.cgi?id=36384 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38716] Can't build, error: undefined reference to `_eglFilterConfigArray'
https://bugs.freedesktop.org/show_bug.cgi?id=38716 --- Comment #13 from Chia-I Wu olva...@gmail.com 2011-07-19 02:27:58 PDT --- (In reply to comment #12) (In reply to comment #1) The command for linking wrongly put the local library search path after the system's. It should be fixed with 24137af. Please test. I am using Debian Sid amd64 but still can't compile the gallium EGL driver.I cloned the latest git and 'make' shows: /usr/bin/ld: error: cannot open ../../../../x86_64-linux-gnu/libEGL.so: No such file or directory libEGL.so is missing. Could you switch to src/egl/main/ and make from that directory? --- mklib: Making Linux shared library: egl_gallium.so /usr/bin/ld: error: cannot open ../../../../x86_64-linux-gnu/libEGL.so: No such file or directory egl.c:98: error: undefined reference to '_eglLog' egl.c:150: error: undefined reference to '_eglLog' egl.c:150: error: undefined reference to '_eglLog' egl.c:78: error: undefined reference to '_eglLog' egl_st.c:79: error: undefined reference to '_eglSearchPathForEach' common/egl_g3d.c:469: error: undefined reference to '_eglReleaseDisplayResources' common/egl_g3d.c:472: error: undefined reference to '_eglDestroyArray' common/egl_g3d.c:476: error: undefined reference to '_eglDestroyArray' common/egl_g3d.c:480: error: undefined reference to '_eglCleanupDisplay' common/egl_g3d.c:186: error: undefined reference to '_eglInitScreen' common/egl_g3d.c:203: error: undefined reference to '_eglLinkScreen' common/egl_g3d.c:526: error: undefined reference to '_eglError' common/egl_g3d.c:581: error: undefined reference to '_eglError' common/egl_g3d.c:510: error: undefined reference to '_eglError' common/egl_g3d.c:429: error: undefined reference to '_eglInitConfig' common/egl_g3d.c:307: error: undefined reference to '_eglValidateConfig' common/egl_g3d.c:437: error: undefined reference to '_eglLinkConfig' common/egl_g3d.c:521: error: undefined reference to '_eglError' ../../../../src/egl/main/eglimage.h:127: error: undefined reference to '_eglCheckResource' common/egl_g3d_api.c:639: error: undefined reference to '_eglGetAPIContext' common/egl_g3d_api.c:584: error: undefined reference to '_eglGetCurrentContext' common/egl_g3d_api.c:126: error: undefined reference to '_eglParseConfigAttribList' common/egl_g3d_api.c:140: error: undefined reference to '_eglFilterConfigArray' common/egl_g3d_api.c:254: error: undefined reference to '_eglInitSurface' common/egl_g3d_api.c:353: error: undefined reference to '_eglInitSurface' common/egl_g3d_api.c:706: error: undefined reference to '_eglGetAPIContext' common/egl_g3d_api.c:619: error: undefined reference to '_eglGetCurrentContext' common/egl_g3d_api.c:552: error: undefined reference to '_eglGetCurrentContext' ../../../../src/egl/main/eglcontext.h:95: error: undefined reference to '_eglPutResource' common/egl_g3d_api.c:160: error: undefined reference to '_eglInitContext' ../../../../src/egl/main/eglsurface.h:118: error: undefined reference to '_eglPutResource' common/egl_g3d_api.c:493: error: undefined reference to '_eglBindContext' ../../../../src/egl/main/eglcontext.h:95: error: undefined reference to '_eglPutResource' ../../../../src/egl/main/eglsurface.h:118: error: undefined reference to '_eglPutResource' common/egl_g3d_api.c:531: error: undefined reference to '_eglBindContext' common/egl_g3d_api.c:823: error: undefined reference to '_eglInitDriverFallbacks' common/egl_g3d_api.c:103: error: undefined reference to '_eglCompareConfigs' common/egl_g3d_api.c:117: error: undefined reference to '_eglMatchConfig' cmklib: Making Linux shared library: egl_gallium.so /usr/bin/ld: error: cannot open ../../../../x86_64-linux-gnu/libEGL.so: No such file or directory egl.c:98: error: undefined reference to '_eglLog' egl.c:150: error: undefined reference to '_eglLog' egl.c:150: error: undefined reference to '_eglLog' egl.c:78: error: undefined reference to '_eglLog' egl_st.c:79: error: undefined reference to '_eglSearchPathForEach' common/egl_g3d.c:469: error: undefined reference to '_eglReleaseDisplayResources' common/egl_g3d.c:472: error: undefined reference to '_eglDestroyArray' common/egl_g3d.c:476: error: undefined reference to '_eglDestroyArray' common/egl_g3d.c:480: error: undefined reference to '_eglCleanupDisplay' common/egl_g3d.c:186: error: undefined reference to '_eglInitScreen' common/egl_g3d.c:203: error: undefined reference to '_eglLinkScreen' common/egl_g3d.c:526: error: undefined reference to '_eglError' common/egl_g3d.c:581: error: undefined reference to '_eglError' common/egl_g3d.c:510: error: undefined reference to '_eglError' common/egl_g3d.c:429: error: undefined reference to '_eglInitConfig' common/egl_g3d.c:307: error: undefined reference to '_eglValidateConfig' common/egl_g3d.c:437: error: undefined reference to '_eglLinkConfig' common/egl_g3d.c:521: error: undefined reference to '_eglError'
[Mesa-dev] [Bug 39219] libgl conflict with xbmc causes lock up on xbmc exit
https://bugs.freedesktop.org/show_bug.cgi?id=39219 Henri Verbeet hverb...@gmail.com changed: What|Removed |Added Attachment #49135|0 |1 is obsolete|| --- Comment #5 from Henri Verbeet hverb...@gmail.com 2011-07-19 04:10:11 PDT --- Created an attachment (id=49295) View: https://bugs.freedesktop.org/attachment.cgi?id=49295 Review: https://bugs.freedesktop.org/review?bug=39219attachment=49295 patch This is a slightly modified version of the same patch. If it's not too much trouble, could you give this one a try as well? If it still works I'll push it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39219] libgl conflict with xbmc causes lock up on xbmc exit
https://bugs.freedesktop.org/show_bug.cgi?id=39219 --- Comment #6 from freewindri...@rocketmail.com 2011-07-19 04:55:29 PDT --- new patch works on i686 Arch Linux (2.6.39.3) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH] dri: Do not tile stencil buffer
Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace:
Until now, the stencil buffer was allocated as a Y tiled buffer, because
in several locations the PRM states that it is. However, it is actually
W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part 2, Section
4.5.2.1 W-Major Format:
W-Major Tile Format is used for separate stencil.
The GTT is incapable of W fencing, so we allocate the stencil buffer with
I915_TILING_NONE and decode the tile's layout in software.
This commit mutually depends on the mesa commit:
intel: Fix stencil buffer to be W tiled
Author: Chad Versace c...@chad-versace.us
Date: Mon Jul 18 00:37:45 2011 -0700
CC: Eric Anholt e...@anholt.net
CC: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Chad Versace c...@chad-versace.us
---
src/intel_dri.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 5ea7c2c..4652dc7 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -336,7 +336,6 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int
attachment,
switch (attachment) {
case DRI2BufferDepth:
case DRI2BufferDepthStencil:
- case DRI2BufferStencil:
case DRI2BufferHiz:
if (SUPPORTS_YTILING(intel)) {
hint |= INTEL_CREATE_PIXMAP_TILING_Y;
@@ -351,6 +350,14 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int
attachment,
case DRI2BufferFrontRight:
hint |= INTEL_CREATE_PIXMAP_TILING_X;
break;
+ case DRI2BufferStencil:
+ /*
+ * The stencil buffer is W tiled. However, we
+ * request from the kernel a non-tiled buffer
+ * because the GTT is incapable of W fencing.
+ */
+ hint |= INTEL_CREATE_PIXMAP_TILING_NONE;
+ break;
default:
free(privates);
free(buffer);
@@ -368,11 +375,12 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int
attachment,
* To accomplish this, we resort to the nasty hack of doubling
* the drm region's cpp and halving its height.
*
- * If we neglect to double the pitch, then
- * drm_intel_gem_bo_map_gtt() maps the memory incorrectly.
+ * If we neglect to double the pitch, then render corruption
+ * occurs.
The alignment does not seem to match.
*/
if (attachment == DRI2BufferStencil) {
- pixmap_height /= 2;
+ pixmap_width = ALIGN(pixmap_width, 64);
+ pixmap_height = ALIGN(pixmap_height / 2, 64);
pixmap_cpp *= 2;
}
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH] intel: Fix stencil buffer to be W tiled
Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace: […] diff --git a/src/mesa/drivers/dri/intel/intel_span.c b/src/mesa/drivers/dri/intel/intel_span.c index 153803f..d306432 100644 --- a/src/mesa/drivers/dri/intel/intel_span.c +++ b/src/mesa/drivers/dri/intel/intel_span.c @@ -131,38 +131,77 @@ intel_set_span_functions(struct intel_context *intel, int miny = 0; \ int maxx = rb-Width; \ int maxy = rb-Height;\ - int stride = rb-RowStride; \ - uint8_t *buf = rb-Data; \ + \ + /* \ +* Here we ignore rb-Data and rb-RowStride as set by\ +* intelSpanRenderStart. Since intel_offset_S8 decodes the W tile \ +* manually, the region's *real* base address and stride is \ +* required. \ +*/ \ + struct intel_renderbuffer *irb = intel_renderbuffer(rb); \ + uint8_t *buf = irb-region-buffer-virtual; \ There are alignment/white space issues above. + unsigned stride = irb-region-pitch; \ + unsigned height = 2 * irb-region-height; \ + bool flip = rb-Name == 0; \ […] Thanks, Paul signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Using Gallium on an embedded system
Hi folks. I wonder if there is someone here who can help me wrap my brain around the code flow for getting Mesa to render with Gallium. I have an embedded system with a GPU supported by a gallium driver. I'd like to have Mesa running with hardware acceleration (OSMesa with software rendering already runs fine). According to a presentation from Tungsten, the architecture for Gallium3D looks like this: _ drm /| App - Mesa - State tracker - Gallium HW Drv - OS,Winsys \| - DRI Ok, great, so it looks like all I need to do is provide an OS,Winsys for my system, and everything above it should work without modification. But what I don't get is how the App creates and binds a context in this scenario. Normally it would call something in mesa/drivers/XXX to do that, but there is no mesa/drivers/gallium... TIA // Marcus ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38716] Can't build, error: undefined reference to `_eglFilterConfigArray'
https://bugs.freedesktop.org/show_bug.cgi?id=38716 --- Comment #14 from Jos van Wolput wol...@onsneteindhoven.nl 2011-07-19 06:22:10 PDT --- (In reply to comment #13) libEGL.so is missing. Could you switch to src/egl/main/ and make from that directory? Switching to .../mesa/src/egl/main, make now properly builds libEGL.so and egl_gallium.so Thank you very much! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Using Gallium on an embedded system
On Tue, Jul 19, 2011 at 3:42 AM, Marcus Comstedt mar...@mc.pp.se wrote: Hi folks. I wonder if there is someone here who can help me wrap my brain around the code flow for getting Mesa to render with Gallium. I have an embedded system with a GPU supported by a gallium driver. I'd like to have Mesa running with hardware acceleration (OSMesa with software rendering already runs fine). According to a presentation from Tungsten, the architecture for Gallium3D looks like this: _ drm /| App - Mesa - State tracker - Gallium HW Drv - OS,Winsys \| - DRI Ok, great, so it looks like all I need to do is provide an OS,Winsys for my system, and everything above it should work without modification. But what I don't get is how the App creates and binds a context in this scenario. The app would call eglCreateContext() or glXCreateContext() or similar. The call chain is a little complicated but eventually you'd wind up in the gallium driver's pipe_screen::context_create() method. Normally it would call something in mesa/drivers/XXX to do that, but there is no mesa/drivers/gallium... Try src/gallium/drivers/ -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Using Gallium on an embedded system
On Tue, Jul 19, 2011 at 8:02 AM, Marcus Comstedt mar...@mc.pp.se wrote: Hi Brian. Thanks for your reply. Brian Paul brian.e.p...@gmail.com writes: The app would call eglCreateContext() or glXCreateContext() or similar. It certainly wouldn't call glXCreateContext(), because there is no X. I'm making my own Winsys, remember? :-) In gallium terms winsys is basically all the stuff that's needed to interface the OS-neutral gallium driver to the OS/window system environment. I don't know what (if any) window system you might be using. If you look in src/gallium/winsys you'll see a subdir for each driver and in each of those dirs you'll see subdirs for one or more environments (dri, xlib, etc). Above all this is the GL/window system API. Examples include GLX, WGL and EGL. These interface provide functions for creating rendering contexts, binding them to drawing surfaces, etc. If you're not familiar with these you should probably read up on EGL. It's probably the most likely API for embedded projects if you're not using X. I'm not sure what egl is or whether it would help in this case. Does it interface directly with Gallium, or would even more layers of adaptation be needed? We already have all the code for using EGL with gallium drivers. Normally it would call something in mesa/drivers/XXX to do that, but there is no mesa/drivers/gallium... Try src/gallium/drivers/ Do you mean that the App should call something in src/gallium/drivers/nvfx directly? In that case, what? No. An application should only call OpenGL and EGL functions. You should probably spend some time reading up on all this. I think the khronos website has plenty of info. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Using Gallium on an embedded system
Hi Brian. Brian Paul brian.e.p...@gmail.com writes: Above all this is the GL/window system API. Examples include GLX, WGL and EGL. These interface provide functions for creating rendering contexts, binding them to drawing surfaces, etc. If you're not familiar with these you should probably read up on EGL. It's probably the most likely API for embedded projects if you're not using X. Ok, it sounds like EGL is the best way forward then. I'll check it out. Thanks again! // Marcus ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39375] New: mesa-7.11_rc1 weird colors and aliasing
https://bugs.freedesktop.org/show_bug.cgi?id=39375 Summary: mesa-7.11_rc1 weird colors and aliasing Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: patrizio.ba...@gmail.com Created an attachment (id=49299) -- (https://bugs.freedesktop.org/attachment.cgi?id=49299) color errors as reported here: https://bugs.gentoo.org/show_bug.cgi?id=375337 I'm using linux 2.6.39.3 with nouveau kms driver on a geforce 7600GT X.Org X Server 1.10.3 xf86-video-nouveau-0.0.16_pre20110711 (but with march's snapshot is the same) switching from mesa 7.10.3 to 7.11_rc1 makes text not really clear and colors are messed up as from screenshot. i tried with egl and llvm flags and without, same result. just reverting to 7.10.3 make everything fine. screenshot attached for wrong colors -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39375] mesa-7.11_rc1 weird colors and aliasing (nouveau driver)
https://bugs.freedesktop.org/show_bug.cgi?id=39375 Patrizio Bassi patrizio.ba...@gmail.com changed: What|Removed |Added Summary|mesa-7.11_rc1 weird colors |mesa-7.11_rc1 weird colors |and aliasing|and aliasing (nouveau ||driver) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39375] mesa-7.11_rc1 weird colors and aliasing (nouveau driver)
https://bugs.freedesktop.org/show_bug.cgi?id=39375 Chi-Thanh Christopher Nguyen chith...@gentoo.org changed: What|Removed |Added Component|Mesa core |Drivers/DRI/nouveau AssignedTo|mesa-dev@lists.freedesktop. |nouveau@lists.freedesktop.o |org |rg See Also||https://bugs.gentoo.org/sho ||w_bug.cgi?id=375337 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 Release Candidate 1 tarball issue
On Mon, Jul 18, 2011 at 8:05 AM, Brian Paul bri...@vmware.com wrote: On 07/17/2011 03:50 PM, Marty Jack wrote: Another problem in the RC1 tarballs appears to be src/mesa/depend. This contains a pile of references to /usr/lib/gcc/x86_64-redhat-linux/4.6.0/include and will fail if you are not on that system. With that removed I am able to build the RC1 tarballs, but that doesn't mean there isn't something else wrong in the parts that I didn't build. The depend files included in the tarball should be empty files. Looks like one of the recent changes to the top-level Makefile lost the 'tarballs' dependency on 'rm_depend'. I'll see if I can fix this later. Actually, we should just omit the 'depend' files from the tarball. In the makefiles we're using -include so there should be no harm if they're missing (but they should be regenerated at compile time anyway). -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: remove depend files from tarballs
--- Makefile | 24 1 files changed, 4 insertions(+), 20 deletions(-) diff --git a/Makefile b/Makefile index abdeb79..864ee5f 100644 --- a/Makefile +++ b/Makefile @@ -253,7 +253,6 @@ MAIN_FILES = \ $(DIRECTORY)/src/mesa/descrip.mms \ $(DIRECTORY)/src/mesa/gl.pc.in \ $(DIRECTORY)/src/mesa/osmesa.pc.in \ - $(DIRECTORY)/src/mesa/depend\ $(MAIN_ES_FILES)\ $(DIRECTORY)/src/mesa/main/*.[chS] \ $(DIRECTORY)/src/mesa/main/*.cpp\ @@ -423,15 +422,13 @@ GLW_FILES = \ $(DIRECTORY)/src/glw/*.[ch] \ $(DIRECTORY)/src/glw/Makefile* \ $(DIRECTORY)/src/glw/README \ - $(DIRECTORY)/src/glw/glw.pc.in \ - $(DIRECTORY)/src/glw/depend + $(DIRECTORY)/src/glw/glw.pc.in GLUT_FILES = \ $(DIRECTORY)/include/GL/glut.h \ $(DIRECTORY)/include/GL/glutf90.h \ $(DIRECTORY)/src/glut/glx/Makefile* \ $(DIRECTORY)/src/glut/glx/SConscript\ - $(DIRECTORY)/src/glut/glx/depend\ $(DIRECTORY)/src/glut/glx/glut.pc.in\ $(DIRECTORY)/src/glut/glx/*def \ $(DIRECTORY)/src/glut/glx/*.[ch]\ @@ -439,13 +436,6 @@ GLUT_FILES = \ $(DIRECTORY)/src/glut/beos/*.cpp\ $(DIRECTORY)/src/glut/beos/Makefile -DEPEND_FILES = \ - $(TOP)/src/mesa/depend \ - $(TOP)/src/glx/depend \ - $(TOP)/src/glw/depend \ - $(TOP)/src/glut/glx/depend \ - $(TOP)/src/glu/sgi/depend - LIB_FILES = \ $(MAIN_FILES) \ @@ -483,15 +473,9 @@ AUTOCONF = autoconf AC_FLAGS = aclocal.m4: configure.ac acinclude.m4 $(ACLOCAL) $(ACLOCAL_FLAGS) -configure: rm_depend configure.ac aclocal.m4 acinclude.m4 +configure: configure.ac aclocal.m4 acinclude.m4 $(AUTOCONF) $(AC_FLAGS) -rm_depend: - @for dep in $(DEPEND_FILES) ; do \ - rm -f $$dep ; \ - touch $$dep ; \ - done - rm_config: parsers rm -f configs/current rm -f configs/autoconf @@ -502,7 +486,7 @@ $(LIB_NAME).tar: rm_config $(LIB_NAME).tar.gz: $(LIB_NAME).tar gzip --stdout --best $(LIB_NAME).tar $(LIB_NAME).tar.gz -$(GLUT_NAME).tar: rm_depend +$(GLUT_NAME).tar: cd .. ; tar -cf $(DIRECTORY)/$(GLUT_NAME).tar $(GLUT_FILES) $(GLUT_NAME).tar.gz: $(GLUT_NAME).tar @@ -534,4 +518,4 @@ md5: $(ARCHIVES) @-md5sum $(GLUT_NAME).tar.bz2 @-md5sum $(GLUT_NAME).zip -.PHONY: tarballs rm_depend rm_config md5 +.PHONY: tarballs rm_config md5 -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
Pekka Paalanen p...@iki.fi writes: On Mon, 18 Jul 2011 08:09:17 -0600 Brian Paul bri...@vmware.com wrote: On 07/15/2011 02:59 PM, Pekka Paalanen wrote: On Fri, 15 Jul 2011 12:22:41 -0600 Brian Paulbri...@vmware.com wrote: On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com wrote: The map-texture-image-v4 branch that I just pushed implements this change. It really cleaned things up for the better and will lead to a few more follow-on improvements. There's no obvious regressions with swrast or the gallium drivers. I updated the intel driver code and tested i915 and it seems OK too, but I didn't do a full piglit run on it. I also updated the legacy r600 driver in case anyone cares but didn't do any testing of it. I didn't update any of the other legacy DRI drivers. Would anyone object if we simply stop building mach64, r128, unichrome, sis, etc? I'd be happy to remove those drivers altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. Sounds good to me. I think we'd only keep the swrast, intel and maybe r300/r600 drivers. Opinions? Um, don't kill nouveau_vieux, please. Does the old nouveau driver support some GPUs that the gallium nv50/nvc0 drivers don't support? Yes. Like Corbin said, 'nouveau_vieux' is for NV04-NV2x, while the gallium driver 'nouveau' supports NV30 and later. http://nouveau.freedesktop.org/wiki/MesaDrivers I run a couple of machines with that driver and have to disagree with that decision as well. If we want to keep the older driver someone will need to volunteer to update the code to support the new driver hooks. Sorry, I cannot promise that. Nouveau_vieux seems to have been missing a maintainer for some time now. That would be me. I admit that because of personal/work reasons I've had to keep myself somewhat out of the loop during the last couple of months, that doesn't mean that I've disappeared or stopped answering my mail. Coincidentally nouveau's texture handling has always been structured around two teximage map/unmap hooks (e.g. compare nouveau_teximage() and the look of _mesa_store_teximage2d() after the API change), and AFAICT the changes would be for the most part trivial, but still, if no-one else wants or knows how to do it (isn't fixing up the drivers the responsibility of whoever changes the API?), I'll get back to it as soon as I can. Thanks. pgpvEBc6NtDvk.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Fix stencil buffer to be W tiled
On Mon, 18 Jul 2011 17:00:54 -0700, Chad Versace c...@chad-versace.us wrote:
On 07/18/2011 08:57 AM, Eric Anholt wrote:
On Mon, 18 Jul 2011 00:55:03 -0700, Chad Versace c...@chad-versace.us
wrote:
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 1669af2..507cc33 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -173,6 +173,9 @@ intel_alloc_renderbuffer_storage(struct gl_context *
ctx, struct gl_renderbuffer
if (irb-Base.Format == MESA_FORMAT_S8) {
/*
+ * The stencil buffer is W tiled. However, we request from the
kernel a
+ * non-tiled buffer because the GTT is incapable of W fencing.
+ *
* The stencil buffer has quirky pitch requirements. From Vol 2a,
* 11.5.6.2.1 3DSTATE_STENCIL_BUFFER, field Surface Pitch:
*The pitch must be set to 2x the value computed based on
width, as
@@ -180,14 +183,14 @@ intel_alloc_renderbuffer_storage(struct gl_context *
ctx, struct gl_renderbuffer
* To accomplish this, we resort to the nasty hack of doubling the
drm
* region's cpp and halving its height.
*
- * If we neglect to double the pitch, then
drm_intel_gem_bo_map_gtt()
- * maps the memory incorrectly.
+ * If we neglect to double the pitch, then render corruption occurs.
*/
irb-region = intel_region_alloc(intel-intelScreen,
- I915_TILING_Y,
+ I915_TILING_NONE,
cpp * 2,
- width,
- height / 2,
+ ALIGN(width, 64),
+ /* XXX: Maybe align to 128? */
+ ALIGN(height / 2, 64),
GL_TRUE);
if (!irb-region)
return false;
This looks like it would fail on a buffer with height = 129.
Oops. It does fail for height = 129. Accordingly, I've changed this hunk to:
irb-region = intel_region_alloc(intel-intelScreen,
-I915_TILING_Y,
+I915_TILING_NONE,
cpp * 2,
-width,
-height / 2,
+ALIGN(width, 64),
+ALIGN((height + 1)/ 2, 64),
GL_TRUE);
And changed the same line in xf86-video-intel too.
Doesn't
seem like 128 pitch requirement would be needed -- has it been tested?
The XXX was left in the patch accidentally. 128-alignment has been tested,
and was
found unnecessary.
Looks good to me, gets the Reviewed-by: Eric Anholt e...@anholt.net
pgp8oSOJauZhM.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] meta: Add a GLSL-based _mesa_meta_Clear() variant.
On Mon, 18 Jul 2011 12:47:26 -0600, Brian Paul bri...@vmware.com wrote: On 07/18/2011 10:33 AM, Eric Anholt wrote: This cuts out a large portion of the overhead of glClear() from resetting the texenv state and recomputing the fixed function programs. It also means less use of fixed function internally in our GLES2 drivers, which is rather bogus. Looks good. Only minor comments below. Reviewed-by: Brian Paul bri...@vmware.com + _mesa_EnableVertexAttribArrayARB(0); + + vs = _mesa_CreateShaderObjectARB(GL_VERTEX_SHADER); + _mesa_ShaderSourceARB(vs, 1,vs_source, NULL); + _mesa_CompileShaderARB(vs); + + fs = _mesa_CreateShaderObjectARB(GL_FRAGMENT_SHADER); + _mesa_ShaderSourceARB(fs, 1,fs_source, NULL); + _mesa_CompileShaderARB(fs); + + clear-ShaderProg = _mesa_CreateProgramObjectARB(); + _mesa_AttachShader(clear-ShaderProg, fs); + _mesa_AttachShader(clear-ShaderProg, vs); + _mesa_BindAttribLocationARB(clear-ShaderProg, 0, position); + _mesa_LinkProgramARB(clear-ShaderProg); + + _mesa_DeleteShader(fs); + _mesa_DeleteShader(vs); I think these deletes could be omitted. It might be confusing to the casual reader. Oh, we're just relying on the hash table to free them. Sounds good (all of the review). pgpDFDUOr5Oxq.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
On Tue, Jul 19, 2011 at 11:12 AM, Francisco Jerez curroje...@riseup.net wrote: (isn't fixing up the drivers the responsibility of whoever changes the API?) That's exactly why removing old drivers is being discussed. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39338] Mesa: LLVM dependency mishmash
https://bugs.freedesktop.org/show_bug.cgi?id=39338 Johannes Obermayr johannesoberm...@gmx.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Johannes Obermayr johannesoberm...@gmx.de 2011-07-19 10:34:13 PDT --- http://cgit.freedesktop.org/mesa/mesa/commit/?id=3143e95353072523ff5d9c977a474a87fe3cbe57 Thanks Tobias. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] rationale for GLubyte pointers for strings?
Hi all, This isn't quite the right place for this question, but I've searched through old standards and googled without any luck, so hopefully somebody here knows the history behind GLubyte*. glGetString and gluErrorString, plus maybe some other functions, return GLubyte pointers instead of simply character pointers. I can't imagine an implementation does anything else internally other than use const char*'s and cast them to the type the interface requires. What's the rationale here? It appears to me to be a desire of GL to avoid depending on the std C library, but types, especially char, are part of the standard, the compiler. Anyone know the history here? Thanks, -tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rationale for GLubyte pointers for strings?
On Tue, Jul 19, 2011 at 12:20:54PM -0600, tom fogal wrote: | glGetString and gluErrorString, plus maybe some other functions, return | GLubyte pointers instead of simply character pointers... | What's the rationale here? I agree, it's odd. I don't remember the rationale, but my best guess is that it papered over some compatibility issue with another language binding (probably Fortran). I suppose there's a very slight possibility that it sprang from a compatibility issue with Cray. Allen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix the texture format in st_context_teximage
On Mon, Jul 18, 2011 at 07:31, Fredrik Höglund fred...@kde.org wrote: Commit 1a339b6c71ebab6e1a64f05b2e133022d3bbcd15 made st_ChooseTextureFormat map GL_RGBA with type GL_UNSIGNED_BYTE to PIPE_FORMAT_A8B8G8R8_UNORM. The image format for ARGB pixmaps is PIPE_FORMAT_B8G8R8A8_UNORM however. This mismatch caused the texture to be recreated in st_finalize_texture. NOTE: This is a candidate for the 7.11 branch. Yes very much so. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39209 Signed-off-by: Fredrik Höglund fred...@kde.org Reviewed-by: Stéphane Marchesin marc...@chromium.org --- src/mesa/state_tracker/st_manager.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/state_tracker/st_manager.c b/src/mesa/state_tracker/st_manager.c index 7bd82aa..d5228d3 100644 --- a/src/mesa/state_tracker/st_manager.c +++ b/src/mesa/state_tracker/st_manager.c @@ -587,7 +587,7 @@ st_context_teximage(struct st_context_iface *stctxi, internalFormat = GL_RGB; texFormat = st_ChooseTextureFormat(ctx, internalFormat, - GL_RGBA, GL_UNSIGNED_BYTE); + GL_BGRA, GL_UNSIGNED_BYTE); _mesa_init_teximage_fields(ctx, target, texImage, tex-width0, tex-height0, 1, 0, -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rationale for GLubyte pointers for strings?
SGI invented OpenGL and offered it first on their IRIX platform. SGI's MIPSpro compiler has the char datatype as unsigned by default, so the compiler would likely complain if assigning a GLbyte pointer to an [unsigned] character pointer. Thus, to do something like char* ext = glGetString(GL_VENDOR); doesn't require a cast on IRIX, while the same code would require a cast using other compilers due to the aforementioned problem. Patrick On Tue, Jul 19, 2011 at 1:44 PM, Allen Akin a...@arden.org wrote: On Tue, Jul 19, 2011 at 12:20:54PM -0600, tom fogal wrote: | glGetString and gluErrorString, plus maybe some other functions, return | GLubyte pointers instead of simply character pointers... | What's the rationale here? I agree, it's odd. I don't remember the rationale, but my best guess is that it papered over some compatibility issue with another language binding (probably Fortran). I suppose there's a very slight possibility that it sprang from a compatibility issue with Cray. Allen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rationale for GLubyte pointers for strings?
I think you have misinterpreted my question. Why not just have glGetString's prototype be: const char* glGetString(GLenum); ? Then (sans the missing const :), your code below would work on *all* platforms, MIPSpro or not, with or without a cast. -tom Patrick Baggett baggett.patr...@gmail.com writes: SGI invented OpenGL and offered it first on their IRIX platform. SGI's MIPSpro compiler has the char datatype as unsigned by default, so the compiler would likely complain if assigning a GLbyte pointer to an [unsigned] character pointer. Thus, to do something like char* ext = glGetString(GL_VENDOR); doesn't require a cast on IRIX, while the same code would require a cast using other compilers due to the aforementioned problem. Patrick On Tue, Jul 19, 2011 at 1:44 PM, Allen Akin a...@arden.org wrote: On Tue, Jul 19, 2011 at 12:20:54PM -0600, tom fogal wrote: | glGetString and gluErrorString, plus maybe some other functions, return | GLubyte pointers instead of simply character pointers... | What's the rationale here? I agree, it's odd. I don't remember the rationale, but my best guess is that it papered over some compatibility issue with another language binding (probably Fortran). I suppose there's a very slight possibility that it sprang from a compatibility issue with Cray. Allen ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rationale for GLubyte pointers for strings?
On 19 July 2011 21:39, tom fogal tfo...@sci.utah.edu wrote: I think you have misinterpreted my question. Why not just have glGetString's prototype be: const char* glGetString(GLenum); ? Then (sans the missing const :), your code below would work on *all* platforms, MIPSpro or not, with or without a cast. IIRC the idea was for the GL spec to be language independent, or something along those lines. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH] intel: Fix stencil buffer to be W tiled
On 07/18/2011 01:20 AM, Paul Menzel wrote: Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace: There are alignment/white space issues above. + unsigned stride = irb-region-pitch;\ + unsigned height = 2 * irb-region-height; \ + bool flip = rb-Name == 0; \ […] Thanks, Paul Thanks. Fix whitespace in both patches. -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] glsl: Create a standalone executable for testing optimization passes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2011 03:30 PM, Paul Berry wrote: This patch adds a new build artifact, glsl_test, which can be used for testing optimization passes in isolation. I'm hoping that we will be able to add other useful standalone tests to this executable in the future. Accordingly, it is built in a modular fashion: the main() function uses its first argument to determine which test function to invoke, removes that argument from argv[], and then calls that function to interpret the rest of the command line arguments and perform the test. Currently the only test function is optpass, which tests optimization passes. A couple of comments... We'll probably have to tweak the build a bit to be sure everything ends up in the tarballs. Since José's changes recently this may not be as much of a problem, but we'll at least want to test it. We can do that on Wednesday. There are a couple other comments below... --- src/glsl/.gitignore |1 + src/glsl/Makefile | 23 +++- src/glsl/test.cpp | 78 src/glsl/test_optpass.cpp | 289 + src/glsl/test_optpass.h | 30 + 5 files changed, 418 insertions(+), 3 deletions(-) create mode 100644 src/glsl/test.cpp create mode 100644 src/glsl/test_optpass.cpp create mode 100644 src/glsl/test_optpass.h diff --git a/src/glsl/.gitignore b/src/glsl/.gitignore index dfbd572..d26839a 100644 --- a/src/glsl/.gitignore +++ b/src/glsl/.gitignore @@ -5,3 +5,4 @@ glsl_parser.h glsl_parser.output builtin_function.cpp builtin_compiler +glsl_test diff --git a/src/glsl/Makefile b/src/glsl/Makefile index e0776c1..f574e27 100644 --- a/src/glsl/Makefile +++ b/src/glsl/Makefile @@ -88,7 +88,7 @@ CXX_SOURCES = \ LIBS = \ $(TOP)/src/glsl/libglsl.a -APPS = glsl_compiler glcpp/glcpp +APPS = glsl_compiler glsl_test glcpp/glcpp GLSL2_C_SOURCES = \ ../mesa/program/hash_table.c \ @@ -100,6 +100,18 @@ GLSL2_OBJECTS = \ $(GLSL2_C_SOURCES:.c=.o) \ $(GLSL2_CXX_SOURCES:.cpp=.o) +TEST_C_SOURCES = \ + ../mesa/program/hash_table.c \ + ../mesa/program/symbol_table.c + +TEST_CXX_SOURCES = \ + test.cpp \ + test_optpass.cpp + +TEST_OBJECTS = \ + $(TEST_C_SOURCES:.c=.o) \ + $(TEST_CXX_SOURCES:.cpp=.o) + ### Basic defines ### DEFINES += \ @@ -128,7 +140,9 @@ ALL_SOURCES = \ $(C_SOURCES) \ $(CXX_SOURCES) \ $(GLSL2_CXX_SOURCES) \ - $(GLSL2_C_SOURCES) + $(GLSL2_C_SOURCES) \ + $(TEST_CXX_SOURCES) \ + $(TEST_C_SOURCES) # TARGETS # @@ -150,7 +164,7 @@ depend: $(ALL_SOURCES) Makefile # Remove .o and backup files clean: clean-dricore - rm -f $(GLCPP_OBJECTS) $(GLSL2_OBJECTS) $(OBJECTS) lib$(LIBNAME).a depend depend.bak builtin_function.cpp builtin_function.o builtin_stubs.o builtin_compiler + rm -f $(GLCPP_OBJECTS) $(GLSL2_OBJECTS) $(TEST_OBJECTS) $(OBJECTS) lib$(LIBNAME).a depend depend.bak builtin_function.cpp builtin_function.o builtin_stubs.o builtin_compiler -rm -f $(APPS) clean-dricore: @@ -173,6 +187,9 @@ install-dricore: default glsl_compiler: $(GLSL2_OBJECTS) libglsl.a builtin_stubs.o $(APP_CXX) $(INCLUDES) $(CFLAGS) $(LDFLAGS) $(GLSL2_OBJECTS) builtin_stubs.o $(LIBS) -o $@ +glsl_test: $(TEST_OBJECTS) libglsl.a builtin_stubs.o + $(APP_CXX) $(INCLUDES) $(CFLAGS) $(LDFLAGS) $(TEST_OBJECTS) builtin_stubs.o $(LIBS) -o $@ + glcpp: glcpp/glcpp glcpp/glcpp: $(GLCPP_OBJECTS) $(APP_CC) $(INCLUDES) $(CFLAGS) $(LDFLAGS) $(GLCPP_OBJECTS) -o $@ diff --git a/src/glsl/test.cpp b/src/glsl/test.cpp new file mode 100644 index 000..b1ff92e --- /dev/null +++ b/src/glsl/test.cpp @@ -0,0 +1,78 @@ +/* + * Copyright © 2011 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the Software), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + *
Re: [Mesa-dev] [PATCH 1/4] mesa: Add an ifndef guard around the definition of the INLINE macro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/18/2011 02:28 PM, Paul Berry wrote: On 18 July 2011 11:58, Brian Paul bri...@vmware.com wrote: On 07/18/2011 12:37 PM, Paul Berry wrote: Several headers redundantly define the INLINE macro. Adding this guard prevents the compiler from complaining about macro redefinition. Other Mesa headers? Or system headers? Or? Other Mesa headers. I found definitions of INLINE in four header files: src/egl/main/eglcompiler.h src/gallium/include/pipe/p_compiler.h src/mapi/mapi/u_compiler.h src/mesa/main/compiler.h None of those headers should ever cross paths. The only one of those that anything under src/mesa/main or src/glsl should *ever* hit is src/mesa/main/compiler.h. Where did the colliding definition come from? Ideally we should put all of our definitions of INLINE in one place, but I was doing enough in other parts of the patch series that I didn't want to shave that particular yak :) I'll update the commit comment to clarify. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4l5e0ACgkQX1gOwKyEAw+QVwCgk1cdXMlGsADztGASrpRnNnXR XVcAoJPPwaYzwNEkDtB+H2hZbqNTqXzh =XXUE -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove depend files from tarballs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/19/2011 08:29 AM, Brian Paul wrote: Won't this add an extra dependency (on makedepend) in the tarballs? I thought that was the reason for including the empty depend files in the first place. Right? --- Makefile | 24 1 files changed, 4 insertions(+), 20 deletions(-) diff --git a/Makefile b/Makefile index abdeb79..864ee5f 100644 --- a/Makefile +++ b/Makefile @@ -253,7 +253,6 @@ MAIN_FILES = \ $(DIRECTORY)/src/mesa/descrip.mms \ $(DIRECTORY)/src/mesa/gl.pc.in \ $(DIRECTORY)/src/mesa/osmesa.pc.in \ - $(DIRECTORY)/src/mesa/depend\ $(MAIN_ES_FILES)\ $(DIRECTORY)/src/mesa/main/*.[chS] \ $(DIRECTORY)/src/mesa/main/*.cpp\ @@ -423,15 +422,13 @@ GLW_FILES = \ $(DIRECTORY)/src/glw/*.[ch] \ $(DIRECTORY)/src/glw/Makefile* \ $(DIRECTORY)/src/glw/README \ - $(DIRECTORY)/src/glw/glw.pc.in \ - $(DIRECTORY)/src/glw/depend + $(DIRECTORY)/src/glw/glw.pc.in GLUT_FILES = \ $(DIRECTORY)/include/GL/glut.h \ $(DIRECTORY)/include/GL/glutf90.h \ $(DIRECTORY)/src/glut/glx/Makefile* \ $(DIRECTORY)/src/glut/glx/SConscript\ - $(DIRECTORY)/src/glut/glx/depend\ $(DIRECTORY)/src/glut/glx/glut.pc.in\ $(DIRECTORY)/src/glut/glx/*def \ $(DIRECTORY)/src/glut/glx/*.[ch]\ @@ -439,13 +436,6 @@ GLUT_FILES = \ $(DIRECTORY)/src/glut/beos/*.cpp\ $(DIRECTORY)/src/glut/beos/Makefile -DEPEND_FILES = \ - $(TOP)/src/mesa/depend \ - $(TOP)/src/glx/depend \ - $(TOP)/src/glw/depend \ - $(TOP)/src/glut/glx/depend \ - $(TOP)/src/glu/sgi/depend - LIB_FILES = \ $(MAIN_FILES) \ @@ -483,15 +473,9 @@ AUTOCONF = autoconf AC_FLAGS = aclocal.m4: configure.ac acinclude.m4 $(ACLOCAL) $(ACLOCAL_FLAGS) -configure: rm_depend configure.ac aclocal.m4 acinclude.m4 +configure: configure.ac aclocal.m4 acinclude.m4 $(AUTOCONF) $(AC_FLAGS) -rm_depend: - @for dep in $(DEPEND_FILES) ; do \ - rm -f $$dep ; \ - touch $$dep ; \ - done - rm_config: parsers rm -f configs/current rm -f configs/autoconf @@ -502,7 +486,7 @@ $(LIB_NAME).tar: rm_config $(LIB_NAME).tar.gz: $(LIB_NAME).tar gzip --stdout --best $(LIB_NAME).tar $(LIB_NAME).tar.gz -$(GLUT_NAME).tar: rm_depend +$(GLUT_NAME).tar: cd .. ; tar -cf $(DIRECTORY)/$(GLUT_NAME).tar $(GLUT_FILES) $(GLUT_NAME).tar.gz: $(GLUT_NAME).tar @@ -534,4 +518,4 @@ md5: $(ARCHIVES) @-md5sum $(GLUT_NAME).tar.bz2 @-md5sum $(GLUT_NAME).zip -.PHONY: tarballs rm_depend rm_config md5 +.PHONY: tarballs rm_config md5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4l69cACgkQX1gOwKyEAw+aLwCeMLKSKUzFWXps4TXdKiCvi/zQ dZoAn1uLNQGjR/Irrf60DOUWpwFCMcFn =7fjo -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] meta: Add a GLSL-based _mesa_meta_Clear() variant.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 09:33 AM, Eric Anholt wrote:
This cuts out a large portion of the overhead of glClear() from
resetting the texenv state and recomputing the fixed function
programs. It also means less use of fixed function internally in our
GLES2 drivers, which is rather bogus.
---
src/mesa/drivers/common/meta.c | 166
src/mesa/drivers/common/meta.h |3 +
2 files changed, 169 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 0e58aec..09d7186 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -62,6 +62,7 @@
#include main/teximage.h
#include main/texparam.h
#include main/texstate.h
+#include main/uniforms.h
#include main/varray.h
#include main/viewport.h
#include program/program.h
@@ -235,6 +236,8 @@ struct clear_state
{
GLuint ArrayObj;
GLuint VBO;
+ GLuint ShaderProg;
+ GLint ColorLocation;
};
@@ -1589,6 +1592,169 @@ _mesa_meta_Clear(struct gl_context *ctx, GLbitfield
buffers)
_mesa_meta_end(ctx);
}
+static void
+meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear)
+{
+ const char *vs_source =
+ attribute vec4 position;\n
+ void main()\n
+ {\n
+ gl_Position = position;\n
+ }\n;
+ const char *fs_source =
+ uniform vec4 color;\n
+ void main()\n
+ {\n
+ gl_FragColor = color;\n
+ }\n;
+ GLuint vs, fs;
+
+ if (clear-ArrayObj != 0)
+ return;
+
+ /* create vertex array object */
+ _mesa_GenVertexArrays(1, clear-ArrayObj);
+ _mesa_BindVertexArray(clear-ArrayObj);
+
+ /* create vertex array buffer */
+ _mesa_GenBuffersARB(1, clear-VBO);
+ _mesa_BindBufferARB(GL_ARRAY_BUFFER_ARB, clear-VBO);
+
+ /* setup vertex arrays */
+ _mesa_VertexAttribPointerARB(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float),
+ (void *)0);
+ _mesa_EnableVertexAttribArrayARB(0);
+
+ vs = _mesa_CreateShaderObjectARB(GL_VERTEX_SHADER);
+ _mesa_ShaderSourceARB(vs, 1, vs_source, NULL);
+ _mesa_CompileShaderARB(vs);
+
+ fs = _mesa_CreateShaderObjectARB(GL_FRAGMENT_SHADER);
+ _mesa_ShaderSourceARB(fs, 1, fs_source, NULL);
+ _mesa_CompileShaderARB(fs);
+
+ clear-ShaderProg = _mesa_CreateProgramObjectARB();
+ _mesa_AttachShader(clear-ShaderProg, fs);
+ _mesa_AttachShader(clear-ShaderProg, vs);
+ _mesa_BindAttribLocationARB(clear-ShaderProg, 0, position);
+ _mesa_LinkProgramARB(clear-ShaderProg);
+
+ _mesa_DeleteShader(fs);
+ _mesa_DeleteShader(vs);
+
+ clear-ColorLocation = _mesa_GetUniformLocationARB(clear-ShaderProg,
+ color);
+}
+
+/**
+ * Meta implementation of ctx-Driver.Clear() in terms of polygon rendering.
+ */
+void
+_mesa_meta_glsl_Clear(struct gl_context *ctx, GLbitfield buffers)
+{
+ struct clear_state *clear = ctx-Meta-Clear;
+ /* save all state but scissor, pixel pack/unpack */
+ GLbitfield metaSave = (META_ALL -
+ META_SCISSOR -
+ META_PIXEL_STORE -
+ META_CONDITIONAL_RENDER);
+ const GLuint stencilMax = (1 ctx-DrawBuffer-Visual.stencilBits) - 1;
+ struct gl_framebuffer *fb = ctx-DrawBuffer;
+ const float x0 = ((float)fb-_Xmin / fb-Width) * 2.0 - 1.0;
+ const float y0 = ((float)fb-_Ymin / fb-Height) * 2.0 - 1.0;
+ const float x1 = ((float)fb-_Xmax / fb-Width) * 2.0 - 1.0;
+ const float y1 = ((float)fb-_Ymax / fb-Height) * 2.0 - 1.0;
+ const float z = -invert_z(ctx-Depth.Clear);
+ struct vertex {
+ GLfloat x, y, z;
+ } verts[4];
+
+ metaSave = (META_ALPHA_TEST |
+META_BLEND |
+META_DEPTH_TEST |
+META_RASTERIZATION |
+META_SHADER |
+META_STENCIL_TEST |
+META_VERTEX |
+META_VIEWPORT |
+META_CLAMP_FRAGMENT_COLOR);
Why is metaSave initialized twice? Also, BITS - OTHER_BITS - MORE_BITS
is non-obvious. This should result in the same compile-time constant as
BITS ~(OTHER_BITS | MORE_BITS), right?
+
+ if (!(buffers BUFFER_BITS_COLOR)) {
+ /* We'll use colormask to disable color writes. Otherwise,
+ * respect color mask
+ */
+ metaSave |= META_COLOR_MASK;
+ }
+
+ _mesa_meta_begin(ctx, metaSave);
+
+ meta_glsl_clear_init(ctx, clear);
+
+ _mesa_UseProgramObjectARB(clear-ShaderProg);
+ _mesa_Uniform4fvARB(clear-ColorLocation, 1,
+ctx-Color.ClearColorUnclamped);
+
+ _mesa_BindVertexArray(clear-ArrayObj);
+ _mesa_BindBufferARB(GL_ARRAY_BUFFER_ARB, clear-VBO);
+
+ /* GL_COLOR_BUFFER_BIT */
+ if (buffers BUFFER_BITS_COLOR) {
+ /* leave colormask, glDrawBuffer state as-is */
+
+ /* Clears never have the color clamped.
Re: [Mesa-dev] [PATCH 2/2] intel: Use the GLSL-based meta clear when available.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 09:33 AM, Eric Anholt wrote:
Improves glxgears performance 19.6% +/- 7.3% (second fps printout.
n=5).
glxgearsisnotabenchmark. Is there *any* other number that could be
quoted here? This *will* bite you later. :)
---
src/mesa/drivers/dri/intel/intel_clear.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_clear.c
b/src/mesa/drivers/dri/intel/intel_clear.c
index dfca03c..35a9948 100644
--- a/src/mesa/drivers/dri/intel/intel_clear.c
+++ b/src/mesa/drivers/dri/intel/intel_clear.c
@@ -182,7 +182,10 @@ intelClear(struct gl_context *ctx, GLbitfield mask)
if (tri_mask) {
debug_mask(tri, tri_mask);
- _mesa_meta_Clear(intel-ctx, tri_mask);
+ if (ctx-Extensions.ARB_fragment_shader)
+ _mesa_meta_glsl_Clear(intel-ctx, tri_mask);
+ else
+ _mesa_meta_Clear(intel-ctx, tri_mask);
}
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4l7YUACgkQX1gOwKyEAw/bKwCeJyteAfI5yzn5rqB1x61qvHAs
R9AAoIphxDQikt4veXCrwHLXUSOydPPv
=6rl/
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove depend files from tarballs
On 07/19/2011 02:40 PM, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/19/2011 08:29 AM, Brian Paul wrote: Won't this add an extra dependency (on makedepend) in the tarballs? I thought that was the reason for including the empty depend files in the first place. Right? It shouldn't make any difference since when the makefiles include the depend files we use -include depend (don't error if file is missing). We pretty much require GNU make nowadays. When we used to care about other versions of make we couldn't use -include everywhere and we'd crap out if include depend failed. Also, I found that we weren't including a complete set of depend files in the tarball anyway. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] meta: Add a GLSL-based _mesa_meta_Clear() variant.
On 07/19/2011 01:46 PM, Ian Romanick wrote:
On 07/18/2011 09:33 AM, Eric Anholt wrote:
This cuts out a large portion of the overhead of glClear() from
resetting the texenv state and recomputing the fixed function
programs. It also means less use of fixed function internally in our
GLES2 drivers, which is rather bogus.
---
src/mesa/drivers/common/meta.c | 166
src/mesa/drivers/common/meta.h |3 +
2 files changed, 169 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 0e58aec..09d7186 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -62,6 +62,7 @@
#include main/teximage.h
#include main/texparam.h
#include main/texstate.h
+#include main/uniforms.h
#include main/varray.h
#include main/viewport.h
#include program/program.h
@@ -235,6 +236,8 @@ struct clear_state
{
GLuint ArrayObj;
GLuint VBO;
+ GLuint ShaderProg;
+ GLint ColorLocation;
};
@@ -1589,6 +1592,169 @@ _mesa_meta_Clear(struct gl_context *ctx, GLbitfield
buffers)
_mesa_meta_end(ctx);
}
+static void
+meta_glsl_clear_init(struct gl_context *ctx, struct clear_state *clear)
+{
+ const char *vs_source =
+ attribute vec4 position;\n
+ void main()\n
+ {\n
+ gl_Position = position;\n
+ }\n;
+ const char *fs_source =
+ uniform vec4 color;\n
+ void main()\n
+ {\n
+ gl_FragColor = color;\n
+ }\n;
+ GLuint vs, fs;
+
+ if (clear-ArrayObj != 0)
+ return;
+
+ /* create vertex array object */
+ _mesa_GenVertexArrays(1, clear-ArrayObj);
+ _mesa_BindVertexArray(clear-ArrayObj);
+
+ /* create vertex array buffer */
+ _mesa_GenBuffersARB(1, clear-VBO);
+ _mesa_BindBufferARB(GL_ARRAY_BUFFER_ARB, clear-VBO);
+
+ /* setup vertex arrays */
+ _mesa_VertexAttribPointerARB(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float),
+(void *)0);
+ _mesa_EnableVertexAttribArrayARB(0);
+
+ vs = _mesa_CreateShaderObjectARB(GL_VERTEX_SHADER);
+ _mesa_ShaderSourceARB(vs, 1, vs_source, NULL);
+ _mesa_CompileShaderARB(vs);
+
+ fs = _mesa_CreateShaderObjectARB(GL_FRAGMENT_SHADER);
+ _mesa_ShaderSourceARB(fs, 1, fs_source, NULL);
+ _mesa_CompileShaderARB(fs);
+
+ clear-ShaderProg = _mesa_CreateProgramObjectARB();
+ _mesa_AttachShader(clear-ShaderProg, fs);
+ _mesa_AttachShader(clear-ShaderProg, vs);
+ _mesa_BindAttribLocationARB(clear-ShaderProg, 0, position);
+ _mesa_LinkProgramARB(clear-ShaderProg);
+
+ _mesa_DeleteShader(fs);
+ _mesa_DeleteShader(vs);
+
+ clear-ColorLocation = _mesa_GetUniformLocationARB(clear-ShaderProg,
+ color);
+}
+
+/**
+ * Meta implementation of ctx-Driver.Clear() in terms of polygon rendering.
+ */
+void
+_mesa_meta_glsl_Clear(struct gl_context *ctx, GLbitfield buffers)
+{
+ struct clear_state *clear = ctx-Meta-Clear;
+ /* save all state but scissor, pixel pack/unpack */
+ GLbitfield metaSave = (META_ALL -
+ META_SCISSOR -
+ META_PIXEL_STORE -
+ META_CONDITIONAL_RENDER);
+ const GLuint stencilMax = (1 ctx-DrawBuffer-Visual.stencilBits) - 1;
+ struct gl_framebuffer *fb = ctx-DrawBuffer;
+ const float x0 = ((float)fb-_Xmin / fb-Width) * 2.0 - 1.0;
+ const float y0 = ((float)fb-_Ymin / fb-Height) * 2.0 - 1.0;
+ const float x1 = ((float)fb-_Xmax / fb-Width) * 2.0 - 1.0;
+ const float y1 = ((float)fb-_Ymax / fb-Height) * 2.0 - 1.0;
+ const float z = -invert_z(ctx-Depth.Clear);
+ struct vertex {
+ GLfloat x, y, z;
+ } verts[4];
+
+ metaSave = (META_ALPHA_TEST |
+ META_BLEND |
+ META_DEPTH_TEST |
+ META_RASTERIZATION |
+ META_SHADER |
+ META_STENCIL_TEST |
+ META_VERTEX |
+ META_VIEWPORT |
+ META_CLAMP_FRAGMENT_COLOR);
Why is metaSave initialized twice?
Yeah, that seems like a copy and paste bug.
Also, BITS - OTHER_BITS - MORE_BITS
is non-obvious. This should result in the same compile-time constant as
BITS ~(OTHER_BITS | MORE_BITS), right?
I agree, it's confusing. Copy and pasted from the original clear code.
And yes, that should be equivalent.
--Kenneth
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] i965: Enable the PIPE_CONTROL workaround workaround out of paranoia.
There's scary stuff going on in PIPE_CONTROL internals, and if the
BSpec says to do this to make PIPE_CONTROL work, I'll go ahead and do
it because we'll probably never be able to debug it after the fact.
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c | 32 +--
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index 9c97ef2..6a5f934 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -308,12 +308,30 @@ emit:
* [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache Flush Enable
* =1, a PIPE_CONTROL with any non-zero post-sync-op is required.
*
- * XXX: There is also a workaround that would appear to apply to this
- * workaround, but it doesn't appear to be necessary so far:
+ * And the workaround for these two requires this workaround first:
*
- * Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent
+ * [Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent
* BEFORE the pipe-control with a post-sync op and no write-cache
* flushes.
+ *
+ * And this last workaround is tricky because of the requirements on
+ * that bit. From section 1.4.7.2.3 Stall of the Sandy Bridge PRM
+ * volume 2 part 1:
+ *
+ * 1 of the following must also be set:
+ * - Render Target Cache Flush Enable ([12] of DW1)
+ * - Depth Cache Flush Enable ([0] of DW1)
+ * - Stall at Pixel Scoreboard ([1] of DW1)
+ * - Depth Stall ([13] of DW1)
+ * - Post-Sync Operation ([13] of DW1)
+ * - Notify Enable ([8] of DW1)
+ *
+ * The cache flushes require the workaround flush that triggered this
+ * one, so we can't use it. Post-sync nonzero is what triggered this
+ * workaround, so we can't use that one either. Notify enable is
+ * IRQs, which aren't really our business. That leaves depth stall or
+ * stall at scoreboard. It shouldn't matter which we choose because
+ * we're supposed to be stalling the entire pipeline anyway.
*/
void
intel_emit_post_sync_nonzero_flush(struct intel_context *intel)
@@ -323,6 +341,14 @@ intel_emit_post_sync_nonzero_flush(struct intel_context
*intel)
BEGIN_BATCH(4);
OUT_BATCH(_3DSTATE_PIPE_CONTROL);
+ OUT_BATCH(PIPE_CONTROL_CS_STALL |
+PIPE_CONTROL_DEPTH_STALL);
+ OUT_BATCH(0); /* address */
+ OUT_BATCH(0); /* write data */
+ ADVANCE_BATCH();
+
+ BEGIN_BATCH(4);
+ OUT_BATCH(_3DSTATE_PIPE_CONTROL);
OUT_BATCH(PIPE_CONTROL_WRITE_IMMEDIATE);
OUT_RELOC(intel-batch.workaround_bo,
I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION, 0);
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] glsl: Create a standalone executable for testing optimization passes.
On 19 July 2011 13:15, Ian Romanick i...@freedesktop.org wrote:
We'll probably have to tweak the build a bit to be sure everything ends
up in the tarballs. Since José's changes recently this may not be as
much of a problem, but we'll at least want to test it. We can do that
on Wednesday.
Ok, cool. Are the tarballs meant to contain both source and
installation artifacts, or just installation artifacts? Because the
unit tests are only intended to be run via make check--they aren't
intended to be part of the final install.
+static const char *extract_command_from_argv(int *argc, char **argv)
+{
+ if (*argc 2) {
+ usage_fail(argv[0]);
+ }
+ const char *command = argv[1];
+ --*argc;
+ memmove(argv[1], argv[2], (*argc) * sizeof(argv[1]));
+ return command;
+}
This feels like an odd re-invention of getopt. Why?
My intention was to allow the glsl_test executable to exhibit
significantly different functionality (including taking different
options) based on its first argument, much in the same way that git
log takes different options from git commit. I'm not aware of a
way to support this functionality directly in getopt, so what I did is
used extract_command_from_argv() to extract the first argument, and
then based on that argument I decide which behavior to invoke, and
that behavior uses getopt to parse whatever particular options it
supports.
There's a bit of planning-for-the-future going on here, since at the
moment glsl_test only supports one possible value for its first
argument, namely optpass.
+static struct gl_shader *
+_mesa_new_shader(struct gl_context *ctx, GLuint name, GLenum type)
+{
+ struct gl_shader *shader;
+
+ (void) ctx;
+
+ assert(type == GL_FRAGMENT_SHADER || type == GL_VERTEX_SHADER);
+ shader = rzalloc(NULL, struct gl_shader);
+ if (shader) {
+ shader-Type = type;
+ shader-Name = name;
+ shader-RefCount = 1;
+ }
+ return shader;
+}
Another candidate for refactoring. :) Since this can't go in
glsl_parser_utils.cpp, the common bits of scaffolding should probably go
in their own file. Perhaps src/glsl/standalone_scaffolding.cpp?
Yeah, true. I'll take care of this.
It looks like there's a bit of code below for reading the shader file
that could use the same treatment.
I assume you're talking about read_stdin_to_eof(), below. By the
same treatment do you mean moving into
src/glsl/standalone_scaffolding.cpp or avoiding code duplication
with the builtin compiler? I can certainly move it into
scandalone_scaffolding.cpp, but it doesn't duplicate things the
builtin compiler does because the builtin compiler reads from a file,
and it determines the file's length by seeking to the end--that won't
work on stdin. (The reason I had test_optpass.cpp read from stdin was
so that the unit tests wouldn't have to create temporary files).
+
+static string read_stdin_to_eof()
+{
+ stringbuf sb;
+ cin.get(sb, '\0');
+ return sb.str();
+}
Why are you mixing C++ iostreams and C FILE I/O? That seems weird. I'd
prefer to stick with C FILE I/O because everybody on the project knows
that well, but the real preference is to not mix and match.
I realize I'm at risk of starting a feud here, but in general I prefer
C++ library functions because they are less vulnerable to bugs like
buffer overruns. I've been trying to restrain myself from using too
many C++ idioms, since they seem to be frowned upon in Mesa, but in
this particular case, the C++ version is so much more straightforward
than the C version that it seemed worth rocking the boat. The C
version of this function, if I'm not mistaken, looks something like
this:
static char *read_stdin_to_eof()
{
char buffer[4096] = \0;
size_t len = 0;
char *result = (char *) malloc(1);
while(fgets(buffer, sizeof(buffer), stdin))
{
size_t bytes_read = strlen(buffer);
result = (char *) realloc(result, len + bytes_read + 1);
memcpy(result + len, buffer, bytes_read);
len += bytes_read;
}
result[len] = '\0';
return result;
}
There's a number of places where you need to be careful: making sure
to allocate result before the while loop (so that if the first call to
fgets() returns NULL we won't segfault), remembering to leave room for
the null terminator when realloc-ing the result, remembering to tack
the null terminator on at the end of the function, and remembering to
have the caller free the memory. The C++ version is less than half
the length and has none of these subtleties.
Since your primary concern is mixing and matching between the use of C
and C++ libraries, I would argue for moving toward C++ libraries,
since they are less prone to bugs.
As to people knowing C libraries better than C++ libraries, that is
going to become less and less true over time as C++ ages and matures,
and people start joining the project who learned the C++ library
functions before the C ones. In fact, I would argue that the turnover
point has
[Mesa-dev] Mesa 7.11 release candidate 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mesa 7.11-rc2 has been released. This is a release candidate for the 7.11 development release. The tag in the GIT repository for Mesa 7.11-rc2 is 'mesa-7.11-rc2'. Mesa 7.11-rc2 is available for download at ftp://freedesktop.org/pub/mesa/7.11/ md5sums: 108fa6beccfb091c39e3fa44e8b91f5a MesaLib-7.11-rc2.tar.gz caf5f553a4a3f98207bd3b30b3c7eb2e MesaLib-7.11-rc2.tar.bz2 a382b6bbf0e6984487862272b6d4d31e MesaLib-7.11-rc2.zip 606806b4cbfafadbe2313de0878895a4 MesaGLUT-7.11-rc2.tar.gz 996aea3cca40bb34c0a9027411924879 MesaGLUT-7.11-rc2.tar.bz2 cd3cbcd1cd407223940870a70b2521b9 MesaGLUT-7.11-rc2.zip I have verified building from the .tar.bz2 file by doing: tar -xjf MesaLib-7.11-rc2.tar.bz2 cd Mesa-7.11-rc2 PKG_CONFIG_PATH=/opt/xorg-master-x86_64/lib64/pkgconfig/ ./configure PKG_CONFIG_PATH=/opt/xorg-master-x86_64/lib64/pkgconfig/ make -j6 My current plan is for RC3 to be on Monday 7/25 with a final release on Friday 7/29. Once we hit RC3, the only changes in the 7.11 branch (until the final release) should be low-risk fixes for significant bugs. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4mGAIACgkQX1gOwKyEAw/3RgCfWaS1krMHtAjeraOcAvFWxBlk 55YAmwUhnOuAp9YwhFBnbuhE/7GMKmAg =ZHZD -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove depend files from tarballs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/19/2011 02:09 PM, Brian Paul wrote: On 07/19/2011 02:40 PM, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/19/2011 08:29 AM, Brian Paul wrote: Won't this add an extra dependency (on makedepend) in the tarballs? I thought that was the reason for including the empty depend files in the first place. Right? It shouldn't make any difference since when the makefiles include the depend files we use -include depend (don't error if file is missing). We pretty much require GNU make nowadays. When we used to care about other versions of make we couldn't use -include everywhere and we'd crap out if include depend failed. Also, I found that we weren't including a complete set of depend files in the tarball anyway. I just noticed that as well. I'm going to put my Reviewed-by on your patch and put it in RC2. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4mGJ4ACgkQX1gOwKyEAw8wsQCggWyw1VUjJLvzrr6DGmPeHp0p dmYAnj60KlyJOwmjZXdpwCvhY8xlAibm =5N56 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] mesa: Add an ifndef guard around the definition of the INLINE macro
On 19 July 2011 13:15, Ian Romanick i...@freedesktop.org wrote: src/egl/main/eglcompiler.h src/gallium/include/pipe/p_compiler.h src/mapi/mapi/u_compiler.h src/mesa/main/compiler.h None of those headers should ever cross paths. The only one of those that anything under src/mesa/main or src/glsl should *ever* hit is src/mesa/main/compiler.h. Where did the colliding definition come from? The colliding definition was in src/mapi/mapi/u_compiler.h. At least one of the conflicting paths is: glsl/link_functions.cpp includes mesa/main/core.h, which includes mesa/main/mtypes.h, which includes mapi/glapi/glapi.h, which includes mapi/glapi/glthread.h, which includes mapi/mapi/u_thread.h, which includes mapi/mapi/u_compiler.h mesa/main/core.h also includes mesa/main/compiler.h I don't know whether there are other conflicting paths. This conflict doesn't lead to compile errors right now (presumably because mesa/main/compiler.h gets included first, and the definition of INLINE in mapi/mapi/u_compiler.h only happens if INLINE is not already defined). However, in patch 2/4 of this patch series, I had to make glsl/glsl_parser_extras.h include main/mtypes.h (so that I could add a function to glsl_parser_extras.h that referred to gl_api). That must have changed the order in which the files get included so that mapi/mapi/u_compiler.h got included first. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i965: Enable the PIPE_CONTROL workaround workaround out of paranoia.
On Tue, 19 Jul 2011 15:44:11 -0700, Eric Anholt e...@anholt.net wrote: There's scary stuff going on in PIPE_CONTROL internals, and if the BSpec says to do this to make PIPE_CONTROL work, I'll go ahead and do it because we'll probably never be able to debug it after the fact. For this and the following patch, if a reviewer could in particular confirm that the set of bits chosen match up to the requirements from the PRM mentioned in the comments for this one, that would be great. pgphLU6JwxkGI.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: GLES2 should return different error enums for invalid fbo queries
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 06:11 PM, Marek Olšák wrote:
ES 2.0.25 page 127 says:
If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then
querying any other pname will generate INVALID_ENUM.
Hurray for be different just for the sake of being different!
See also:
b9e9df78a03edb35472c2e231aef4747e09db792
NOTE: This is a candidate for the 7.10 and 7.11 branches.
---
src/mesa/main/fbobject.c | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 8496936..1e11513 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2134,10 +2134,13 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
{
const struct gl_renderbuffer_attachment *att;
struct gl_framebuffer *buffer;
+ GLboolean is_gl;
GET_CURRENT_CONTEXT(ctx);
ASSERT_OUTSIDE_BEGIN_END(ctx);
+ is_gl = ctx-API == API_OPENGL;
+
Maybe this would be better
GLenum err = (ctx-API == API_OPENGL) ? GL_INVALID_OPERATION :
GL_INVALID_ENUM;
Every time I look at error generation code in Mesa, I feel a little ill.
It always ends up being so much ugly code. meh.
buffer = get_framebuffer_target(ctx, target);
if (!buffer) {
_mesa_error(ctx, GL_INVALID_ENUM,
@@ -2188,7 +2191,12 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
}
else {
assert(att-Type == GL_NONE);
- *params = 0;
+ if (is_gl) {
+*params = 0;
+ } else {
+_mesa_error(ctx, GL_INVALID_ENUM,
+glGetFramebufferAttachmentParameterivEXT(pname));
+ }
}
return;
case GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL_EXT:
@@ -2196,7 +2204,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
*params = att-TextureLevel;
}
else if (att-Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
glGetFramebufferAttachmentParameterivEXT(pname));
}
else {
@@ -2214,7 +,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
}
}
else if (att-Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
glGetFramebufferAttachmentParameterivEXT(pname));
}
else {
@@ -2232,7 +2240,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
}
}
else if (att-Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
glGetFramebufferAttachmentParameterivEXT(pname));
}
else {
@@ -2246,7 +2254,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
glGetFramebufferAttachmentParameterivEXT(pname));
}
else if (att-Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
glGetFramebufferAttachmentParameterivEXT(pname));
}
else {
@@ -2267,7 +2275,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
return;
}
else if (att-Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
glGetFramebufferAttachmentParameterivEXT(pname));
}
else {
@@ -2301,7 +2309,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
glGetFramebufferAttachmentParameterivEXT(pname));
}
else if (att-Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, is_gl ? GL_INVALID_OPERATION : GL_INVALID_ENUM,
glGetFramebufferAttachmentParameterivEXT(pname));
}
else if (att-Texture) {
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4mINUACgkQX1gOwKyEAw/O5ACdEu8vAh6KY0fa+/GJpMH9UwaM
hIEAn3VAcVw5XvNpHlXZ9YJP+st+MMJp
=SvMB
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 release candidate 2
Hello list Mesa 7.11-rc2 has been released. This is a release candidate for the 7.11 development release. I've tried to compile this one 996aea3cca40bb34c0a9027411924879 MesaGLUT-7.11-rc2.tar.bz2 After unpacking ./configure --prefix=/opt/mesa PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig LC_ALL=C make -j8 Make fails here gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mapi -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/opt/mesa/include -I/opt/mesa/include/libdrm-DFEATURE_GL=1 -I/opt/mesa/include -I/opt/mesa/include/libdrm -I/usr/include/libdrm -I/usr/include/nouveau -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0206 -fvisibility=hidden nouveau_bo_state.c -o nouveau_bo_state.o In file included from nouveau_fbo.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory In file included from nouveau_state.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory In file included from nouveau_state.c:30: nouveau_util.h: In function 'OUT_RINGb': nouveau_util.h:169: warning: implicit declaration of function 'OUT_RING' nouveau_util.h: In function 'OUT_RINGm': nouveau_util.h:179: warning: implicit declaration of function 'OUT_RINGf' In file included from nouveau_screen.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory make[6]: *** [nouveau_fbo.o] Error 1 make[6]: *** Waiting for unfinished jobs In file included from nouveau_context.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory make[6]: *** [nouveau_state.o] Error 1 make[6]: *** [nouveau_screen.o] Error 1 In file included from nouveau_driver.c:29: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory In file included from nouveau_span.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory In file included from nouveau_bufferobj.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory In file included from nouveau_driver.c:32: nouveau_util.h: In function 'OUT_RINGb': nouveau_util.h:169: warning: implicit declaration of function 'OUT_RING' nouveau_util.h: In function 'OUT_RINGm': nouveau_util.h:179: warning: implicit declaration of function 'OUT_RINGf' nouveau_driver.c: In function 'nouveau_flush': nouveau_driver.c:62: warning: implicit declaration of function 'FIRE_RING' make[6]: *** [nouveau_bufferobj.o] Error 1 In file included from nouveau_bo_state.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory nouveau_bo_state.c: In function 'nouveau_bo_marker_emit': nouveau_bo_state.c:40: warning: implicit declaration of function 'MARK_RING' nouveau_bo_state.c:46: warning: implicit declaration of function 'nouveau_pushbuf_emit_reloc' nouveau_bo_state.c:46: error: 'struct nouveau_channel' has no member named 'cur' nouveau_bo_state.c:54: error: 'struct nouveau_channel' has no member named 'cur' nouveau_bo_state.c:57: error: 'struct nouveau_channel' has no member named 'cur' nouveau_bo_state.c:65: warning: implicit declaration of function 'MARK_UNDO' make[6]: *** [nouveau_driver.o] Error 1 make[6]: *** [nouveau_bo_state.o] Error 1 make[6]: *** [nouveau_span.o] Error 1 nouveau_context.c: In function 'nouveau_context_init': nouveau_context.c:133: warning: passing argument 4 of 'nouveau_channel_alloc' makes pointer from integer without a cast /usr/include/nouveau/nouveau_channel.h:50: note: expected 'struct nouveau_channel **' but argument is of type 'int' nouveau_context.c:133: error: too many arguments to function 'nouveau_channel_alloc' nouveau_context.c: In function 'update_framebuffer': nouveau_context.c:282: warning: implicit declaration of function 'FIRE_RING' make[6]: *** [nouveau_context.o] Error 1 make[6]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers/dri/nouveau' make[5]: *** [lib] Error 2 make[5]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers/dri/nouveau' make[4]: *** [subdirs] Error 1 make[4]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers/dri' make[3]: *** [default] Error 1 make[3]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers' make[2]: *** [driver_subdirs] Error 2 make[2]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src' make: *** [default] Error 1 Cheers, Sebastian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i965: Enable the PIPE_CONTROL workaround workaround out of paranoia.
On 07/19/2011 03:44 PM, Eric Anholt wrote:
There's scary stuff going on in PIPE_CONTROL internals, and if the
BSpec says to do this to make PIPE_CONTROL work, I'll go ahead and do
it because we'll probably never be able to debug it after the fact.
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c | 32 +--
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index 9c97ef2..6a5f934 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -308,12 +308,30 @@ emit:
* [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache Flush Enable
* =1, a PIPE_CONTROL with any non-zero post-sync-op is required.
*
- * XXX: There is also a workaround that would appear to apply to this
- * workaround, but it doesn't appear to be necessary so far:
+ * And the workaround for these two requires this workaround first:
*
- * Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent
+ * [Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent
* BEFORE the pipe-control with a post-sync op and no write-cache
* flushes.
+ *
+ * And this last workaround is tricky because of the requirements on
+ * that bit. From section 1.4.7.2.3 Stall of the Sandy Bridge PRM
+ * volume 2 part 1:
You mean 1.7.4.2.3. For that matter, I think the earlier reference
(implementing two workarounds on gen6. From section 1.4.7.1) should be
1.7.4.1 as well.
+ *
+ * 1 of the following must also be set:
+ * - Render Target Cache Flush Enable ([12] of DW1)
+ * - Depth Cache Flush Enable ([0] of DW1)
+ * - Stall at Pixel Scoreboard ([1] of DW1)
+ * - Depth Stall ([13] of DW1)
+ * - Post-Sync Operation ([13] of DW1)
+ * - Notify Enable ([8] of DW1)
+ *
+ * The cache flushes require the workaround flush that triggered this
+ * one, so we can't use it. Post-sync nonzero is what triggered this
+ * workaround, so we can't use that one either. Notify enable is
+ * IRQs, which aren't really our business. That leaves depth stall or
+ * stall at scoreboard. It shouldn't matter which we choose because
+ * we're supposed to be stalling the entire pipeline anyway.
It seems like depth stall should be eliminated, too. Workaround 1:
Before any depth stall flush [...] send a PIPE_CONTROL with no bits set
except Post-Sync Operation != 0. So we'd have to do that. But then we
hit Workaround 3 again---this very text says we need a CS stall...with
depth or scoreboard stall. If a depth stall...refer to rule 1.
Repeat...infinitely.
Perhaps I'm misreading...or it doesn't apply since we don't care about
the effects of the depth stall (we're just required to set the bit).
Anyway, it seems like Stall at Pixel Scoreboard might be the safer bet, no?
*/
void
intel_emit_post_sync_nonzero_flush(struct intel_context *intel)
@@ -323,6 +341,14 @@ intel_emit_post_sync_nonzero_flush(struct intel_context
*intel)
BEGIN_BATCH(4);
OUT_BATCH(_3DSTATE_PIPE_CONTROL);
+ OUT_BATCH(PIPE_CONTROL_CS_STALL |
+ PIPE_CONTROL_DEPTH_STALL);
+ OUT_BATCH(0); /* address */
+ OUT_BATCH(0); /* write data */
+ ADVANCE_BATCH();
+
+ BEGIN_BATCH(4);
+ OUT_BATCH(_3DSTATE_PIPE_CONTROL);
OUT_BATCH(PIPE_CONTROL_WRITE_IMMEDIATE);
OUT_RELOC(intel-batch.workaround_bo,
I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION, 0);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] i965: Avoid kernel BUG_ON if we happen to wait on the pipe_control w/a BO.
On 07/19/2011 03:44 PM, Eric Anholt wrote: For this and occlusion queries, we're trying to avoid setting I915_GEM_DOMAIN_RENDER for the write domain, because the data written is definitely not going through the render cache, but we do need to tell the kernel that the object has been written. However, with using I915_GEM_DOMAIN_GTT, the kernel on retiring the batchbuffer sees that the w/a BO has a write domain of GTT, and puts it on the flushing list. If something tries to wait for that BO to finish rendering (such as the AUB dumper reading the contents of BOs), we get into wait_request (since obj-active) but with a 0 seqno (since the object is on the flushing list, not actually on a ringbuffer), and BUG_ONs. To avoid the kernel bug (which I'm hoping to delete soon anyway), just use I915_GEM_DOMAIN_INSTRUCTION like occlusion queries do. This doesn't result in more flushing, because we invalidate INSTRUCTION on every batchbuffer now that we're state streaming, anyway. --- src/mesa/drivers/dri/intel/intel_batchbuffer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c b/src/mesa/drivers/dri/intel/intel_batchbuffer.c index b61a2ff..9c97ef2 100644 --- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c +++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c @@ -325,7 +325,7 @@ intel_emit_post_sync_nonzero_flush(struct intel_context *intel) OUT_BATCH(_3DSTATE_PIPE_CONTROL); OUT_BATCH(PIPE_CONTROL_WRITE_IMMEDIATE); OUT_RELOC(intel-batch.workaround_bo, - I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT, 0); + I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION, 0); OUT_BATCH(0); /* write data */ ADVANCE_BATCH(); For this patch only: Reviewed-and-tested-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] progs/egl: Add an OpenGL ES 2.0 demo for EGL_OES_image_pixmap.
This is based on opengles1/texture_from_pixmap.c
---
src/egl/opengles2/Makefile.am |4 +-
src/egl/opengles2/texture_from_pixmap.c | 653 +++
2 files changed, 656 insertions(+), 1 deletions(-)
create mode 100644 src/egl/opengles2/texture_from_pixmap.c
diff --git a/src/egl/opengles2/Makefile.am b/src/egl/opengles2/Makefile.am
index 8d85c06..1e791fb 100644
--- a/src/egl/opengles2/Makefile.am
+++ b/src/egl/opengles2/Makefile.am
@@ -38,7 +38,8 @@ if HAVE_GLESV2
bin_PROGRAMS = \
es2_info \
es2gears \
- es2tri
+ es2tri \
+ texture_from_pixmap
endif
endif
@@ -46,3 +47,4 @@ es2_info_LDADD = $(X11_LIBS)
es2tri_LDADD = $(X11_LIBS)
es2gears_LDADD = ../eglut/libeglut_x11.la
+texture_from_pixmap_LDADD = $(X11_LIBS)
diff --git a/src/egl/opengles2/texture_from_pixmap.c
b/src/egl/opengles2/texture_from_pixmap.c
new file mode 100644
index 000..5e47468
--- /dev/null
+++ b/src/egl/opengles2/texture_from_pixmap.c
@@ -0,0 +1,653 @@
+/*
+ * Mesa 3-D graphics library
+ * Version: 7.9
+ *
+ * Copyright (C) 2010 LunarG Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Chia-I Wu o...@lunarg.com
+ *Shuang He shuang...@intel.com
+ */
+
+/*
+ * This demo uses EGL_KHR_image_pixmap and GL_OES_EGL_image to demonstrate
+ * texture-from-pixmap.
+ */
+
+#include assert.h
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include unistd.h /* for usleep */
+#include sys/time.h /* for gettimeofday */
+#include X11/Xlib.h
+#include X11/Xutil.h
+#include X11/keysym.h
+#include GLES2/gl2.h
+#include GLES2/gl2ext.h
+#include EGL/egl.h
+#include EGL/eglext.h
+
+struct app_data {
+ /* native */
+ Display *xdpy;
+ Window canvas, cube;
+ Pixmap pix;
+ unsigned int width, height, depth;
+ GC fg, bg;
+
+ /* EGL */
+ EGLDisplay dpy;
+ EGLContext ctx;
+ EGLSurface surf;
+ EGLImageKHR img;
+
+ /* OpenGL ES */
+ GLuint texture;
+
+ PFNEGLCREATEIMAGEKHRPROC eglCreateImageKHR;
+ PFNEGLDESTROYIMAGEKHRPROC eglDestroyImageKHR;
+ PFNGLEGLIMAGETARGETTEXTURE2DOESPROC glEGLImageTargetTexture2DOES;
+
+ /* app state */
+ Bool loop;
+ Bool redraw, reshape;
+
+ struct {
+ Bool active;
+ unsigned long next_frame; /* in ms */
+ } animate;
+
+ struct {
+ Bool active;
+ int x1, y1;
+ int x2, y2;
+ } paint;
+ int prog;
+ int vs;
+ int fs;
+};
+
+enum pigilt_attrib_location {
+ PIGLIT_ATTRIB_POS,
+ PIGLIT_ATTRIB_TEX
+};
+
+static const char vertex_shader[] =
+attribute vec3 pos;\n
+attribute vec3 tex;\n
+\n
+\n
+varying mediump vec2 texCoord;\n
+\n
+void main(void)\n
+{\n
+gl_Position = vec4(pos, 1.0);\n
+texCoord = tex.xy;\n
+};
+
+static const char fragment_shader[] =
+uniform sampler2D texid;\n
+varying mediump vec2 texCoord;\n
+\n
+void main(void)\n
+{\n
+gl_FragColor = texture2D(texid, texCoord);\n
+};
+
+
+static void
+gl_redraw(void)
+{
+ float verts[4][4];
+ float tex[4][2];
+ float x = -0.5;
+ float y = -0.5;
+ float w = 1.0;
+ float h = 1.0;
+ float tx = 0.0;
+ float ty = 1.0;
+ float tw = 1.0;
+ float th = -1.0;
+
+ verts[0][0] = x;
+ verts[0][1] = y;
+ verts[0][2] = 0.0;
+ verts[0][3] = 1.0;
+ tex[0][0] = tx;
+ tex[0][1] = ty;
+ verts[1][0] = x + w;
+ verts[1][1] = y;
+ verts[1][2] = 0.0;
+ verts[1][3] = 1.0;
+ tex[1][0] = tx + tw;
+ tex[1][1] = ty;
+ verts[2][0] = x;
+ verts[2][1] = y + h;
+ verts[2][2] = 0.0;
+ verts[2][3] = 1.0;
+ tex[2][0] = tx;
+ tex[2][1] = ty + th;
+ verts[3][0] = x + w;
+ verts[3][1] = y + h;
+ verts[3][2] = 0.0;
+ verts[3][3] = 1.0;
+ tex[3][0] = tx + tw;
+ tex[3][1] = ty + th;
+
+ glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
+ glVertexAttribPointer(PIGLIT_ATTRIB_POS, 4, GL_FLOAT, GL_FALSE, 0, verts);
+ glVertexAttribPointer(PIGLIT_ATTRIB_TEX, 2, GL_FLOAT, GL_FALSE, 0, tex);
+
