Re: [Mesa-dev] [PATCH] tnl: Add support for datatype GL_FIXED in vertex arrays
On 2011/2/15 13:08, Eric Anholt wrote: On Tue, 8 Feb 2011 14:30:55 -0800, Chad Versace wrote: Before populating the vertex buffer attribute pointer (VB->AttribPtr[]), convert vertex data in GL_FIXED format to GL_FLOAT. Fixes bug: http://bugs.freedesktop.org/show_bug.cgi?id=34047 Don't suppose we have a testcase for these? It could go easily in the ARB_ES2_compat directory without needing new framework stuff. Does this mean, we don't need infrastructure to support OpenGL ES 2.0 for piglit anymore? Thanks --Shuang ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] tnl: Add support for datatype GL_FIXED in vertex arrays
On Tue, 8 Feb 2011 14:30:55 -0800, Chad Versace wrote: > Before populating the vertex buffer attribute pointer (VB->AttribPtr[]), > convert vertex data in GL_FIXED format to GL_FLOAT. > > Fixes bug: http://bugs.freedesktop.org/show_bug.cgi?id=34047 Don't suppose we have a testcase for these? It could go easily in the ARB_ES2_compat directory without needing new framework stuff. pgpsXW7hcj6Sp.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
On Monday 14 February 2011 21:13:04 Matt Turner wrote: > On Mon, Feb 14, 2011 at 8:31 PM, Yahya H. Mirza wrote: > > Is there anyone looking into using CMAKE as another build system for > > MESA? > > The solution is not another build system. in this case it is. the issue with vs build files is that no one working on linux would be even able to update them so they're bound to get broken every day. cmake can generate native project files on all platforms - linux, os x (xcode), windows (vs) so in that sense it's the only build system that could reasonably cover all the platforms and is the only build system that could replace everything we have right now. the fact that piglit and our demos already use it make it even easier. the build system to rule them all. unfortunately Jose tried it and the issue was that cmake doesn't support convinenice libraries which mesa uses quite extensively and there was no decent way of making it work without recompiling the same file number of times (not a workable solution from a development point of view). so as it stands scons is the "official" way of building on windows. z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
On Mon, Feb 14, 2011 at 8:31 PM, Yahya H. Mirza wrote: > Is there anyone looking into using CMAKE as another build system for MESA? The solution is not another build system. Although, after cmake, if we just added an imake build system, I think we'd have everything covered. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
Thanks for the reply. Is there anyone looking into using CMAKE as another build system for MESA? Thanks in advance. Yahya -Original Message- From: Brian Paul [mailto:brian.e.p...@gmail.com] Sent: Monday, February 14, 2011 8:36 AM To: Yahya H. Mirza Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010 On Fri, Feb 11, 2011 at 11:31 AM, Yahya H. Mirza wrote: > Hi All, > > > > I've been trying to build Mesa 7.10 on Windows 7 / Visual Studio 2010 > and I have been having some problems. > > > > When I opened > > \windows\VC8\mesa\mesa.sln, it was automatically converted to VS2010. > > > > When I tried to build the various projects there were a number of > problems including a number of misconfigured build directories. > > > > Additionally, when building the mesa project in VS2010, it has trouble > finding a path for building "predefined shaders". > > > > Finally, the "glsl_apps_compile" project seems to be out of date. > > > > Is there an updated version of this solution file for Mesa7.10 / > VS2010, or has anyone successfully built Mesa7.10 with CMAKE? > > > > Any suggestions on successfully building Mesa7.10 for Windows7 / > VS2010 would be greatly appreciated. The MSVC project files for Mesa haven't been maintained in a while. They'll be removed in the next Mesa release. Instead, take a look at the instructions for building with scons. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] mesa: Optionally build a dricore support library (v3)
On Mon, Feb 14, 2011 at 4:15 AM, Christopher James Halse Rogers wrote: > On Sat, 2011-02-12 at 15:19 +0100, Sedat Dilek wrote: >> Hi, >> >> here on radeon RV250 I can only use swrast DRI driver. >> >> [ Xorg.log ] >> ... >> [ 3354.432] (EE) AIGLX error: Calling driver entry point failed >> [ 3354.432] (EE) AIGLX: reverting to software rendering >> ... >> >> My autogen-line looks like this: >> >> ./autogen.sh --prefix=/usr --with-driver=dri >> --with-dri-driverdir=/usr/lib/dri --with-dri-drivers=r200 >> --disable-gallium --disable-egl --disable-glu --disable-glut >> --disable-glw --enable-shared-dricore --enable-glx-tls --enable-debug >> >> I have attached my Xorg.log and mesa build-log. >> >> I have built ddx and mesa from git against same libdrm, not sure if >> there is some correlations with mesa-pkgs from experimental. >> >> Any ideas why I can't use classic-mesa DRI driver with >> --enable-shared-dricore (normal built mesa works fine, w/o the new >> confgure option)? > > That build log looks fine to me. Could you also give the output of > ldd /usr/lib/dri/r200_dri.so (and ldd /usr/lib/dri/swrast_dri.so as a > control)? > I have now built with --with-dri-drivers=r200,swrast (rest same as above). root@tbox:~# ldd /usr/lib/dri/r200_dri.so linux-gate.so.1 => (0xb78e) libdricore.so => /usr/lib/dri/libdricore.so (0xb7654000) libglsl.so => /usr/lib/dri/libglsl.so (0xb7549000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7528000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7502000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb74e9000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb74e5000) libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0xb74df000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb73f2000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb73cc000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb73af000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7269000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb726) /lib/ld-linux.so.2 (0xb78e1000) root@tbox:~# ldd /usr/lib/dri/swrast_dri.so linux-gate.so.1 => (0xb77c) libdricore.so => /usr/lib/dri/libdricore.so (0xb75ab000) libglsl.so => /usr/lib/dri/libglsl.so (0xb74a) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb747f000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7459000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb744) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb743c000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb735) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7329000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb730c000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb71c6000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb71bd000) /lib/ld-linux.so.2 (0xb77c1000) root@tbox:~# ldd /usr/lib/dri/libdricore.so linux-gate.so.1 => (0xb789b000) libglsl.so => /usr/lib/dri/libglsl.so (0xb7587000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7485000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb745e000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7441000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb72fb000) /lib/ld-linux.so.2 (0xb789c000) root@tbox:~# ldd /usr/lib/dri/libglsl.so linux-gate.so.1 => (0xb77cb000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb75bc000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7596000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7578000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7432000) /lib/ld-linux.so.2 (0xb77cc000 root@tbox:~# egrep -i 'aiglx|swrast' /var/log/Xorg.0.log [ 2863.123] (==) AIGLX enabled [ 2863.275] (EE) AIGLX error: Calling driver entry point failed [ 2863.276] (EE) AIGLX: reverting to software rendering [ 2863.276] (II) AIGLX: Screen 0 is not DRI capable [ 2863.277] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so [ 2863.277] (II) GLX: Initialized DRISWRAST GL provider for screen 0 >> >> Regards, >> - Sedat - >> >> P.S.: >> >> # LC_ALL=C ls -alt /usr/lib/libGL* /usr/lib/dri/ >> lrwxrwxrwx 1 sd sd 10 Feb 12 14:53 /usr/lib/libGL.so -> libGL.so.1 >> lrwxrwxrwx 1 sd sd 12 Feb 12 14:53 /usr/lib/libGL.so.1 -> >> libGL.so.1.2 >> -rwxr-xr-x 1 sd sd 2243051 Feb 12 14:53 /usr/lib/libGL.so.1.2 >> lrwxrwxrwx 1 root root 11 Feb 12 12:14 /usr/lib/libGLU.so -> libGLU.so.1 >> lrwxrwxrwx 1 root root 20 Feb 12 12:14 /usr/lib/libGLU.so.1 -> >> libGLU.so.1.3.071000 >> lrwxrwxrwx 1 root root 16 Feb 10 07:43 /usr/lib/libGLEW.so.1.5 -> >> libGLEW.so.1.5.8 >> -rw-r--r-- 1 root root 347376 Feb 9 08:57 /usr/lib/libGLEW.so.1.5.8 >> -rw-r--r-- 1 root root 716106 Feb 8 18:31 /usr/lib/libGLU.a >> -rw-r--r-- 1 root root 454672 Feb 8 18:31 /usr/lib/libGLU.so.1.3.071000 >> >> /usr/lib/dri/: >> total 59180 >> drwxr-xr-x 147 root root 81920 Feb 12 14:58 .. >> -rwxr-xr-x
[Mesa-dev] [PATCH] tnl: Add support for datatype GL_FIXED in vertex arrays
Before populating the vertex buffer attribute pointer (VB->AttribPtr[]),
convert vertex data in GL_FIXED format to GL_FLOAT.
Fixes bug: http://bugs.freedesktop.org/show_bug.cgi?id=34047
---
src/mesa/tnl/t_draw.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/src/mesa/tnl/t_draw.c b/src/mesa/tnl/t_draw.c
index 858b828..b1967e6 100644
--- a/src/mesa/tnl/t_draw.c
+++ b/src/mesa/tnl/t_draw.c
@@ -125,6 +125,43 @@ convert_half_to_float(const struct gl_client_array *input,
}
}
+/**
+ * \brief Convert fixed-point to floating-point.
+ *
+ * In OpenGL, a fixed-point number is a "signed 2's complement 16.16 scaled
+ * integer" (Table 2.2 of the OpenGL ES 2.0 spec).
+ *
+ * If the buffer has the \c normalized flag set, the formula
+ * \code normalize(x) := (2*x + 1) / (2^16 - 1) \endcode
+ * is used to map the fixed-point numbers into the range [-1, 1].
+ */
+static void
+convert_fixed_to_float(const struct gl_client_array *input,
+ const GLubyte *ptr, GLfloat *fptr,
+ GLuint count)
+{
+ GLuint i, j;
+ const GLint size = input->Size;
+
+ if (input->Normalized) {
+ for (i = 0; i < count; ++i) {
+ const GLfixed *in = (GLfixed *) ptr;
+ for (j = 0; j < size; ++j) {
+*fptr++ = (GLfloat) (2 * in[j] + 1) / (GLfloat) ((1 << 16) - 1);
+ }
+ ptr += input->StrideB;
+ }
+ } else {
+ for (i = 0; i < count; ++i) {
+ const GLfixed *in = (GLfixed *) ptr;
+ for (j = 0; j < size; ++j) {
+*fptr++ = in[j] / (GLfloat) (1 << 16);
+ }
+ ptr += input->StrideB;
+ }
+ }
+}
+
/* Adjust pointer to point at first requested element, convert to
* floating point, populate VB->AttribPtr[].
*/
@@ -174,6 +211,9 @@ static void _tnl_import_array( struct gl_context *ctx,
case GL_HALF_FLOAT:
convert_half_to_float(input, ptr, fptr, count, sz);
break;
+ case GL_FIXED:
+ convert_fixed_to_float(input, ptr, fptr, count);
+ break;
default:
assert(0);
break;
--
1.7.3.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
Hi, I have made VS2008 project and solution files based on the scons files. I have also included generation of necessary source files from python as part of the build. This also works in VS2010. My requirement was to get OpenGL software rendering to work so it's not tested for other configurations. I also had to make small changes to the source code, like casting void pointers to the proper type (malloc). > The MSVC project files for Mesa haven't been maintained in a while. > They'll be removed in the next Mesa release. Instead, take a look at > the instructions for building with scons. This is sad news for me and probably a few others on the Windows platform. Most of us are used to writing code and debug inside Visual Studio and would be pretty helpless working from the command line. In December I tried to submit the project and solution files to mesa-user as an attachment but the post was to big and I didn't have the time to follow up. Btw. git is new territory for me. Regards, Brede On Mon, Feb 14, 2011 at 3:36 PM, Brian Paul wrote: > On Fri, Feb 11, 2011 at 11:31 AM, Yahya H. Mirza wrote: >> Hi All, >> >> >> >> I’ve been trying to build Mesa 7.10 on Windows 7 / Visual Studio 2010 and I >> have been having some problems. >> >> >> >> When I opened >> >> \windows\VC8\mesa\mesa.sln, it was automatically converted to VS2010. >> >> >> >> When I tried to build the various projects there were a number of problems >> including a number of misconfigured build directories. >> >> >> >> Additionally, when building the mesa project in VS2010, it has trouble >> finding a path for building “predefined shaders”. >> >> >> >> Finally, the “glsl_apps_compile” project seems to be out of date. >> >> >> >> Is there an updated version of this solution file for Mesa7.10 / VS2010, or >> has anyone successfully built Mesa7.10 with CMAKE? >> >> >> >> Any suggestions on successfully building Mesa7.10 for Windows7 / VS2010 >> would be greatly appreciated. > > The MSVC project files for Mesa haven't been maintained in a while. > They'll be removed in the next Mesa release. Instead, take a look at > the instructions for building with scons. > > -Brian > ___ > 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
[Mesa-dev] [Bug 34261] Buildsystem disables openvg when disabling gallium egl
https://bugs.freedesktop.org/show_bug.cgi?id=34261 Hicham HAOUARI changed: What|Removed |Added CC||airl...@freedesktop.org -- 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 34261] Buildsystem disables openvg when disabling gallium egl
https://bugs.freedesktop.org/show_bug.cgi?id=34261 --- Comment #2 from Hicham HAOUARI 2011-02-14 15:05:56 PST --- (In reply to comment #1) > The OpenVG support is provided by the vega gallium state tracker, so it's > bound > up with gallium EGL support. > > I think that the poor interaction between gallium EGL and Wayland has been > resolved in mesa master, in: > commit a22a332fc7cc54d4d0973dcd21a90159cc51de1a > Author: Chia-I Wu > Date: Thu Jan 13 04:40:38 2011 +0800 > > egl: Improve driver selection. > > The idea is to be able to match a driver using the following order > > try egl_gallium with hw renderer > try egl_dri2 > try egl_gallium with sw renderer > try egl_glx Thanks for your quick reply, sadly that commit isn't on 7.10 yet -- 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] [PATCH] r600g: Fix RGB10_A2 format handling
On 14 February 2011 18:07, Fabian Bieler wrote: > This patch fixes the fbo/fbo-clear-formats piglit test. > > As PIPE_FORMAT_B10G10R10A2_UNORM is the only format the mesa state tracker > uses, this is the only format I actualy tested. > Evergreen likely needs the same fix. Please keep r600_state_inlines.h and eg_state_inlines in sync unless there's a reason for them to be different. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 34261] Buildsystem disables openvg when disabling gallium egl
https://bugs.freedesktop.org/show_bug.cgi?id=34261 --- Comment #1 from Christopher James Halse Rogers 2011-02-14 14:19:06 PST --- The OpenVG support is provided by the vega gallium state tracker, so it's bound up with gallium EGL support. I think that the poor interaction between gallium EGL and Wayland has been resolved in mesa master, in: commit a22a332fc7cc54d4d0973dcd21a90159cc51de1a Author: Chia-I Wu Date: Thu Jan 13 04:40:38 2011 +0800 egl: Improve driver selection. The idea is to be able to match a driver using the following order try egl_gallium with hw renderer try egl_dri2 try egl_gallium with sw renderer try egl_glx -- 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] [PATCH] st/mesa: Use blend equation and function of first render target for all render targets if ARB_draw_buffers_blend is not supported
On 02/14/2011 10:01 AM, Fabian Bieler wrote: This patch fixes the fbo/fbo-drawbuffers2-blend piglit test. Looks good. I'll commit it soon. Thanks! -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] gallium: remove pipe_vertex_buffer::max_index
On Mon, Feb 14, 2011 at 6:58 PM, José Fonseca wrote: > Marek, > > I'm OK with removing pipe_vertex_buffer::max_index but there is a bit > more work involved, as they are not really equivalent in the guarantees. > > pipe_vertex_buffer::max_index is an attribute of the vertex buffer -- it > describe the max index that can be fetch from the buffer without running > into a buffer overflow. It is an hard limit -- it must be set > accurately by the state tracker or crashes will occur. It can be > removed because it can be derived from the vertex element size, vertex > element stride, vertex buffer offset, and vertex buffer size. > > pipe_draw_info::max_index is an attribute of the index buffer: it > describes the maximum index in the index buffer. It is an hint -- there > may be higher indices in the index buffer, and if so it is OK for the > driver to ignore those vertices, but it should not crash with a buffer > overflow. > > Therefore, in order to safely remove pipe_vertex_buffer::max_index, we > should compute the max_index inside the draw module / pipe drivers, and > ensure vertices with higher indices will never be removed. > > There are a few places in this patch where you replace > pipe_vertex_buffer::max_index with ~0 or no checks, which means that > places which where previous robust to pipe_draw_info::max_index == ~0 > and bogus indices will now start crashing. > You're right in theory. In practice, pipe_vertex_buffer::max_index was really derived from the value which is put in pipe_draw_info::max_index and was correctly initialized for user buffers only. It was set to ~0 for hardware buffers. Moreover, it could also be computed with: pipe_vertex_buffer::max_index = (pipe_resource::width0 - pipe_vertex_buffer::buffer_offset) / pipe_vertex_buffer::stride - 1 So it was already redundant. Basically, pipe_resource::width0 is also redundant for user buffers, because it is actually computed from pipe_draw_info::max_index too. It's all logical because the index bounds are the only info we have about user buffers and we compute all the other properties from it. This is how width0 is computed: pipe_resource::width0 = (pipe_draw_info::max_index + 1) * pipe_vertex_buffer::stride; Now we substitute width0 in the first formula: pipe_vertex_buffer::max_index = ((pipe_draw_info::max_index + 1) * pipe_vertex_buffer::stride - pipe_vertex_buffer::buffer_offset) / pipe_vertex_buffer::stride - 1 If we examine the state tracker code, we'll notice that buffer_offset is always 0 for user buffers. After simplification, we get this: pipe_vertex_buffer::max_index = pipe_draw_info::max_index And that's the whole story. That said, I'd like not to call set_vertex_buffers only to update max_index if I can get the same info from pipe_draw_info. Because pipe_vertex_buffer::max_index was really the maximum index value in the index buffer, we don't need to clamp anything when we fetch vertices, the clamping would basically do nothing. That's why I removed the clamping in Draw and put ~0 in the translate::run parameter and in several other places. Does this explanation justify all of my changes in the patch to you? Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] pb_bufmgr_cache: add is_buffer_busy hook and use it instead of non-blocking map
On Mon, 2011-02-14 at 10:18 -0800, Marek Olšák wrote:
> On Mon, Feb 14, 2011 at 6:47 PM, José Fonseca
> mailto:jfons...@vmware.com>> wrote:
> On Sun, 2011-02-13 at 23:58 -0800, Dave Airlie wrote:
> > >>if(buf->base.base.size < size)
> > >> return 0;
> > >>
> > >> @@ -242,13 +240,10 @@ pb_cache_is_buffer_compat(struct pb_cache_buffer
> > >> *buf,
> > >>if(!pb_check_usage(desc->usage, buf->base.base.usage))
> > >> return 0;
> > >>
> > >> - map = pb_map(buf->buffer, PB_USAGE_DONTBLOCK, NULL);
> > >> - if (!map) {
> > >> - return -1;
> > >> - }
> > >> + if (buf->mgr->base.is_buffer_busy)
> > >> + if (buf->mgr->base.is_buffer_busy(&buf->mgr->base, buf->buffer))
> > >> + return -1;
> > >
> > > Oops, this is wrong. I will locally replace any occurences of
> > > "buf->mgr->base(.)" with "buf->mgr->provider(->)", which is how it was
> > > meant
> > > to be, but the idea remains the same. Please review.
>
> Marek, I don't understand what you want to do here: you removed the
> pb_map, but you left the pb_unmap, and what will happen if
> is_buffer_busy is not defined?
>
> I didn't leave the pb_unmap call, it was removed too, I just cut it off in my
> second email, since it wasn't relevant to the typo. Sorry about that. So
> there's only one way: is_buffer_busy.
>
>
> >
> > I actually suggested this originally, but Jose I think preferred using
> > the dontblock to the buffer mapping.
>
> I'd prefer that there is one way of doing this, but I didn't/don't feel
> strong about this. IMO, having two ways, PB_USAGE_DONTBLOCK and
> is_buffer_busy, is not cleaner that just PB_USAGE_DONTBLOCK, even if
> is_buffer_busy is conceptually cleaner.
>
> The thing is mapping a buffer just to know whether it's being used is
> unnecessary, and the mapping itself may be slower than a simple is_busy query.
>
>
> Marek, Would adding an inline function, pb_is_buffer_busy, that calls
> pb_map(PB_USAGE_DONTBLOCK)+pb_unmap inside work for you?
>
> Another way, would be to add is_buffer_busy and have the default
> implementation to do pb_map/pb_unmap.
>
> I can add a piece of code that uses pb_map/pb_unmap if the is_buffer_busy
> hook is not set, so that the original behavior is preserved. Would that be ok
> with you? Here's a new patch:
>
>
> pb_bufmgr_cache: add is_buffer_busy hook and use it instead of
> non-blocking map
>
> This is cleaner and implementing the hook is optional.
>
> diff --git a/src/gallium/auxiliary/pipebuffer/pb_bufmgr.h
> b/src/gallium/auxiliary/pipebuffer/pb_bufm
> index 2ef0216..960068c 100644
> --- a/src/gallium/auxiliary/pipebuffer/pb_bufmgr.h
> +++ b/src/gallium/auxiliary/pipebuffer/pb_bufmgr.h
> @@ -82,6 +82,10 @@ struct pb_manager
> */
> void
> (*flush)( struct pb_manager *mgr );
> +
> + boolean
> + (*is_buffer_busy)( struct pb_manager *mgr,
> + struct pb_buffer *buf );
> };
>
>
> diff --git a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
> b/src/gallium/auxiliary/pipebuffer/p
> index a6eb403..25accef 100644
> --- a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
> +++ b/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
> @@ -227,8 +227,6 @@ pb_cache_is_buffer_compat(struct pb_cache_buffer *buf,
>pb_size size,
>const struct pb_desc *desc)
> {
> - void *map;
> -
> if(buf->base.base.size < size)
>return 0;
>
> @@ -242,13 +240,18 @@ pb_cache_is_buffer_compat(struct pb_cache_buffer *buf,
> if(!pb_check_usage(desc->usage, buf->base.base.usage))
>return 0;
>
> - map = pb_map(buf->buffer, PB_USAGE_DONTBLOCK, NULL);
> - if (!map) {
> - return -1;
> + if (buf->mgr->provider->is_buffer_busy) {
> + if (buf->mgr->provider->is_buffer_busy(buf->mgr->provider,
> buf->buffer))
> + return -1;
> + } else {
> + void *ptr = pb_map(buf->buffer, PB_USAGE_DONTBLOCK, NULL);
> +
> + if (!ptr)
> + return -1;
> +
> + pb_unmap(buf->buffer);
> }
>
> - pb_unmap(buf->buffer);
> -
> return 1;
> }
This looks a better solution in the interim. We can ensure implement
is_buffer_busy everywhere, and replace this fallback with an
assert(buf->mgr->provider->is_buffer_busy) at a later stage. Thanks.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] pb_bufmgr_cache: add is_buffer_busy hook and use it instead of non-blocking map
On Mon, Feb 14, 2011 at 6:47 PM, José Fonseca wrote:
> On Sun, 2011-02-13 at 23:58 -0800, Dave Airlie wrote:
> > >>if(buf->base.base.size < size)
> > >> return 0;
> > >>
> > >> @@ -242,13 +240,10 @@ pb_cache_is_buffer_compat(struct pb_cache_buffer
> > >> *buf,
> > >>if(!pb_check_usage(desc->usage, buf->base.base.usage))
> > >> return 0;
> > >>
> > >> - map = pb_map(buf->buffer, PB_USAGE_DONTBLOCK, NULL);
> > >> - if (!map) {
> > >> - return -1;
> > >> - }
> > >> + if (buf->mgr->base.is_buffer_busy)
> > >> + if (buf->mgr->base.is_buffer_busy(&buf->mgr->base,
> buf->buffer))
> > >> + return -1;
> > >
> > > Oops, this is wrong. I will locally replace any occurences of
> > > "buf->mgr->base(.)" with "buf->mgr->provider(->)", which is how it was
> meant
> > > to be, but the idea remains the same. Please review.
>
> Marek, I don't understand what you want to do here: you removed the
> pb_map, but you left the pb_unmap, and what will happen if
> is_buffer_busy is not defined?
>
I didn't leave the pb_unmap call, it was removed too, I just cut it off in
my second email, since it wasn't relevant to the typo. Sorry about that. So
there's only one way: is_buffer_busy.
> >
> > I actually suggested this originally, but Jose I think preferred using
> > the dontblock to the buffer mapping.
>
> I'd prefer that there is one way of doing this, but I didn't/don't feel
> strong about this. IMO, having two ways, PB_USAGE_DONTBLOCK and
> is_buffer_busy, is not cleaner that just PB_USAGE_DONTBLOCK, even if
> is_buffer_busy is conceptually cleaner.
>
The thing is mapping a buffer just to know whether it's being used is
unnecessary, and the mapping itself may be slower than a simple is_busy
query.
> Marek, Would adding an inline function, pb_is_buffer_busy, that calls
> pb_map(PB_USAGE_DONTBLOCK)+pb_unmap inside work for you?
>
> Another way, would be to add is_buffer_busy and have the default
> implementation to do pb_map/pb_unmap.
>
I can add a piece of code that uses pb_map/pb_unmap if the is_buffer_busy
hook is not set, so that the original behavior is preserved. Would that be
ok with you? Here's a new patch:
pb_bufmgr_cache: add is_buffer_busy hook and use it instead of
non-blocking map
This is cleaner and implementing the hook is optional.
diff --git a/src/gallium/auxiliary/pipebuffer/pb_bufmgr.h
b/src/gallium/auxiliary/pipebuffer/pb_bufm
index 2ef0216..960068c 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_bufmgr.h
+++ b/src/gallium/auxiliary/pipebuffer/pb_bufmgr.h
@@ -82,6 +82,10 @@ struct pb_manager
*/
void
(*flush)( struct pb_manager *mgr );
+
+ boolean
+ (*is_buffer_busy)( struct pb_manager *mgr,
+ struct pb_buffer *buf );
};
diff --git a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
b/src/gallium/auxiliary/pipebuffer/p
index a6eb403..25accef 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
+++ b/src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c
@@ -227,8 +227,6 @@ pb_cache_is_buffer_compat(struct pb_cache_buffer *buf,
pb_size size,
const struct pb_desc *desc)
{
- void *map;
-
if(buf->base.base.size < size)
return 0;
@@ -242,13 +240,18 @@ pb_cache_is_buffer_compat(struct pb_cache_buffer *buf,
if(!pb_check_usage(desc->usage, buf->base.base.usage))
return 0;
- map = pb_map(buf->buffer, PB_USAGE_DONTBLOCK, NULL);
- if (!map) {
- return -1;
+ if (buf->mgr->provider->is_buffer_busy) {
+ if (buf->mgr->provider->is_buffer_busy(buf->mgr->provider,
buf->buffer))
+ return -1;
+ } else {
+ void *ptr = pb_map(buf->buffer, PB_USAGE_DONTBLOCK, NULL);
+
+ if (!ptr)
+ return -1;
+
+ pb_unmap(buf->buffer);
}
- pb_unmap(buf->buffer);
-
return 1;
}
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Mesa/Gallium vertex array state optimizations
Marek, Apart of some subtleties with removing pipe_vertex_buffer::max_index, I think this looks great. I'm OK with addressing the pipe_vertex_buffer::max_index issues after commiting this series, as well behaved applications should not be affected. Jose On Sat, 2011-02-12 at 11:05 -0800, Marek Olšák wrote: > Hi, > > this patch series optimizes vertex array state changes in Mesa/Gallium. The > problem with the vbo module and st/mesa is that it re-binds vertex arrays > every draw operation instead of only when they get changed by the > application, and this series aims to address that issue. > > Some new issues arose during the implemention though: > > 1) The VBO module didn't notify the underlying driver when it was > changing buffer offsets and other vertex array properties. This is > fixed in the 1st patch. > > 2) If we do not re-bind vertex arrays every draw operation, we must assure > that the state is preserved after operations like glBlitFramebuffer. This is > resolved in the 3rd patch using cso_cache. > > 3) Unfortunately, user buffers must be mutable in order to prevent re-binding > vertex buffers because we have no way to know how large they are. Instead, a > new context hook has been added to Gallium called 'redefine_user_buffer', > which notifies a driver that a subrange of a user buffer should be > reuploaded, and also redefines its size. > > I've only tested softpipe and r300g and there were no regressions. r600g > should also work and Christopher told me his Nouveau drivers should be ready > for this series too. > > Please review. > > Marek Olšák (6): > vbo: notify a driver that we change buffer offsets, strides, etc. > vbo: bind arrays only when necessary > gallium: always save and restore vertex buffers using cso_cache > gallium: remove pipe_vertex_buffer::max_index > st/mesa: set vertex arrays state only when necessary > gallium: notify drivers about possible changes in user buffer contents > > Best regards > Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] gallium: remove pipe_vertex_buffer::max_index
Marek,
I'm OK with removing pipe_vertex_buffer::max_index but there is a bit
more work involved, as they are not really equivalent in the guarantees.
pipe_vertex_buffer::max_index is an attribute of the vertex buffer -- it
describe the max index that can be fetch from the buffer without running
into a buffer overflow. It is an hard limit -- it must be set
accurately by the state tracker or crashes will occur. It can be
removed because it can be derived from the vertex element size, vertex
element stride, vertex buffer offset, and vertex buffer size.
pipe_draw_info::max_index is an attribute of the index buffer: it
describes the maximum index in the index buffer. It is an hint -- there
may be higher indices in the index buffer, and if so it is OK for the
driver to ignore those vertices, but it should not crash with a buffer
overflow.
Therefore, in order to safely remove pipe_vertex_buffer::max_index, we
should compute the max_index inside the draw module / pipe drivers, and
ensure vertices with higher indices will never be removed.
There are a few places in this patch where you replace
pipe_vertex_buffer::max_index with ~0 or no checks, which means that
places which where previous robust to pipe_draw_info::max_index == ~0
and bogus indices will now start crashing.
Jose
On Sat, 2011-02-12 at 11:04 -0800, Marek Olšák wrote:
> This is redundant to pipe_draw_info::max_index and doesn't really fit
> in the optimizations I plan.
> ---
> src/gallium/auxiliary/draw/draw_llvm.c | 17 -
> src/gallium/auxiliary/draw/draw_llvm.h |5 +
> src/gallium/auxiliary/draw/draw_pt.c |3 +--
> src/gallium/auxiliary/draw/draw_pt_fetch.c |4 ++--
> src/gallium/auxiliary/draw/draw_pt_fetch_emit.c|2 +-
> .../auxiliary/draw/draw_pt_fetch_shade_emit.c |2 +-
> src/gallium/auxiliary/util/u_draw_quad.c |1 -
> src/gallium/auxiliary/util/u_dump_state.c |1 -
> src/gallium/docs/d3d11ddi.txt |1 -
> src/gallium/drivers/svga/svga_state_vs.c |2 +-
> src/gallium/drivers/trace/tr_dump_state.c |1 -
> src/gallium/include/pipe/p_state.h |1 -
> .../state_trackers/d3d1x/dxgi/src/dxgi_native.cpp |1 -
> .../state_trackers/d3d1x/gd3d11/d3d11_context.h|1 -
> src/gallium/state_trackers/vega/polygon.c |2 --
> src/gallium/tests/graw/fs-test.c |1 -
> src/gallium/tests/graw/gs-test.c |2 --
> src/gallium/tests/graw/quad-tex.c |1 -
> src/gallium/tests/graw/shader-leak.c |1 -
> src/gallium/tests/graw/tri-gs.c|1 -
> src/gallium/tests/graw/tri-instanced.c |2 --
> src/gallium/tests/graw/tri.c |1 -
> src/gallium/tests/graw/vs-test.c |1 -
> src/mesa/state_tracker/st_draw.c |5 -
> src/mesa/state_tracker/st_draw_feedback.c |1 -
> 25 files changed, 11 insertions(+), 49 deletions(-)
>
> diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
> b/src/gallium/auxiliary/draw/draw_llvm.c
> index a73bdd7..a5217c1 100644
> --- a/src/gallium/auxiliary/draw/draw_llvm.c
> +++ b/src/gallium/auxiliary/draw/draw_llvm.c
> @@ -214,13 +214,12 @@ static LLVMTypeRef
> create_jit_vertex_buffer_type(struct gallivm_state *gallivm)
> {
> LLVMTargetDataRef target = gallivm->target;
> - LLVMTypeRef elem_types[4];
> + LLVMTypeRef elem_types[3];
> LLVMTypeRef vb_type;
>
> elem_types[0] =
> - elem_types[1] =
> - elem_types[2] = LLVMInt32TypeInContext(gallivm->context);
> - elem_types[3] = LLVMPointerType(LLVMInt8TypeInContext(gallivm->context),
> 0); /* vs_constants */
> + elem_types[1] = LLVMInt32TypeInContext(gallivm->context);
> + elem_types[2] = LLVMPointerType(LLVMInt8TypeInContext(gallivm->context),
> 0); /* vs_constants */
>
> vb_type = LLVMStructTypeInContext(gallivm->context, elem_types,
> Elements(elem_types), 0);
> @@ -229,10 +228,8 @@ create_jit_vertex_buffer_type(struct gallivm_state
> *gallivm)
>
> LP_CHECK_MEMBER_OFFSET(struct pipe_vertex_buffer, stride,
>target, vb_type, 0);
> - LP_CHECK_MEMBER_OFFSET(struct pipe_vertex_buffer, max_index,
> - target, vb_type, 1);
> LP_CHECK_MEMBER_OFFSET(struct pipe_vertex_buffer, buffer_offset,
> - target, vb_type, 2);
> + target, vb_type, 1);
>
> LP_CHECK_STRUCT_SIZE(struct pipe_vertex_buffer, target, vb_type);
>
> @@ -513,9 +510,7 @@ generate_fetch(struct gallivm_state *gallivm,
> LLVMValueRef vbuffer_ptr = LLVMBuildGEP(builder, vbuffers_ptr,
> &indices, 1, "");
> LLVMValueRef vb_stride = draw_jit_vbuffer_stride(gallivm, vbuf);
> - LLVMValueRef vb_ma
Re: [Mesa-dev] [PATCH 2/2] pb_bufmgr_cache: add is_buffer_busy hook and use it instead of non-blocking map
On Sun, 2011-02-13 at 23:58 -0800, Dave Airlie wrote:
> >>if(buf->base.base.size < size)
> >> return 0;
> >>
> >> @@ -242,13 +240,10 @@ pb_cache_is_buffer_compat(struct pb_cache_buffer
> >> *buf,
> >>if(!pb_check_usage(desc->usage, buf->base.base.usage))
> >> return 0;
> >>
> >> - map = pb_map(buf->buffer, PB_USAGE_DONTBLOCK, NULL);
> >> - if (!map) {
> >> - return -1;
> >> - }
> >> + if (buf->mgr->base.is_buffer_busy)
> >> + if (buf->mgr->base.is_buffer_busy(&buf->mgr->base, buf->buffer))
> >> + return -1;
> >
> > Oops, this is wrong. I will locally replace any occurences of
> > "buf->mgr->base(.)" with "buf->mgr->provider(->)", which is how it was meant
> > to be, but the idea remains the same. Please review.
Marek, I don't understand what you want to do here: you removed the
pb_map, but you left the pb_unmap, and what will happen if
is_buffer_busy is not defined?
>
> I actually suggested this originally, but Jose I think preferred using
> the dontblock to the buffer mapping.
I'd prefer that there is one way of doing this, but I didn't/don't feel
strong about this. IMO, having two ways, PB_USAGE_DONTBLOCK and
is_buffer_busy, is not cleaner that just PB_USAGE_DONTBLOCK, even if
is_buffer_busy is conceptually cleaner.
Marek, Would adding an inline function, pb_is_buffer_busy, that calls
pb_map(PB_USAGE_DONTBLOCK)+pb_unmap inside work for you?
Another way, would be to add is_buffer_busy and have the default
implementation to do pb_map/pb_unmap.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Fix RGB10_A2 format handling
This patch fixes the fbo/fbo-clear-formats piglit test. As PIPE_FORMAT_B10G10R10A2_UNORM is the only format the mesa state tracker uses, this is the only format I actualy tested. From 27238ed21d3f2d7a6912531ca9f01d508cf76931 Mon Sep 17 00:00:00 2001 From: Fabian Bieler Date: Thu, 10 Feb 2011 16:57:34 +0100 Subject: [PATCH 2/6] r600g: Fix RGB10_A2 format handling --- src/gallium/drivers/r600/r600_state_inlines.h |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/r600/r600_state_inlines.h b/src/gallium/drivers/r600/r600_state_inlines.h index 8180515..fa6c24c 100644 --- a/src/gallium/drivers/r600/r600_state_inlines.h +++ b/src/gallium/drivers/r600/r600_state_inlines.h @@ -345,9 +345,11 @@ static inline uint32_t r600_translate_colorswap(enum pipe_format format) case PIPE_FORMAT_R10G10B10A2_UNORM: case PIPE_FORMAT_R10G10B10X2_SNORM: - case PIPE_FORMAT_B10G10R10A2_UNORM: case PIPE_FORMAT_R10SG10SB10SA2U_NORM: - return V_0280A0_SWAP_STD_REV; + return V_0280A0_SWAP_STD; + + case PIPE_FORMAT_B10G10R10A2_UNORM: + return V_0280A0_SWAP_ALT; case PIPE_FORMAT_R16G16_UNORM: return V_0280A0_SWAP_STD; @@ -422,7 +424,7 @@ static INLINE uint32_t r600_translate_colorformat(enum pipe_format format) case PIPE_FORMAT_R10G10B10X2_SNORM: case PIPE_FORMAT_B10G10R10A2_UNORM: case PIPE_FORMAT_R10SG10SB10SA2U_NORM: - return V_0280A0_COLOR_10_10_10_2; + return V_0280A0_COLOR_2_10_10_10; case PIPE_FORMAT_Z24X8_UNORM: case PIPE_FORMAT_Z24_UNORM_S8_USCALED: -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: Use blend equation and function of first render target for all render targets if ARB_draw_buffers_blend is not supported
This patch fixes the fbo/fbo-drawbuffers2-blend piglit test.
From 92d78e485ced85378404ea68e9050de6d9f6639b Mon Sep 17 00:00:00 2001
From: Fabian Bieler
Date: Thu, 10 Feb 2011 16:45:41 +0100
Subject: [PATCH 1/6] st/mesa: Use blend equation and function of first render target for all render targets if ARB_draw_buffers_blend is not supported
If EXT_draw_buffers2 is supported but ARB_draw_buffers_blend isn't
_mesa_BlendFuncSeparateEXT only sets up the blend equation and function for the
first render target. This patch makes sure that update_blend doesn't try to use
the data from other rendertargets in such cases.
---
src/mesa/state_tracker/st_atom_blend.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_blend.c b/src/mesa/state_tracker/st_atom_blend.c
index 8a3609e..fb1c7a4 100644
--- a/src/mesa/state_tracker/st_atom_blend.c
+++ b/src/mesa/state_tracker/st_atom_blend.c
@@ -191,7 +191,7 @@ update_blend( struct st_context *st )
{
struct pipe_blend_state *blend = &st->state.blend;
unsigned num_state = 1;
- unsigned i;
+ unsigned i, j;
memset(blend, 0, sizeof(*blend));
@@ -214,12 +214,15 @@ update_blend( struct st_context *st )
}
else if (st->ctx->Color.BlendEnabled) {
/* blending enabled */
- for (i = 0; i < num_state; i++) {
+ for (i = 0, j = 0; i < num_state; i++) {
blend->rt[i].blend_enable = (st->ctx->Color.BlendEnabled >> i) & 0x1;
+ if (st->ctx->Extensions.ARB_draw_buffers_blend)
+j = i;
+
blend->rt[i].rgb_func =
-translate_blend(st->ctx->Color.Blend[i].EquationRGB);
+translate_blend(st->ctx->Color.Blend[j].EquationRGB);
if (st->ctx->Color.Blend[i].EquationRGB == GL_MIN ||
st->ctx->Color.Blend[i].EquationRGB == GL_MAX) {
@@ -229,13 +232,13 @@ update_blend( struct st_context *st )
}
else {
blend->rt[i].rgb_src_factor =
- translate_blend(st->ctx->Color.Blend[i].SrcRGB);
+ translate_blend(st->ctx->Color.Blend[j].SrcRGB);
blend->rt[i].rgb_dst_factor =
- translate_blend(st->ctx->Color.Blend[i].DstRGB);
+ translate_blend(st->ctx->Color.Blend[j].DstRGB);
}
blend->rt[i].alpha_func =
-translate_blend(st->ctx->Color.Blend[i].EquationA);
+translate_blend(st->ctx->Color.Blend[j].EquationA);
if (st->ctx->Color.Blend[i].EquationA == GL_MIN ||
st->ctx->Color.Blend[i].EquationA == GL_MAX) {
@@ -245,9 +248,9 @@ update_blend( struct st_context *st )
}
else {
blend->rt[i].alpha_src_factor =
- translate_blend(st->ctx->Color.Blend[i].SrcA);
+ translate_blend(st->ctx->Color.Blend[j].SrcA);
blend->rt[i].alpha_dst_factor =
- translate_blend(st->ctx->Color.Blend[i].DstA);
+ translate_blend(st->ctx->Color.Blend[j].DstA);
}
}
}
--
1.7.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 34261] New: Buildsystem disables openvg when disabling gallium egl
https://bugs.freedesktop.org/show_bug.cgi?id=34261 Summary: Buildsystem disables openvg when disabling gallium egl Product: Mesa Version: 7.10 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: hicham.haou...@gmail.com On Fedora, gallium egl is disabled since it breaks wayland AFAIK, but that forces openvg to be disabled also. Is there any chance to fix this ? Ie, make openvg build even if gallium egl is disabled. -- 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 34259] gallium: transfers should use z/depth and not y/height for 1d array textures as layer parameter
https://bugs.freedesktop.org/show_bug.cgi?id=34259 Roland Scheidegger changed: What|Removed |Added Summary|gallium: transfers should |gallium: transfers should |not use z/depth and not |use z/depth and not |y/height for 1d array |y/height for 1d array |textures as layer parameter |textures as layer parameter -- 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 34259] New: gallium: transfers should not use z/depth and not y/height for 1d array textures as layer parameter
https://bugs.freedesktop.org/show_bug.cgi?id=34259 Summary: gallium: transfers should not use z/depth and not y/height for 1d array textures as layer parameter Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: srol...@vmware.com Currently, gallium is using gl-style y/height for the layer parameter for 1d array textures in pipe transfers (that is, it is using the next "unused" parameter, which is y for 1d array, and z for 2d array textures). This was never meant to be that way but not properly documented. It should always use z/depth for layer parameter, regardless if it's a 1d or 2d array texture. Conceptually, it is a different parameter, which is just basically merged with z/depth since 3d arrays don't exist. -- 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] Building Mesa 7.10 on Windows 7 / Visual Studio 2010
On Fri, Feb 11, 2011 at 11:31 AM, Yahya H. Mirza wrote: > Hi All, > > > > I’ve been trying to build Mesa 7.10 on Windows 7 / Visual Studio 2010 and I > have been having some problems. > > > > When I opened > > \windows\VC8\mesa\mesa.sln, it was automatically converted to VS2010. > > > > When I tried to build the various projects there were a number of problems > including a number of misconfigured build directories. > > > > Additionally, when building the mesa project in VS2010, it has trouble > finding a path for building “predefined shaders”. > > > > Finally, the “glsl_apps_compile” project seems to be out of date. > > > > Is there an updated version of this solution file for Mesa7.10 / VS2010, or > has anyone successfully built Mesa7.10 with CMAKE? > > > > Any suggestions on successfully building Mesa7.10 for Windows7 / VS2010 > would be greatly appreciated. The MSVC project files for Mesa haven't been maintained in a while. They'll be removed in the next Mesa release. Instead, take a look at the instructions for building with scons. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Mesa/Gallium vertex array state optimizations
On Sun, 2011-02-13 at 22:04 +0100, Marek Olšák wrote:
> Keith,
>
> Yes, they will. If vertex buffers are not re-set in st_draw_vbo,
> redefine_user_buffer is called for each user buffer which is set and that
> tells a driver which buffer ranges need to be re-uploaded. This can be found
> in the last hunk of the last patch, specifically:
OK, thanks for clarifying Marek. I think the patches look great.
> @@ -646,6 +664,26 @@ st_draw_vbo(struct gl_context *ctx,
> #endif
>}
>
> + /* Notify the driver that the content of user buffers may have been
> +* changed. */
> + if (!new_array && st->num_user_vbs) {
> + for (i = 0; i < st->num_user_vbs; i++) {
> + if (st->user_vb[i]) {
> +unsigned stride = st->user_vb_stride[i];
> +
> +if (stride) {
> + pipe->redefine_user_buffer(pipe, st->user_vb[i],
> + min_index * stride,
> + (max_index + 1 - min_index) *
> stride);
> +} else {
> + /* stride == 0 */
> + pipe->redefine_user_buffer(pipe, st->user_vb[i],
> + 0, st->user_vb[i]->width0);
> +}
> + }
> + }
> + }
> +
>setup_index_buffer(ctx, ib, &ibuffer);
>pipe->set_index_buffer(pipe, &ibuffer);
>
> What remains to implement is using this information in drivers to re-upload
> the buffer ranges marked with redefine_user_buffer. r300g, r600g, some
> nouveau drivers, and anything which uses Draw do not need this information,
> so they are safe. I think the only driver which needs special handling is
> svga, but I don't know that driver so well to be able to do it.
I know svga is getting a bit of attention at the moment, so this might
be something they may want to pick up.
Keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
