[Mesa3d-dev] [Bug 27012] mesa git shows a compilation error
http://bugs.freedesktop.org/show_bug.cgi?id=27012 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #3 from Michel Dänzer mic...@daenzer.net 2010-03-12 00:32:50 PST --- Different issue, file another bug for it if necessary. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 27037] New: mesa git shows a compilation error
http://bugs.freedesktop.org/show_bug.cgi?id=27037 Summary: mesa git shows a compilation error 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 make shows the following error: --- make[5]: Entering directory `/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm/radeon/egl' gcc -c -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -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 -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o make[5]: *** No rule to make target `../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by `egl_x11_radeon.so'. Stop. make[5]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm/radeon/egl' make[4]: *** [default] Error 1 make[4]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm/radeon' make[3]: *** [default] Error 1 make[3]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm' make[2]: *** [default] Error 1 make[2]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys' 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. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 27007] Lines disappear with GL_LINE_SMOOTH
http://bugs.freedesktop.org/show_bug.cgi?id=27007 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added AssignedTo|mesa3d- |e...@anholt.net |d...@lists.sourceforge.net | Component|Drivers/X11 |Drivers/DRI/i965 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 27037] mesa git shows a compilation error
http://bugs.freedesktop.org/show_bug.cgi?id=27037 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Michel Dänzer mic...@daenzer.net 2010-03-12 01:15:12 PST --- *** This bug has been marked as a duplicate of bug 27010 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] xdemos build breakage...
On Fri, Mar 12, 2010 at 9:37 AM, David Miller da...@davemloft.net wrote: This change: commit d888bbc45a84946cafb4f4d2c89681a580cd89bc Author: Brian Paul bri...@vmware.com Date: Tue Nov 17 13:39:13 2009 -0700 progs/xdemos: added -lX11 -lpthread for GNU gold linker breaks the build if you are building under a specific path prefix (say, /opt/XORG) and you have an existing X11 installation in the usual location (/usr, etc.) Mesa gets configure with: PATH=/opt/XORG/bin:$PATH ./configure --prefix=/opt/XORG --libdir=/opt/XORG/lib And then we get, for example: make[2]: Entering directory `/home/davem/src/GIT/XORG/mesa/mesa/progs/xdemos' gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_SPARC_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS corender.o ipc.o -L../../lib -lGL -lm -lX11 -lpthread -o corender /usr/bin/../lib/libxcb-xlib.so.0: undefined reference to `_xcb_lock_io' /usr/bin/../lib/libxcb-xlib.so.0: undefined reference to `_xcb_unlock_io' collect2: ld returned 1 exit status Reverting the commit, of course, makes the problem go away. One way to fix this would be to propagate the --libdir prefix down to these Makefiles. The same exact problem exists in progs/egl, but since libEGL doesn't link to libX11 any more, a simple revert of: commit 8d0bdfa4335ea07a747f53635a57414d15c234b7 Author: Chia-I Wu olva...@gmail.com Date: Wed Aug 26 12:44:02 2009 +0800 progs: EGL/X progs should link to libX11. Since 5a459d58fca2b71cb77c39f98df8a81ce6298421, libEGL no longer links to libX11. Add the dependency to affected progs and cleanup prog/egl/Makefile. Signed-off-by: Chia-I Wu olva...@gmail.com doesn't fix the problem. Sigh... :-) I think this is a configuration problem. Does it help if you configure mesa with $ ./configure --prefix=/opt/XORG --libdir=/opt/XORG/lib LDFLAGS=-L/opt/XORG/lib ? I haven't tried, but conventionally, LDFLAGS (and CFLAGS) are available for user's use. -- o...@lunarg.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] New error in xorg_crtc.c
Hi guys, I've pulled in the latest commits for my local copy of Mesa git master.I ran gmake -B realclean,and used my usaul confiugre options: ./configure --prefix=/usr --enable-32-bit --enable-xcb --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096 --with-max-height=4096 --enable-debug Mesa stops compiling with this new error: /usr/include/xorg/edid.h:623: warning: declaration does not declare anything gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -DHAVE_CONFIG_H -DHAVE_XEXTPROTO_71 -DHAVE_LIBKMS -I/usr/include/libkms -I/usr/include/pixman-1 -I/usr/include/xorg -I/usr/include/drm -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../include -I../../../../src/mesa -I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 xorg_crtc.c -o xorg_crtc.o In file included from /usr/include/xorg/xf86Crtc.h:25, from xorg_crtc.c:41: /usr/include/xorg/edid.h:623: warning: declaration does not declare anything xorg_crtc.c: In function ‘crtc_load_cursor_argb_ga3d’: xorg_crtc.c:223: error: ‘struct pipe_screen’ has no member named ‘get_tex_transfer’ xorg_crtc.c:227: error: ‘struct pipe_screen’ has no member named ‘transfer_map’ xorg_crtc.c:231: error: ‘struct pipe_screen’ has no member named ‘transfer_unmap’ xorg_crtc.c:232: error: ‘struct pipe_screen’ has no member named ‘tex_transfer_destroy’ gmake[4]: *** [xorg_crtc.o] Error 1 gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/xorg' gmake[3]: *** [subdirs] Error 1 gmake[3]: Leaving directory `/opt/mesa/src/gallium/state_trackers' gmake[2]: *** [default] Error 1 gmake[2]: Leaving directory `/opt/mesa/src/gallium' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/opt/mesa/src' gmake: *** [default] Error 1 I think it's to do with the gallium-context-tranfers merge,or some very recent commit,I'm not that sure.The error is similar to the one that has been posted earlier in the mailing list. Regards, STEVE555 -- View this message in context: http://old.nabble.com/New-error-in-xorg_crtc.c-tp27874502p27874502.html Sent from the mesa3d-dev mailing list archive at Nabble.com. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] New error in xorg_crtc.c
Steve, Fixed, sorry for the screwup - it looks like a couple of directories escaped conversion. Keith On Fri, 2010-03-12 at 03:59 -0800, STEVE555 wrote: Hi guys, I've pulled in the latest commits for my local copy of Mesa git master.I ran gmake -B realclean,and used my usaul confiugre options: ./configure --prefix=/usr --enable-32-bit --enable-xcb --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096 --with-max-height=4096 --enable-debug Mesa stops compiling with this new error: /usr/include/xorg/edid.h:623: warning: declaration does not declare anything gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -DHAVE_CONFIG_H -DHAVE_XEXTPROTO_71 -DHAVE_LIBKMS -I/usr/include/libkms -I/usr/include/pixman-1 -I/usr/include/xorg -I/usr/include/drm -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../include -I../../../../src/mesa -I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 xorg_crtc.c -o xorg_crtc.o In file included from /usr/include/xorg/xf86Crtc.h:25, from xorg_crtc.c:41: /usr/include/xorg/edid.h:623: warning: declaration does not declare anything xorg_crtc.c: In function ‘crtc_load_cursor_argb_ga3d’: xorg_crtc.c:223: error: ‘struct pipe_screen’ has no member named ‘get_tex_transfer’ xorg_crtc.c:227: error: ‘struct pipe_screen’ has no member named ‘transfer_map’ xorg_crtc.c:231: error: ‘struct pipe_screen’ has no member named ‘transfer_unmap’ xorg_crtc.c:232: error: ‘struct pipe_screen’ has no member named ‘tex_transfer_destroy’ gmake[4]: *** [xorg_crtc.o] Error 1 gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/xorg' gmake[3]: *** [subdirs] Error 1 gmake[3]: Leaving directory `/opt/mesa/src/gallium/state_trackers' gmake[2]: *** [default] Error 1 gmake[2]: Leaving directory `/opt/mesa/src/gallium' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/opt/mesa/src' gmake: *** [default] Error 1 I think it's to do with the gallium-context-tranfers merge,or some very recent commit,I'm not that sure.The error is similar to the one that has been posted earlier in the mailing list. Regards, STEVE555 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.
On Fri, 2010-03-12 at 02:54 -0800, Corbin Simpson wrote:
Module: Mesa
Branch: master
Commit: 50876ddaaff72a324ac45e255985e0f84e108594
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=50876ddaaff72a324ac45e255985e0f84e108594
Author: Corbin Simpson mostawesomed...@gmail.com
Date: Fri Mar 12 02:51:40 2010 -0800
st/mesa: Always recalculate invalid index bounds.
These should always be sanitized before heading towards the pipe driver,
and if the calling function explicitly marked them as invalid, we need
to regenerate them.
Allows r300g to properly pass a bit more of Wine's d3d9 testing without
dropping stuff on the floor.
---
src/mesa/state_tracker/st_draw.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c
b/src/mesa/state_tracker/st_draw.c
index 8b01272..d81b361 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -542,9 +542,9 @@ st_draw_vbo(GLcontext *ctx,
assert(ctx-NewState == 0x0);
/* Gallium probably doesn't want this in some cases. */
- if (!index_bounds_valid)
- if (!vbo_all_varyings_in_vbos(arrays))
- vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ if (index_bounds_valid != GL_TRUE) {
+ vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ }
Corbin,
This isn't really desirable. Ideally this range checking should be
pushed into pipe driver, because it's an expensive operation that is not
necessary on a lot of hardware. #
Specifically, vertex fetch hardware can often be set up with the min/max
permissible index bounds to avoid accessing vertex data outside of the
bound VB's. This can be achieved by examining the VBs, with min_index
== 0, max_index = vb.size / vb.stride.
The case where we need to calculate them internally is if some data is
not in a VB, meaning we can't guess what the legal min/max values are.
Also note that we need that min/max information to be able to upload the
data to a VB.
So, I think the code was probably correct in the original version -
defer the minmax scan to the hardware driver, which may or may not need
it.
But maybe there is a better way to let the driver know that we are not
providing this information.
Keith
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.
Michal,
Is the intention to have 1 sampler view active in the Mesa state
tracker, specifically in the cases where min_lod varies?
In other words, you seem to have two ways of specifying the same state:
pipe_sampler_view::first_level
and
pipe_sampler::min_lod
Is there a case to keep both of these? Or is one enough?
Keith
On Fri, 2010-03-12 at 05:39 -0800, Micha?? Kr??l wrote:
Module: Mesa
Branch: gallium-sampler-view
Commit: b8030c6561e019e079b5be2fe64ec804df4bfa03
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=b8030c6561e019e079b5be2fe64ec804df4bfa03
Author: Michal Krol mic...@vmware.com
Date: Fri Mar 12 14:37:36 2010 +0100
st/mesa: Associate a sampler view with an st texture object.
Lazily create a sampler view when the texture is being bound
for the first time.
---
src/mesa/state_tracker/st_atom_pixeltransfer.c |2 +
src/mesa/state_tracker/st_atom_texture.c | 20 +-
src/mesa/state_tracker/st_cb_bitmap.c | 48 +++
src/mesa/state_tracker/st_cb_drawpixels.c | 46 ++
src/mesa/state_tracker/st_cb_texture.c |4 ++
src/mesa/state_tracker/st_context.c|4 +-
src/mesa/state_tracker/st_context.h|3 +-
src/mesa/state_tracker/st_texture.h| 39 +++
8 files changed, 119 insertions(+), 47 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c
b/src/mesa/state_tracker/st_atom_pixeltransfer.c
index 0b2e3f5..e766b3a 100644
--- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
+++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
@@ -257,6 +257,8 @@ get_pixel_transfer_program(GLcontext *ctx, const struct
state_key *key)
/* create the colormap/texture now if not already done */
if (!st-pixel_xfer.pixelmap_texture) {
st-pixel_xfer.pixelmap_texture = create_color_map_texture(ctx);
+ st-pixel_xfer.pixelmap_sampler_view =
st_sampler_view_from_texture(ctx-st-pipe,
+
st-pixel_xfer.pixelmap_texture);
}
/* with a little effort, we can do four pixel map look-ups with
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 57b71c1..241c001 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -56,7 +56,7 @@ update_textures(struct st_context *st)
/* loop over sampler units (aka tex image units) */
for (su = 0; su st-ctx-Const.MaxTextureImageUnits; su++) {
- struct pipe_texture *pt = NULL;
+ struct pipe_sampler_view *sampler_view = NULL;
if (samplersUsed (1 su)) {
struct gl_texture_object *texObj;
@@ -84,7 +84,7 @@ update_textures(struct st_context *st)
st-state.num_textures = su + 1;
- pt = st_get_stobj_texture(stObj);
+ sampler_view = st_get_stobj_sampler_view(stObj);
}
/*
@@ -96,17 +96,17 @@ update_textures(struct st_context *st)
}
*/
- pipe_texture_reference(st-state.sampler_texture[su], pt);
+ pipe_sampler_view_reference(st-state.sampler_views[su],
sampler_view);
}
- cso_set_sampler_textures(st-cso_context,
-st-state.num_textures,
-st-state.sampler_texture);
+ cso_set_fragment_sampler_views(st-cso_context,
+ st-state.num_textures,
+ st-state.sampler_views);
if (st-ctx-Const.MaxVertexTextureImageUnits 0) {
- cso_set_vertex_sampler_textures(st-cso_context,
- MIN2(st-state.num_textures,
-
st-ctx-Const.MaxVertexTextureImageUnits),
- st-state.sampler_texture);
+ cso_set_vertex_sampler_views(st-cso_context,
+ MIN2(st-state.num_textures,
+
st-ctx-Const.MaxVertexTextureImageUnits),
+ st-state.sampler_views);
}
}
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c
b/src/mesa/state_tracker/st_cb_bitmap.c
index f326601..25d33b9 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -398,7 +398,7 @@ setup_bitmap_vertex_data(struct st_context *st,
static void
draw_bitmap_quad(GLcontext *ctx, GLint x, GLint y, GLfloat z,
GLsizei width, GLsizei height,
- struct pipe_texture *pt,
+ struct pipe_sampler_view *sv,
const GLfloat *color)
{
struct st_context *st = ctx-st;
@@ -436,7 +436,7 @@ draw_bitmap_quad(GLcontext *ctx, GLint x, GLint y,
GLfloat z,
cso_save_rasterizer(cso);
cso_save_samplers(cso);
-
Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.
Resending to the right address.
Keith
On Fri, 2010-03-12 at 13:40 +, Keith Whitwell wrote:
On Fri, 2010-03-12 at 02:54 -0800, Corbin Simpson wrote:
Module: Mesa
Branch: master
Commit: 50876ddaaff72a324ac45e255985e0f84e108594
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=50876ddaaff72a324ac45e255985e0f84e108594
Author: Corbin Simpson mostawesomed...@gmail.com
Date: Fri Mar 12 02:51:40 2010 -0800
st/mesa: Always recalculate invalid index bounds.
These should always be sanitized before heading towards the pipe driver,
and if the calling function explicitly marked them as invalid, we need
to regenerate them.
Allows r300g to properly pass a bit more of Wine's d3d9 testing without
dropping stuff on the floor.
---
src/mesa/state_tracker/st_draw.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c
b/src/mesa/state_tracker/st_draw.c
index 8b01272..d81b361 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -542,9 +542,9 @@ st_draw_vbo(GLcontext *ctx,
assert(ctx-NewState == 0x0);
/* Gallium probably doesn't want this in some cases. */
- if (!index_bounds_valid)
- if (!vbo_all_varyings_in_vbos(arrays))
-vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ if (index_bounds_valid != GL_TRUE) {
+ vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ }
Corbin,
This isn't really desirable. Ideally this range checking should be
pushed into pipe driver, because it's an expensive operation that is not
necessary on a lot of hardware. #
Specifically, vertex fetch hardware can often be set up with the min/max
permissible index bounds to avoid accessing vertex data outside of the
bound VB's. This can be achieved by examining the VBs, with min_index
== 0, max_index = vb.size / vb.stride.
The case where we need to calculate them internally is if some data is
not in a VB, meaning we can't guess what the legal min/max values are.
Also note that we need that min/max information to be able to upload the
data to a VB.
So, I think the code was probably correct in the original version -
defer the minmax scan to the hardware driver, which may or may not need
it.
But maybe there is a better way to let the driver know that we are not
providing this information.
Keith
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] gallium-sampler-view branch merge
michal wrote on 2010-03-11 17:59: Keith Whitwell wrote on 2010-03-11 16:16: On Thu, 2010-03-11 at 06:05 -0800, michal wrote: Keith Whitwell wrote on 2010-03-11 14:21: On Thu, 2010-03-11 at 03:16 -0800, michal wrote: Hi, I would like to merge the branch in subject this week. This feature branch allows state trackers to bind sampler views instead of textures to shader stages. A sampler view object holds a reference to a texture and also overrides internal texture format (resource casting) and specifies RGBA swizzle (needed for GL_EXT_texture_swizzle extension). Michal, I've got some issues with the way the sampler views are being generated and used inside the CSO module. The point of a sampler view is that it gives the driver an opportunity to do expensive operations required for special sampling modes (which may include copying surface data if hardware is deficient in some way). This approach works if a sampler view is created once, then used multiple times before being deleted. Unfortunately, it seems the changes to support this in the CSO module provide only a single-shot usage model. Sampler views are created in cso_set_XXX_sampler_textures, bound to the context, and then dereferenced/destroyed on the next bind. The reason CSO code looks like this is because it was meant to be an itermediate step towards migration to sampler view model. Fully converting all existing state trackers is non-trivial and thus I chose this conservative approach. State trackers that do not care about extra features a sampler view provides will keep using this one-shot CSO interface with the hope that creation of sampler objects is lighweight (format matches texture format, swizzle matches native texel layout, etc.). On the surface, this hope isn't likely to be fulfilled - lots of hardware doesn't support non-zero first_level. Most cases of drivers implementing sampler views internally are to catch this issue. Of course, it seems like your branch so leaves the existing driver-specific sampler view code in place, so that there are potentially two implementations of sampler views in those drivers. I guess this means that you can get away with the current implementation for now, but it prevents drivers actually taking advantage of the fact that these entities exist in the interface -- they will continue to have to duplicate the concept internally until the state trackers and/or CSO module start caching views. Ideally, everybody moves on and we stop using CSO for sampler views. I prefer putting my effort into incremental migration of state trackers rather than caching something that by definition doesn't need to be cached. The CSO module exists to manage this type of caching on behalf of state trackers. I would have thought that this was a sensible extension of the existing purpose of the CSO module. Won't all state-trackers implementing APIs which don't expose sampler views to the application require essentially the same caching logic, as is the case with regular state? Wouldn't it be least effort to do that caching once only in the CSO module? OK, I see your point. I will make the necessary changes and ping you when that's done. Keith, I changed my mind, went ahead and implemented sampler view caching in mesa state tracker, rather than inside cso context. I strongly believe that doing caching on cso side would be slower and more complicated. A state tracker has a better understanding of the relationship between a texture and sampler view. In case of mesa, this is trivial 1-to-1 mapping. Later, when we'll need more sampler views per texture, we can have a per-texture cache for that, and yes, the code for that would be in cso. There are two other state trackers that need to be fixed: xorg and vega. The transition should be similar to mesa -- I can help with doing that, but I can't do it myself. Once that's done we can purge one-shot sampler view wrappers. What do you think? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] some r6xx work for r600g
Hello, attached is a patch against rev. 189abd58e83af98276b9e170413918c821592f0c of Jerome Glisse's mesa repo. With this my RV610 runs rudimentarily (few card hangs instead of hangs each time of loading r600g, some rendering). The changes against r7xx cards are copied from the differences in r600demo. The patch does not preserve compatibility with r7xx cards (@ Jerome Glisse: Is there a way to select codepaths depending on the used chip, e.g. like if(rdev-chip = RV670)... ) Also the renderung results are somewhat different from Jerome Glisse's results. tri-flat gives the following result: -red background -there is a completely green quad rendered. Its sides are parallel to the window borders. Left bound is the left vertex of the desired triangle, right and lower bounds are the lower right vertex of the triangle and upper bound is the middle of the window. Regards Stephan Schmid patch_r600g_r6xx_rudimentary.diff Description: application/pgp-keys -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.
Keith Whitwell wrote on 2010-03-12 14:46: Michal, Is the intention to have 1 sampler view active in the Mesa state tracker, specifically in the cases where min_lod varies? In other words, you seem to have two ways of specifying the same state: pipe_sampler_view::first_level and pipe_sampler::min_lod Is there a case to keep both of these? Or is one enough? It looks like one has to go away, and that would be pipe_sampler::min_lod. And we want to have a per-texture cache of sampler views in mesa. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.
On Fri, 2010-03-12 at 06:08 -0800, michal wrote: Keith Whitwell wrote on 2010-03-12 14:46: Michal, Is the intention to have 1 sampler view active in the Mesa state tracker, specifically in the cases where min_lod varies? In other words, you seem to have two ways of specifying the same state: pipe_sampler_view::first_level and pipe_sampler::min_lod Is there a case to keep both of these? Or is one enough? It looks like one has to go away, and that would be pipe_sampler::min_lod. And we want to have a per-texture cache of sampler views in mesa. Yeah. There is hardware out there that is modeled after DX9 that doesn't support min_lod, which would be greatly simplified with this. Jose -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.
On Fri, 2010-03-12 at 06:08 -0800, michal wrote: Keith Whitwell wrote on 2010-03-12 14:46: Michal, Is the intention to have 1 sampler view active in the Mesa state tracker, specifically in the cases where min_lod varies? In other words, you seem to have two ways of specifying the same state: pipe_sampler_view::first_level and pipe_sampler::min_lod Is there a case to keep both of these? Or is one enough? It looks like one has to go away, and that would be pipe_sampler::min_lod. And we want to have a per-texture cache of sampler views in mesa. OK, I'm fine with this if you're ok to go ahead and implement the caching. It's worth noting that drivers can discard any vram backing sampler views at any time (when they're not in use), so if we have a situation where large numbers of views are gobbling up vram, the driver has the option of running though all the views and discarding their cached contents. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.
On Fri, 2010-03-12 at 06:19 -0800, Christoph Bumiller wrote: On 12.03.2010 15:08, michal wrote: Keith Whitwell wrote on 2010-03-12 14:46: Michal, Is the intention to have 1 sampler view active in the Mesa state tracker, specifically in the cases where min_lod varies? In other words, you seem to have two ways of specifying the same state: pipe_sampler_view::first_level and pipe_sampler::min_lod Is there a case to keep both of these? Or is one enough? It looks like one has to go away, and that would be pipe_sampler::min_lod. And we want to have a per-texture cache of sampler views in mesa. But there *is* a difference between GL_TEXTURE_MIN_LOD and GL_TEXTURE_BASE_LEVEL which those two seem to reflect. How do you implement that if you just remove one ? Note that we currently only have the one (sampler::min_lod), and the other is a synonym for the same value that has been introduced by this branch. Those GL values are currently both consolidated down by the mesa state-tracker (along with other stuff) into sampler::min_lod. Although Michal has chosen a different name for the new member, it has the same meaning and the GL semantics can be implemented on top of it as they currently are for sampler::min_lod. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.
What if you have a non-integer min LOD? While the integer part may belong to the sampler view, the fractional part really seems to be a sampler property. Requiring min_lod 1.0 also doesn't seem to make much sense, so shouldn't it be kept as it is now? Same thing for last_level / max_lod. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] xdemos build breakage...
This change: commit d888bbc45a84946cafb4f4d2c89681a580cd89bc Author: Brian Paul bri...@vmware.com Date: Tue Nov 17 13:39:13 2009 -0700 progs/xdemos: added -lX11 -lpthread for GNU gold linker breaks the build if you are building under a specific path prefix (say, /opt/XORG) and you have an existing X11 installation in the usual location (/usr, etc.) I found the same problem and sent a patch to this list a few hours ago to address it: [PATCH] Add -L$(libdir) for xdemos and egl so that the right libX11 is found -- Jeff Smith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] util_format cleanup leftover: Gallium BGRA vertex swizzles
On Thu, 2010-03-11 at 17:50 -0800, Marek Olšák wrote: Please see this commit: http://cgit.freedesktop.org/~mareko/mesa/commit/?id=177a4432aa88fc68d83895ae71b7ad2c86a1e7e3 Subject: [PATCH] gallium: fix BGRA vertex color swizzles The mapping for vertex_array_bgra: (gl - st - translate) GL_RGBA - PIPE_FORMAT_R8G8B8A8 (RGBA) - no swizzle (XYZW) GL_BGRA - PIPE_FORMAT_A8R8G8B8 (ARGB) - ZYXW (BGRA again??) Iẗ́'s pretty clear that PIPE_FORMAT_A8R8G8B8 here is wrong. This commit fixes the pipe format and removes obvious workarounds in util/translate. Tested with: softpipe, llvmpipe, r300g. Please review. Marek, Well spotted. These were cases where formats were being used inconsistently in respect to their LSB-MSB vs MSB-LSB meanings and my automatic format rename did no more than flipping the inconsistency the otherway around. Looks good to me. I've went ahead and commited since I needed to fix up other state trackers. Jose -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Change some int64_t's to uint64_t's, to match CARD64's signedness
I'd like one of the other DRI developers to double-check this patch but the others look fine. I'll commit them soon. -Brian On Thu, Mar 11, 2010 at 9:13 PM, Jeff Smith whydo...@yahoo.com wrote: -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.
On Fri, 2010-03-12 at 06:54 -0800, Luca Barbieri wrote: What if you have a non-integer min LOD? While the integer part may belong to the sampler view, the fractional part really seems to be a sampler property. Requiring min_lod 1.0 also doesn't seem to make much sense, so shouldn't it be kept as it is now? Same thing for last_level / max_lod. Hmm, I see your point. Fractional values don't have a lot of meaning in the views, but without a fraction from somewhere we don't capture all of GL semantics. I guess this is the underlying reason GL has such a wide variety of ways of specifying the min/max level also. And finally, it seems like DX10 has done the same thing - with both integer min/max in views and float min/max in the sampler state. It looks like we really do want to keep them both. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] xdemos build breakage...
On Fri, Mar 12, 2010 at 6:48 AM, Jeff Smith whydo...@yahoo.com wrote: This change: commit d888bbc45a84946cafb4f4d2c89681a580cd89bc Author: Brian Paul bri...@vmware.com Date: Tue Nov 17 13:39:13 2009 -0700 progs/xdemos: added -lX11 -lpthread for GNU gold linker breaks the build if you are building under a specific path prefix (say, /opt/XORG) and you have an existing X11 installation in the usual location (/usr, etc.) I found the same problem and sent a patch to this list a few hours ago to address it: [PATCH] Add -L$(libdir) for xdemos and egl so that the right libX11 is found That's not really the right thing, though. You're assuming that I have libX11 in the same libdir as I'm installing to and I want to use it. The fact is that configure uses pkg-config to check for x11 and other libraries needed to link the demos. It certainly was working before without requiring hardcoding things into the Makefiles. -- Dan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] dri/r700: Include shader/programopt.h instead of programopt.c.
Committed. Thanks. -Brian On Fri, Mar 12, 2010 at 12:38 AM, Luc Verhaegen l...@skynet.be wrote: Luc Verhaegen. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.
On 12.03.2010 15:08, michal wrote: Keith Whitwell wrote on 2010-03-12 14:46: Michal, Is the intention to have 1 sampler view active in the Mesa state tracker, specifically in the cases where min_lod varies? In other words, you seem to have two ways of specifying the same state: pipe_sampler_view::first_level and pipe_sampler::min_lod Is there a case to keep both of these? Or is one enough? It looks like one has to go away, and that would be pipe_sampler::min_lod. And we want to have a per-texture cache of sampler views in mesa. But there *is* a difference between GL_TEXTURE_MIN_LOD and GL_TEXTURE_BASE_LEVEL which those two seem to reflect. How do you implement that if you just remove one ? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] some r6xx work for r600g
On Fri, Mar 12, 2010 at 03:05:43PM +0100, Stephan Schmid wrote: Hello, attached is a patch against rev. 189abd58e83af98276b9e170413918c821592f0c of Jerome Glisse's mesa repo. With this my RV610 runs rudimentarily (few card hangs instead of hangs each time of loading r600g, some rendering). The changes against r7xx cards are copied from the differences in r600demo. The patch does not preserve compatibility with r7xx cards (@ Jerome Glisse: Is there a way to select codepaths depending on the used chip, e.g. like if(rdev-chip = RV670)... ) Also the renderung results are somewhat different from Jerome Glisse's results. tri-flat gives the following result: -red background -there is a completely green quad rendered. Its sides are parallel to the window borders. Left bound is the left vertex of the desired triangle, right and lower bounds are the lower right vertex of the triangle and upper bound is the middle of the window. Regards Stephan Schmid Idea is that winsys will query pciid and set different defaultstate function btw r600/r700 then it will call different createscreen function btw r600/r700 (passing along pciid) and create screen will most likely have some kind of ptr to shader function which should pretty much the only difference from pipe pov (ignoring the restriction stated in the open documentation for which we need the pciid to alter the capacity of the state tracker). Cheers, Jerome -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] util_format cleanup leftover: Gallium BGRA vertex swizzles
On Fri, 2010-03-12 at 08:17 -0800, Brian Paul wrote: Jose wrote: On Thu, 2010-03-11 at 17:50 -0800, Marek Olšák wrote: Please see this commit: http://cgit.freedesktop.org/~mareko/mesa/commit/?id=177a4432aa88fc68d83895ae71b7ad2c86a1e7e3 Subject: [PATCH] gallium: fix BGRA vertex color swizzles The mapping for vertex_array_bgra: (gl - st - translate) GL_RGBA - PIPE_FORMAT_R8G8B8A8 (RGBA) - no swizzle (XYZW) GL_BGRA - PIPE_FORMAT_A8R8G8B8 (ARGB) - ZYXW (BGRA again??) Iẗ́'s pretty clear that PIPE_FORMAT_A8R8G8B8 here is wrong. This commit fixes the pipe format and removes obvious workarounds in util/translate. Tested with: softpipe, llvmpipe, r300g. Please review. Marek, Well spotted. These were cases where formats were being used inconsistently in respect to their LSB-MSB vs MSB-LSB meanings and my automatic format rename did no more than flipping the inconsistency the otherway around. Looks good to me. I've went ahead and commited since I needed to fix up other state trackers. Should this go into the 7.8 branch too, Jose? It's a cleanup -- it doesn't actually change behavior --, but I think it is better to port to 7.8 since cherrypicking future related fixes could end up having different effect on 7.8 branch. Jose -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Cast needed in program_lexer.l ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl Schultz wrote: Am getting these warnings in the Windows build: 2Compiling... 2lex.yy.c 2program_lexer.l(327) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data 2program_lexer.l(331) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data 2program_lexer.l(335) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data 2program_lexer.l(339) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data [snip] If it is not a huge hassle, can someone add these casts to 7.8 and master? The warnings are no big deal, but the casts do have some value in documenting the implicit conversion. Absolutely not. All the casts do is clutter the code. This is a completely worthless warning from Visual Studio. It generates only noise. I have never seen a case where it was actually useful. There are pragmas and command line options to disable specific warnings. You should do that. Brian, could you please revert those patches. I don't want that crap in code that I maintain. Seriously. Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuanyEACgkQX1gOwKyEAw/PJwCgjZDqwdLrkC5hZ28hCgLpdmvH anYAnAm2rMb2fSgnOjsqRSybuhQ1ZmOA =cRwl -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 23941] Wine offscreen rendering causes GL_INVALID_FRAMEBUFFER_OPERATION_EXT
http://bugs.freedesktop.org/show_bug.cgi?id=23941 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Sven Arvidsson s...@whiz.se 2010-03-12 12:29:11 PST --- This is working a lot better now, both games in Wine in general, and the specific title I used for testing this (the Halo demo). Both the rendering errors and the warning message is gone. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Cast needed in program_lexer.l ???
Absolutely not. All the casts do is clutter the code. This is a
completely worthless warning from Visual Studio. It generates only
noise. I have never seen a case where it was actually useful. There
are pragmas and command line options to disable specific warnings. You
should do that.
Brian, could you please revert those patches. I don't want that crap in
code that I maintain. Seriously.
What about this patch:
From 40136f460562d49a21877fdb52d9ddbf8ae6f7b9 Mon Sep 17 00:00:00 2001
From: Gon Solo gons...@gmail.com
Date: Fri, 12 Mar 2010 21:39:59 +0100
Subject: [PATCH] Use strof. C99 is 11 years now.
---
src/mesa/main/imports.c |7 +++
src/mesa/main/imports.h |3 +++
src/mesa/shader/lex.yy.c|8
src/mesa/shader/program_lexer.l |8
4 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 56e8195..d77b36c 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -810,6 +810,13 @@ _mesa_strtod( const char *s, char **end )
#endif
}
+/** Wrapper around strtof() */
+float
+_mesa_strtof( const char *s, char **end )
+{
+ return strtof(s, end);
+}
+
/** Compute simple checksum/hash for a string */
unsigned int
_mesa_str_checksum(const char *str)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index fb4a00e..c30be11 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -578,6 +578,9 @@ _mesa_strdup( const char *s );
extern double
_mesa_strtod( const char *s, char **end );
+extern float
+_mesa_strtof( const char *s, char **end );
+
extern unsigned int
_mesa_str_checksum(const char *str);
diff --git a/src/mesa/shader/lex.yy.c b/src/mesa/shader/lex.yy.c
index d1af35f..6d09d1d 100644
--- a/src/mesa/shader/lex.yy.c
+++ b/src/mesa/shader/lex.yy.c
@@ -2212,7 +2212,7 @@ case 142:
YY_RULE_SETUP
#line 326 program_lexer.l
{
- yylval-real = _mesa_strtod(yytext, NULL);
+ yylval-real = _mesa_strtof(yytext, NULL);
return REAL;
}
YY_BREAK
@@ -2224,7 +2224,7 @@ YY_DO_BEFORE_ACTION; /* set up yytext again */
YY_RULE_SETUP
#line 330 program_lexer.l
{
- yylval-real = _mesa_strtod(yytext, NULL);
+ yylval-real = _mesa_strtof(yytext, NULL);
return REAL;
}
YY_BREAK
@@ -2232,7 +2232,7 @@ case 144:
YY_RULE_SETUP
#line 334 program_lexer.l
{
- yylval-real = _mesa_strtod(yytext, NULL);
+ yylval-real = _mesa_strtof(yytext, NULL);
return REAL;
}
YY_BREAK
@@ -2240,7 +2240,7 @@ case 145:
YY_RULE_SETUP
#line 338 program_lexer.l
{
- yylval-real = _mesa_strtod(yytext, NULL);
+ yylval-real = _mesa_strtof(yytext, NULL);
return REAL;
}
YY_BREAK
diff --git a/src/mesa/shader/program_lexer.l
b/src/mesa/shader/program_lexer.l
index 83bc508..fe18272 100644
--- a/src/mesa/shader/program_lexer.l
+++ b/src/mesa/shader/program_lexer.l
@@ -324,19 +324,19 @@ ARRAYSHADOW2D {
return_token_or_IDENTIFIER(require_ARB_fp require
return INTEGER;
}
{num}?{frac}{exp}?{
- yylval-real = _mesa_strtod(yytext, NULL);
+ yylval-real = _mesa_strtof(yytext, NULL);
return REAL;
}
{num}./[^.] {
- yylval-real = _mesa_strtod(yytext, NULL);
+ yylval-real = _mesa_strtof(yytext, NULL);
return REAL;
}
{num}{exp}{
- yylval-real = _mesa_strtod(yytext, NULL);
+ yylval-real = _mesa_strtof(yytext, NULL);
return REAL;
}
{num}.{exp} {
- yylval-real = _mesa_strtod(yytext, NULL);
+ yylval-real = _mesa_strtof(yytext, NULL);
return REAL;
}
--
1.6.3.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Cast needed in program_lexer.l ???
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gonsolo wrote:
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 56e8195..d77b36c 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -810,6 +810,13 @@ _mesa_strtod( const char *s, char **end )
#endif
}
+/** Wrapper around strtof() */
+float
+_mesa_strtof( const char *s, char **end )
+{
+ return strtof(s, end);
+}
+
We can't use strtof for the same reason we can't (directly) use strtod.
It uses the locale, so that can make it parse numbers incorrectly. All
of the users of _mesa_strtod actually want _mesa_strtof, so the right
fix is to change the existing _mesa_strtod to _mesa_strtof.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkua0dEACgkQX1gOwKyEAw9kNgCffpzl4Zxk2JjOwAjIhR2gpiEp
Y8IAoIs8IjQdhm7RdOmmYqWk/RylSmYK
=0Ep5
-END PGP SIGNATURE-
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Framebuffers in mesa
On Fri, Mar 12, 2010 at 12:19 PM, Maciej Cencora m.cenc...@gmail.com wrote: Hi all, I've got some questions regarding FBOs in mesa. I hope you'll be able to answer at least some of them. GLcontext structure holds pointers to 4 gl_framebuffers (DrawBuffer, ReadBuffer, WinSysDrawBuffer, WinSysReadBuffer) and one to gl_renderbuffer (CurrentRenderbuffer). gl_framebuffer struct contains amongs other fields: _ColorDrawBuffers[], _ColorReadBuffers, _DepthBuffer, _StencilBuffer. Now having in mind that r300 wraps all gl_renderbuffers and gl_texture_object Do you mean that r300 subclasses gl_renderbuffer and gl_texture_object? That's what I think you mean. The term wrapping has a special meaning for renderbuffers (see below). (they contain HW buffer objects that I'm interested in), what is the proper way to get to read and draw buffers? The current read framebuffer is at ctx-ReadBuffer. The current drawing framebuffer is ctx-DrawBuffer. Then, if you're reading _colors_ the renderbuffer to use is ctx-ReadBuffer-_ColorReadBuffer. If you want to read _stencil_ values, it would be ctx-ReadBuffer-_StencilBuffer. Similarly for Z/depth, etc. To draw to color buffers (there may be more than one) you'll want ctx-DrawBuffer-_ColorDrawBuffers[]. For stencil it's ctx-DrawBuffer-_Stencil, etc. Renderbuffers typically correspond to a region of video memory. How that works is driver-dependent. What operations use ctx-_ReadBuffer besides glReadPixels,glCopyPixels and glCopyTex(Sub)Image? glCopyColorTable and maybe some other obscure functions. You got the main ones. What operations use ctx-_DrawBuffer besides rendering operations? (glBegin/glEnd, glDrawElements, glDrawArrays, ...) That's basically it, plus glClear. Am I correct that for ctx-_DrawBuffer field _ColorReadBuffer is unused, and for ctx-_ReadBuffer _ColorDrawBuffers is unused? No, they're used - see above. The _ColorReadBuffer field depends on the glReadBuffer() call. The _ColorDrawBuffers[] pointers depend on the glDrawBuffer() and glDrawBuffersARB() functions. It's important to understand the heirarchy of gl_framebuffers and gl_renderbuffers. Each framebuffer object has a collection of renderbuffers. Renderbuffers may also act as wrappers for gl_texture_object when doing render to texture. In this case, the renderbuffer acts as a 2D view into a level/slice/face of a texture object. Also, we have special depth/stencil renderbuffers which wrap combined depth/stencil buffers. See main/depthstencil.c That's mainly for software rendering, though. -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.
The overriding goal is to avoid the expense of computing this in
software when the hardware can do the bounds check.
I guess we could add a PIPE_CAP query to ask the driver if it can do
bounds checking and if it can't, do it in the state tracker. But I
think Keith's interested in minimizing queries like this. Hence, try
to do it in the driver. I think it should be easy to write a
re-usable utility function to do the checks.
If you're seeing ~0, that means the Mesa VBO module has not computed
the bounds, and/or the user didn't provide them. I'd have to check the
code.
If vertex data is coming from regular memory and not a VBO we have no
idea what the legal bounds are.
-Brian
On Fri, Mar 12, 2010 at 5:06 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
This seems to be at odds with the idea that the pipe driver receives
pre-sanitized inputs.
If this patch is reverted:
- I can't trust the min and max elts, because they're set to ~0
- I can't just use the vertex buffer sizes, because they're set to ~0
So I have to do the maths myself, guessing just like st/mesa guesses. Maybe
this is specific to Radeons, but I *always* need those values.
I don't mind this, but IMO it *must* be doc'd, The minimum and maximum
index limits passed to draw_elements and draw_range_elements may be
invalid, and really, at that point, why are we even passing them? Seems
absurd to me. :3
Posting from a mobile, pardon my terseness. ~ C.
On Mar 12, 2010 5:40 AM, Keith Whitwell kei...@vmware.com wrote:
On Fri, 2010-03-12 at 02:54 -0800, Corbin Simpson wrote:
Module: Mesa
Branch: master
Commit: 50876ddaaff72a324ac45e255985e0f84e108594
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=50876ddaaff72a324ac45e255985e0f84e108594
Author: Corbin Simpson mostawesomed...@gmail.com
Date: Fri Mar 12 02:51:40 2010 -0800
st/mesa: Always recalculate invalid index bounds.
These should always be sanitized before heading towards the pipe driver,
and if the calling function explicitly marked them as invalid, we need
to regenerate them.
Allows r300g to properly pass a bit more of Wine's d3d9 testing without
dropping stuff on the floor.
---
src/mesa/state_tracker/st_draw.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c
b/src/mesa/state_tracker/st_draw.c
index 8b01272..d81b361 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -542,9 +542,9 @@ st_draw_vbo(GLcontext *ctx,
assert(ctx-NewState == 0x0);
/* Gallium probably doesn't want this in some cases. */
- if (!index_bounds_valid)
- if (!vbo_all_varyings_in_vbos(arrays))
- vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ if (index_bounds_valid != GL_TRUE) {
+ vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ }
Corbin,
This isn't really desirable. Ideally this range checking should be
pushed into pipe driver, because it's an expensive operation that is not
necessary on a lot of hardware. #
Specifically, vertex fetch hardware can often be set up with the min/max
permissible index bounds to avoid accessing vertex data outside of the
bound VB's. This can be achieved by examining the VBs, with min_index
== 0, max_index = vb.size / vb.stride.
The case where we need to calculate them internally is if some data is
not in a VB, meaning we can't guess what the legal min/max values are.
Also note that we need that min/max information to be able to upload the
data to a VB.
So, I think the code was probably correct in the original version -
defer the minmax scan to the hardware driver, which may or may not need
it.
But maybe there is a better way to let the driver know that we are not
providing this information.
Keith
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Cast needed in program_lexer.l ???
We can't use strtof for the same reason we can't (directly) use strtod. It uses the locale, so that can make it parse numbers incorrectly. All of the users of _mesa_strtod actually want _mesa_strtof, so the right fix is to change the existing _mesa_strtod to _mesa_strtof. Some remarks from a beginner: 1. Isn't strtod meant to be a very basic function? Making it dependent on a locale isn't helpful. 2. I see strtod_l is defined in /usr/include/stdlib.h which is part of the package libc6-dev on my Ubuntu system, yet there is no manpage for it. 3. strtod is defined in /usr/include/stdlib.h which is in package libc6-dev, the manpage is in manpages-dev. From my limited view, every function should be defined in some_package, it should be declared in some_package-dev and documented in some_package-doc. Is there any reason for this mess except being historical? (Please excuse my ignorance, just a beginner :) ) g -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] xdemos build breakage...
From: Dan Nicholson dbn.li...@gmail.com To: Brian Paul bri...@vmware.com Cc: Jeff Smith whydo...@yahoo.com; David Miller da...@davemloft.net; mesa3d-dev@lists.sourceforge.net mesa3d-dev@lists.sourceforge.net Sent: Fri, March 12, 2010 10:51:29 AM Subject: Re: [Mesa3d-dev] xdemos build breakage... That's not really the right thing, though. You're assuming that I have libX11 in the same libdir as I'm installing to and I want to use it. The fact is that configure uses pkg-config to check for x11 and other libraries needed to link the demos. It certainly was working before without requiring hardcoding things into the Makefiles. Oops, I didn't see your reply, Dan. I already committed Jeff's patch. If you have better fix, please revert. No problem. I'll look at it a little later and see if there's more of a general fix from autoconf. I imagine it's not the last time we'll see build breakage in the demos. -- Dan Dan, Can you please review this patch? I believe it handles the case described. -- Jeff 0005-Use-X11_LIBS-from-pkg-config-instead-of-libdir-for.patch Description: Binary data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.
Isn't it possible to compute the maximum legal index by just taking the minimum of: (vb-buffer-size - vb-buffer_offset - ve-src_offset) / vb-stride over all vertex buffers/elements? Isn't the kernel checker doing something like this? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.
Actually, why is the state tracker doing the min/max computation at all? If the driver does the index lookup itself, as opposed to using an hardware index buffer, (e.g. the nouveau drivers do this in some cases) this is unnecessary and slow. Would completely removing the call to vbo_get_minmax_index break anything? Also, how about removing the max_index field in pipe_vertex_buffer? This seems to be set to the same value for all vertex buffers, and the value is then passed to draw_range_elements too. Isn't the value passed to draw_range_elements sufficient? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
