Re: [Mesa-dev] Gallium pixel formats on big-endian
On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote: - Original Message - On Mit, 2013-01-30 at 06:12 -0800, Jose Fonseca wrote: - Original Message - On Mon, 2013-01-28 at 06:56 -0500, Adam Jackson wrote: I've been looking at untangling the pixel format code for big-endian. My current theory is that blindly byte-swapping values is just wrong. Certainly. :) I think you're discovering that this hasn't really been thought through beyond what's necessary for things to work with little endian CPU and GPU. Any code there is for dealing with big endian CPUs has been bolted on as an afterthought. My memory is a bit fuzzy, but I thought that we decided that gallium formats were always defined in terms of little-endian, which is why all need to be byte-swapped. The state tracker was the one responsible to translate endian-neutral API formats into the non-neutral gallium ones. I know that was the suggested solution when this was discussed previously, but I'm still not really convinced that cuts it. Just for one example, last time in 864e97f3-352a-4fdb-9bb7-6d41a1969...@zimbra-prod-mbox-2.vmware.com you seemed to agree it doesn't make sense for vertex elements. I couldn't find it by id, but I think you mean: http://lists.freedesktop.org/archives/mesa-dev/2011-April/007109.html Yes, that's right. (I did say my memory was fuzzy :) Yeah, that's what I was referring to. For another example (which I suspect is more relevant for this thread), wouldn't it be nice if the software rendering drivers could directly represent the window system renderbuffer format as a Gallium format in all cases? I'm missing your point, could you give an example of where that's currently not possible? E.g. an XImage of depth 16, where the pixels are generally packed in big endian if the X server runs on a big endian machine. It's impossible to represent that with PIPE_FORMAT_*5*6*5_UNORM packed in little endian. I can't help feeling it would be better to treat endianness explicitly rather than implicitly in the format description, so drivers and state trackers could choose to use little/big/native/foreign endian formats as appropriate for the hardware and APIs they're dealing with. What you mean by explicitly vs implicitly? Do you mean r5g6b5_be, r5g6b5_le, r32g32b32a32_unorm_le, r32g32b32a32_unorm_be, etc? Yeah, something like that, with the byte order only applying within each component for array formats. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: handle unhandled PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60098 --- src/gallium/drivers/llvmpipe/lp_screen.c |1 + src/gallium/drivers/nv30/nv30_screen.c |1 + src/gallium/drivers/r300/r300_screen.c |1 + src/gallium/drivers/r600/r600_pipe.c |1 + src/gallium/drivers/radeonsi/radeonsi_pipe.c |1 + src/gallium/drivers/softpipe/sp_screen.c |2 ++ src/gallium/drivers/svga/svga_screen.c |1 + 7 files changed, 8 insertions(+) diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index 3769428..f3bc516 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -217,6 +217,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: case PIPE_CAP_CUBE_MAP_ARRAY: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; } /* should only get here on unhandled cases */ diff --git a/src/gallium/drivers/nv30/nv30_screen.c b/src/gallium/drivers/nv30/nv30_screen.c index f3faf8a..d30ae11 100644 --- a/src/gallium/drivers/nv30/nv30_screen.c +++ b/src/gallium/drivers/nv30/nv30_screen.c @@ -120,6 +120,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_MULTISAMPLE: case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY: case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY: diff --git a/src/gallium/drivers/r300/r300_screen.c b/src/gallium/drivers/r300/r300_screen.c index d0f0070..5a249ae 100644 --- a/src/gallium/drivers/r300/r300_screen.c +++ b/src/gallium/drivers/r300/r300_screen.c @@ -155,6 +155,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_MULTISAMPLE: case PIPE_CAP_CUBE_MAP_ARRAY: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: +case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; /* SWTCL-only features. */ diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index a59578d..c0dab9d 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -564,6 +564,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_FRAGMENT_COLOR_CLAMPED: case PIPE_CAP_VERTEX_COLOR_CLAMPED: case PIPE_CAP_USER_VERTEX_BUFFERS: + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c b/src/gallium/drivers/radeonsi/radeonsi_pipe.c index 471dd48..98f72eb 100644 --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c @@ -355,6 +355,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_QUERY_TIMESTAMP: case PIPE_CAP_CUBE_MAP_ARRAY: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/softpipe/sp_screen.c b/src/gallium/drivers/softpipe/sp_screen.c index af40261..16aba5a 100644 --- a/src/gallium/drivers/softpipe/sp_screen.c +++ b/src/gallium/drivers/softpipe/sp_screen.c @@ -171,6 +171,8 @@ softpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) return 1; case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: return 1; + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: + return 0; } /* should only get here on unhandled cases */ debug_printf(Unexpected PIPE_CAP %d query\n, param); diff --git a/src/gallium/drivers/svga/svga_screen.c b/src/gallium/drivers/svga/svga_screen.c index c6f0343..c2492f9 100644 --- a/src/gallium/drivers/svga/svga_screen.c +++ b/src/gallium/drivers/svga/svga_screen.c @@ -256,6 +256,7 @@ svga_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: case PIPE_CAP_CUBE_MAP_ARRAY: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY: return 1; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Regading OpenGLES2 on Linux
Hi,
Thanks for your reply. We are working with mesa-8.0.4 on Ubuntu 12.04 and
compiling the mesa with following options(hardware rendering enabled) and found
that there is no Winsys is enabled for radeon/drm and it has only SW
winsys. After this we took mesa-9.0.1 and configured and found radeon/drm is
enabled, but compilation is not successful with the error attached. Our
intention is compile mesa with opengles2 only with gallium driver(R600) and run
es2 demo program which are in mesa-demos.
Mesa-8.0.4 :
root@amd-desktop:/home/amd/Downloads/testtrails/mesa-mesa-8.0.4#
./configure --prefix=/opt/xorg2 --enable-shared-glapi
--with-gallium-drivers=r600 --enable-gles2 --enable-debug --disable-opengl
prefix: /opt/xorg2
exec_prefix: ${prefix}
libdir: ${exec_prefix}/lib
includedir: ${prefix}/include
OpenGL: no (ES1: no ES2: yes)
OpenVG: no
OSMesa: no
GLX: no
GLU: no
EGL: yes
EGL platforms: x11
EGL drivers:
llvm:no
Gallium: yes
Gallium dirs:auxiliary drivers state_trackers
Target dirs:
Winsys dirs: sw
Driver dirs: galahad identity noop r600 rbug trace
Trackers dirs:
Shared libs: yes
Static libs: no
CFLAGS: -g -O2 -Wall -Wmissing-prototypes -std=c99
-fno-strict-aliasing -fno-builtin-memcmp -g -fPIC
CXXFLAGS:-g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp
-g -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN
-DHAVE_MINCORE -DHAVE_LIBUDEV -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM
-DUSE_SSE_ASM
PYTHON2: python2
Run 'make' to build Mesa
Mesa-9.0.1:
root@amd-desktop:/home/amd/Downloads/testtrails/mesa-mesa-9.0.1#
./configure --prefix=/opt/xorg2 --enable-shared-glapi
--with-gallium-drivers=r600 --enable-gles2 --enable-debug --disable-opengl
prefix: /opt/xorg2
exec_prefix: ${prefix}
libdir: ${exec_prefix}/lib
includedir: ${prefix}/include
OpenGL: no (ES1: no ES2: yes)
OpenVG: no
OSMesa: no
DRI drivers: no
DRI driver dir: ${libdir}/dri
GLX: DRI-based
EGL: yes
EGL platforms: x11
EGL drivers: builtin:egl_glx builtin:egl_dri2
llvm:no
Gallium: yes
Gallium dirs:auxiliary drivers state_trackers
Target dirs: dri-r600
Winsys dirs: radeon/drm sw sw/dri
Driver dirs: galahad identity noop r600 rbug trace
Trackers dirs: dri
Shared libs: yes
Static libs: no
Shared-glapi:yes
CFLAGS: -g -O2 -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-strict-aliasing -fno-builtin-memcmp -g -fPIC
CXXFLAGS:-g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp
-g -fPIC
Macros: -D_GNU_SOURCE -DHAVE_PTHREAD -DDEBUG -DUSE_X86_ASM
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN
-DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE
-DHAVE_LIBUDEV
PYTHON2: python2
Run 'make' to build Mesa
Compilation error in mesa-9.0.1:
Making all in .
make[4]: Entering directory
`/home/amd/Downloads/testtrails/mesa-mesa-9.0.1/src/mesa'
CC api_arrayelt.lo
CC api_exec.lo
../../src/mesa/main/api_exec.c: In function '_mesa_create_exec_table':
../../src/mesa/main/api_exec.c:132:4: warning: passing argument 1 of
'_mesa_loopback_init_api_table' from incompatible pointer type [enabled by
default]
../../src/mesa/main/api_loopback.h:44:1: note: expected 'struct _glapi_table *'
but argument is of type 'struct gl_context *'
../../src/mesa/main/api_exec.c:132:4: error: too many arguments to function
'_mesa_loopback_init_api_table'
../../src/mesa/main/api_loopback.h:44:1: note: declared here
../../src/mesa/main/api_exec.c:525:40: error: '_mesa_GetVertexAttribPointervNV'
undeclared (first use in this function)
../../src/mesa/main/api_exec.c:525:40: note: each undeclared identifier is
reported only once for each function it appears in
make[4]: *** [api_exec.lo] Error 1
Can you please let us know whether we can build the mesa for only opengles2
without opengl ? (--disable-opengles2 and –disable-opengl), and if it is how
to build mesa for opengles2 only. And I have looked at :
http://mesa3d.org/opengles.html and in this they mentioned –enable-opengles2
and –enable-opengles2
Re: [Mesa-dev] Gallium pixel formats on big-endian
- Original Message - On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote: - Original Message - On Mit, 2013-01-30 at 06:12 -0800, Jose Fonseca wrote: - Original Message - On Mon, 2013-01-28 at 06:56 -0500, Adam Jackson wrote: I've been looking at untangling the pixel format code for big-endian. My current theory is that blindly byte-swapping values is just wrong. Certainly. :) I think you're discovering that this hasn't really been thought through beyond what's necessary for things to work with little endian CPU and GPU. Any code there is for dealing with big endian CPUs has been bolted on as an afterthought. My memory is a bit fuzzy, but I thought that we decided that gallium formats were always defined in terms of little-endian, which is why all need to be byte-swapped. The state tracker was the one responsible to translate endian-neutral API formats into the non-neutral gallium ones. I know that was the suggested solution when this was discussed previously, but I'm still not really convinced that cuts it. Just for one example, last time in 864e97f3-352a-4fdb-9bb7-6d41a1969...@zimbra-prod-mbox-2.vmware.com you seemed to agree it doesn't make sense for vertex elements. I couldn't find it by id, but I think you mean: http://lists.freedesktop.org/archives/mesa-dev/2011-April/007109.html Yes, that's right. (I did say my memory was fuzzy :) Yeah, that's what I was referring to. For another example (which I suspect is more relevant for this thread), wouldn't it be nice if the software rendering drivers could directly represent the window system renderbuffer format as a Gallium format in all cases? I'm missing your point, could you give an example of where that's currently not possible? E.g. an XImage of depth 16, where the pixels are generally packed in big endian if the X server runs on a big endian machine. It's impossible to represent that with PIPE_FORMAT_*5*6*5_UNORM packed in little endian. I see. Is this something that could be worked around? I can't help feeling it would be better to treat endianness explicitly rather than implicitly in the format description, so drivers and state trackers could choose to use little/big/native/foreign endian formats as appropriate for the hardware and APIs they're dealing with. What you mean by explicitly vs implicitly? Do you mean r5g6b5_be, r5g6b5_le, r32g32b32a32_unorm_le, r32g32b32a32_unorm_be, etc? Yeah, something like that, with the byte order only applying within each component for array formats. I don't oppose that. But it does seem a lot of work. How would hardware drivers handle this? Specially those that have a single LE/BE bit to choose? (BTW, I do believe we should unify Mesa format handling and Gallium's u_format module into a shared external helper library for formats before we venture into that though as the effort of doing that would pretty much double. I think it is also worth considering the other extreme: all formats are expected to be LE on LE platforms, BE on BE platforms. Is this feasible, or are there APIs that need (i.e, require) to handle both LE/BE formats? (Or hardware only capable of LE formats?) If not, would it be feasible to byte-swap at state tracker level? In short, in order to support BE platforms properly, there will be some pain regardless the approach we take. I really don't feel strongly about any approach -- just want a level of pain we (ie. the whole community) can sustain. Because if the right thing is onerous and few care I suspect this will quickly rot or never get completed. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glapi: Do not use backtrace on MinGW.
Looks good. Though I wonder why I didn't see build failures here. What sort of error did you get? Jose - Original Message - execinfo.h is not available on MinGW. Signed-off-by: Vinson Lee v...@freedesktop.org --- src/mapi/glapi/gen/gl_gentable.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mapi/glapi/gen/gl_gentable.py b/src/mapi/glapi/gen/gl_gentable.py index a00c9c2..a3c9898 100644 --- a/src/mapi/glapi/gen/gl_gentable.py +++ b/src/mapi/glapi/gen/gl_gentable.py @@ -42,7 +42,7 @@ header = /* GLXEXT is the define used in the xserver when the GLX extension i #endif #if (defined(GLXEXT) defined(HAVE_BACKTRACE)) \\ - || (!defined(GLXEXT) defined(DEBUG) !defined(_WIN32_WCE) !defined(__CYGWIN__)) + || (!defined(GLXEXT) defined(DEBUG) !defined(_WIN32_WCE) !defined(__CYGWIN__) !defined(__MINGW32__)) #define USE_BACKTRACE #endif -- 1.8.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Regading OpenGLES2 on Linux
On Don, 2013-01-31 at 09:29 +, Ramesh Reddy Emmadi wrote: OpenGL: no (ES1: no ES2: yes) [...] make[4]: Entering directory `/home/amd/Downloads/testtrails/mesa-mesa-9.0.1/src/mesa' CC api_arrayelt.lo CC api_exec.lo ../../src/mesa/main/api_exec.c: In function '_mesa_create_exec_table': ../../src/mesa/main/api_exec.c:132:4: warning: passing argument 1 of '_mesa_loopback_init_api_table' from incompatible pointer type [enabled by default] ../../src/mesa/main/api_loopback.h:44:1: note: expected 'struct _glapi_table *' but argument is of type 'struct gl_context *' ../../src/mesa/main/api_exec.c:132:4: error: too many arguments to function '_mesa_loopback_init_api_table' ../../src/mesa/main/api_loopback.h:44:1: note: declared here ../../src/mesa/main/api_exec.c:525:40: error: '_mesa_GetVertexAttribPointervNV' undeclared (first use in this function) ../../src/mesa/main/api_exec.c:525:40: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [api_exec.lo] Error 1 Can you please let us know whether we can build the mesa for only opengles2 without opengl ? (--disable-opengles2 and –disable-opengl), and if it is how to build mesa for opengles2 only. Does it help if you add --enable-gallium-egl and/or --with-dri-drivers'' to the configure arguments? If not, I'm afraid your findings indicate GLES2 without OpenGL doesn't work with 8.0 or 9.0. FWIW though, I just tried it with current Git master, and it seems to work fine. And I have looked at : http://mesa3d.org/opengles.html and in this they mentioned –enable-opengles2 and –enable-opengles2 for Gallium driver hardware. To work with gallium driver is it required both opengles1 and opengles2? No, enabling only opengles2 seems to work fine. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: Disable GLX if OpenGL is not enabled
From: Michel Dänzer michel.daen...@amd.com GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL. Signed-off-by: Michel Dänzer michel.daen...@amd.com --- configure.ac |8 1 file changed, 8 insertions(+) diff --git a/configure.ac b/configure.ac index cfd52bf..62cc32b 100644 --- a/configure.ac +++ b/configure.ac @@ -701,6 +701,14 @@ if test x$enable_dri$enable_xlib_glx = xyesyes; then AC_MSG_ERROR([DRI and Xlib-GLX cannot be built together]) fi +# Disable GLX if OpenGL is not enabled +if test x$enable_glx = xyes -a \ +x$enable_opengl = xno; then +AC_MSG_WARN([OpenGL not enabled, disabling GLX]) +enable_glx=no +enable_xlib_glx=no +fi + # Disable GLX if DRI and Xlib-GLX are not enabled if test x$enable_glx = xyes -a \ x$enable_dri = xno -a \ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium pixel formats on big-endian
On 31.01.2013 09:30, Michel Dänzer wrote: On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote: - Original Message - On Mit, 2013-01-30 at 06:12 -0800, Jose Fonseca wrote: - Original Message - On Mon, 2013-01-28 at 06:56 -0500, Adam Jackson wrote: I've been looking at untangling the pixel format code for big-endian. My current theory is that blindly byte-swapping values is just wrong. Certainly. :) I think you're discovering that this hasn't really been thought through beyond what's necessary for things to work with little endian CPU and GPU. Any code there is for dealing with big endian CPUs has been bolted on as an afterthought. My memory is a bit fuzzy, but I thought that we decided that gallium formats were always defined in terms of little-endian, which is why all need to be byte-swapped. The state tracker was the one responsible to translate endian-neutral API formats into the non-neutral gallium ones. I know that was the suggested solution when this was discussed previously, but I'm still not really convinced that cuts it. Just for one example, last time in 864e97f3-352a-4fdb-9bb7-6d41a1969...@zimbra-prod-mbox-2.vmware.com you seemed to agree it doesn't make sense for vertex elements. I couldn't find it by id, but I think you mean: http://lists.freedesktop.org/archives/mesa-dev/2011-April/007109.html Yes, that's right. (I did say my memory was fuzzy :) Yeah, that's what I was referring to. For another example (which I suspect is more relevant for this thread), wouldn't it be nice if the software rendering drivers could directly represent the window system renderbuffer format as a Gallium format in all cases? I'm missing your point, could you give an example of where that's currently not possible? E.g. an XImage of depth 16, where the pixels are generally packed in big endian if the X server runs on a big endian machine. It's impossible to represent that with PIPE_FORMAT_*5*6*5_UNORM packed in little endian. I can't help feeling it would be better to treat endianness explicitly rather than implicitly in the format description, so drivers and state trackers could choose to use little/big/native/foreign endian formats as appropriate for the hardware and APIs they're dealing with. What you mean by explicitly vs implicitly? Do you mean r5g6b5_be, r5g6b5_le, r32g32b32a32_unorm_le, r32g32b32a32_unorm_be, etc? Yeah, something like that, with the byte order only applying within each component for array formats. It's a bit tricky, formats with 16 and 32 bpc seem to already have these components ordered in the host byte order (if the GPU endianness switch is set to that). At least I think that has to be the case because we certainly don't bswap all the vertex data and things work, and that suggests it affects colours, too, or using vertex buffers as textures wouldn't work. Formats like B8G8R8A8_UNORM or R5G6B5_UNORM might be treated as a word by the GPU (not sure, I don't have a BE machine), and thus byte order could differ between BE and LE. So RGBA32_UNORM_LE/BE doesn't seem useful (or at least not usable, since the endian switch usually isn't per RT/texture/vertex buffer/...), and RGBA8_LE/BE would be confusing, because we have the rule (*) that the component written to the left resides at a lower address. What would RGBA8_BE be ? R at lowest address on BE and A at lowest address on LE ? Just use ABGR8 on LE then. Otoh, adding G3B5R5G3 (the bswapped version of R5G6B5) would look a bit awkward, but would be correct gallium terminology on BE if the format is treated as a 16 bit word. That's probably why they started the inconsistent naming we had in gallium in the past in the first place. Maybe we should just define some formats as affected by endianness, because G3B5R5G3 certainly won't be supported if GPU is set to LE. But then the rule (*) has to be stated with respect to a specific endianness. Let me think about that some more ... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 59851] AC_ARG_WITH misusage leading to mesa configure failure
https://bugs.freedesktop.org/show_bug.cgi?id=59851 Quentin Glidic sardemff7+freedesk...@sardemff7.net changed: What|Removed |Added Attachment #73648|0 |1 is obsolete|| --- Comment #2 from Quentin Glidic sardemff7+freedesk...@sardemff7.net --- Created attachment 73992 -- https://bugs.freedesktop.org/attachment.cgi?id=73992action=edit Patch to fix mesa configure Patch fixed and with a different logic. Now force-enable LLVM shared libraries in a post-check, with a warning for the user. -- 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] Regading OpenGLES2 on Linux
Hi Michel, Thanks for your info. Got the error1 while compiling mesa-8.0.4 with the following configuration options and commented the _mesa_BindBufferBase function in src/mesa/main/bufferobj.c file. After this change able to compile the code successfully, but while make install got one more error(error2). Can you please let us know, is there any thing wrong in the configuration and also any changes required for code to compile with --enable-gles2 only (without opengl and opengles1). if opengles2 only work without opengl and openles2, we want to know whether mesa-demos opengles2 folder will compile without any issues? or any code changes required to compile the es2 demos? for X11. ./autogen.sh --prefix=/opt/xorg2 --with-gallium-drivers=r600 --enable-gles2 --enable-debug --with-dri-drivers --with-egl-platforms=x11,drm --disable-opengl --enable-gallium-egl --enable-dri --enable-shared-glapi Error 1: imklib: Making Linux shared library: r600_dri.so.tmp g++ -I/opt/xorg/include -g -O2 -Wall -Wmissing-prototypes -std=c99 -fno-strict-aliasing -fno-builtin-memcmp -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -fvisibility=hidden -o r600_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp ../../../../src/mesa/libmesa.a -L/opt/xorg/lib -ldrm -lexpat -lm -lpthread -ldl -L/opt/xorg/lib; r600_dri.so.tmp: undefined reference to `_mesa_BindBufferBase' collect2: ld returned 1 exit status make[3]: *** [r600_dri.so] Error 1 make[3]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src/gallium/targets/dri-r600' make[2]: *** [default] Error 1 make[2]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src/gallium/targets' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src' make: *** [default] Error 1 root@amd-desktop:/home/amd/Downloads/mesa-mesa-8.0.4# Error 2: /usr/bin/install -c -d /opt/xorg2/include/GL /usr/bin/install -c -m 644 ../../include/GL/*.h \ /opt/xorg2/include/GL /usr/bin/install -c -d /opt/xorg2/lib /usr/bin/install -c -d /opt/xorg2/lib/pkgconfig /bin/bash ../../bin/minstall ../../lib/libGL.*so* \ /opt/xorg2/lib Unknown type of argument: ../../lib/libGL.*so* make[3]: *** [install-libgl] Error 1 make[3]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src/mesa' make[2]: *** [install] Error 1 make[2]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src/mesa' make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src' make: *** [install] Error 1 Thanks in advance. Thanks and Regards, Ramesh From: Michel Dänzer [mic...@daenzer.net] Sent: Thursday, January 31, 2013 3:53 PM To: Ramesh Reddy Emmadi Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] Regading OpenGLES2 on Linux On Don, 2013-01-31 at 09:29 +, Ramesh Reddy Emmadi wrote: OpenGL: no (ES1: no ES2: yes) [...] make[4]: Entering directory `/home/amd/Downloads/testtrails/mesa-mesa-9.0.1/src/mesa' CC api_arrayelt.lo CC api_exec.lo ../../src/mesa/main/api_exec.c: In function '_mesa_create_exec_table': ../../src/mesa/main/api_exec.c:132:4: warning: passing argument 1 of '_mesa_loopback_init_api_table' from incompatible pointer type [enabled by default] ../../src/mesa/main/api_loopback.h:44:1: note: expected 'struct _glapi_table *' but argument is of type 'struct gl_context *' ../../src/mesa/main/api_exec.c:132:4: error: too many arguments to function '_mesa_loopback_init_api_table' ../../src/mesa/main/api_loopback.h:44:1: note: declared here ../../src/mesa/main/api_exec.c:525:40: error: '_mesa_GetVertexAttribPointervNV' undeclared (first use in this function) ../../src/mesa/main/api_exec.c:525:40: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [api_exec.lo] Error 1 Can you please let us know whether we can build the mesa for only opengles2 without opengl ? (--disable-opengles2 and –disable-opengl), and if it is how to build mesa for opengles2 only. Does it help if you add --enable-gallium-egl and/or --with-dri-drivers'' to the configure arguments? If not, I'm afraid your findings indicate GLES2 without OpenGL doesn't work with 8.0 or 9.0. FWIW though, I just tried it with current Git master, and it seems to work fine. And I have looked at : http://mesa3d.org/opengles.html and in this they mentioned –enable-opengles2 and –enable-opengles2 for Gallium driver hardware. To work with gallium driver is it required both opengles1 and opengles2? No, enabling only opengles2 seems to work fine. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast
[Mesa-dev] [Bug 59851] AC_ARG_WITH misusage leading to mesa configure failure
https://bugs.freedesktop.org/show_bug.cgi?id=59851 --- Comment #3 from Tom Stellard tstel...@gmail.com --- (In reply to comment #2) Created attachment 73992 [details] [review] Patch to fix mesa configure Patch fixed and with a different logic. Now force-enable LLVM shared libraries in a post-check, with a warning for the user. Thanks for the patch, it looks good to me, but I need to test it out on a few configurations before I push it. -- 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] compiling mesa-8.0.4 with opengles2 only
Hi, Got the error1 while compiling mesa-8.0.4 with the following configuration options and commented the _mesa_BindBufferBase function in src/mesa/main/bufferobj.c file. After this change able to compile the code successfully, but while make install got one more error(error2). Can you please let us know, is there any thing wrong in the configuration and also any changes required for code to compile with --enable-gles2 only (without opengl and opengles1). if opengles2 only work without opengl and openles2, we want to know whether mesa-demos opengles2 folder will compile without any issues? or any code changes required to compile the es2 demos? for X11. ./autogen.sh --prefix=/opt/xorg2 --with-gallium-drivers=r600 --enable-gles2 --enable-debug --with-dri-drivers --with-egl-platforms=x11,drm --disable-opengl --enable-gallium-egl --enable-dri --enable-shared-glapi Error 1: imklib: Making Linux shared library: r600_dri.so.tmp g++ -I/opt/xorg/include -g -O2 -Wall -Wmissing-prototypes -std=c99 -fno-strict-aliasing -fno-builtin-memcmp -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -fvisibility=hidden -o r600_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp ../../../../src/mesa/libmesa.a -L/opt/xorg/lib -ldrm -lexpat -lm -lpthread -ldl -L/opt/xorg/lib; r600_dri.so.tmp: undefined reference to `_mesa_BindBufferBase' collect2: ld returned 1 exit status make[3]: *** [r600_dri.so] Error 1 make[3]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src/gallium/targets/dri-r600' make[2]: *** [default] Error 1 make[2]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src/gallium/targets' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src' make: *** [default] Error 1 root@amd-desktop:/home/amd/Downloads/mesa-mesa-8.0.4# Error 2: /usr/bin/install -c -d /opt/xorg2/include/GL /usr/bin/install -c -m 644 ../../include/GL/*.h \ /opt/xorg2/include/GL /usr/bin/install -c -d /opt/xorg2/lib /usr/bin/install -c -d /opt/xorg2/lib/pkgconfig /bin/bash ../../bin/minstall ../../lib/libGL.*so* \ /opt/xorg2/lib Unknown type of argument: ../../lib/libGL.*so* make[3]: *** [install-libgl] Error 1 make[3]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src/mesa' make[2]: *** [install] Error 1 make[2]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src/mesa' make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/amd/Downloads/mesa-mesa-8.0.4/src' make: *** [install] Error 1 Thanks in advance. Thanks and Regards, Ramesh CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium pixel formats on big-endian
On Don, 2013-01-31 at 02:14 -0800, Jose Fonseca wrote: - Original Message - On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote: - Original Message - For another example (which I suspect is more relevant for this thread), wouldn't it be nice if the software rendering drivers could directly represent the window system renderbuffer format as a Gallium format in all cases? I'm missing your point, could you give an example of where that's currently not possible? E.g. an XImage of depth 16, where the pixels are generally packed in big endian if the X server runs on a big endian machine. It's impossible to represent that with PIPE_FORMAT_*5*6*5_UNORM packed in little endian. I see. Is this something that could be worked around? Basically anything can be worked around somehow, right? :) But in this example, it seems like it would require some kind of sideband information to specify that PIPE_FORMAT_*5*6*5_UNORM actually has the reversed byte order now, and some layer of the stack to use that and swap the bytes accordingly. So, extra copies and an extra information channel (and possibly a layering violation). I can't help feeling it would be better to treat endianness explicitly rather than implicitly in the format description, so drivers and state trackers could choose to use little/big/native/foreign endian formats as appropriate for the hardware and APIs they're dealing with. What you mean by explicitly vs implicitly? Do you mean r5g6b5_be, r5g6b5_le, r32g32b32a32_unorm_le, r32g32b32a32_unorm_be, etc? Yeah, something like that, with the byte order only applying within each component for array formats. I don't oppose that. But it does seem a lot of work. I'm afraid so. How would hardware drivers handle this? Specially those that have a single LE/BE bit to choose? I guess drivers would advertise the formats they can and want to support given the hardware capabilities and target platforms. For drivers which only have to worry about little endian environments, basically nothing should change except for the format names and maybe other similar details. (BTW, I do believe we should unify Mesa format handling and Gallium's u_format module into a shared external helper library for formats before we venture into that though as the effort of doing that would pretty much double. That might be a good idea. The Mesa format code seems to have grown some warts of its own anyway. I think it is also worth considering the other extreme: all formats are expected to be LE on LE platforms, BE on BE platforms. Right. I think that might be preferable over LE always, if we decide not to support both LE/BE explicitly. Is this feasible, or are there APIs that need (i.e, require) to handle both LE/BE formats? Not sure, but my impression has been that APIs tend to prefer the CPU native byte order. Anything else makes little sense from an application POV. Still, I wouldn't be surprised if there were exceptions, e.g. with image/video APIs related to fixed file formats. (Or hardware only capable of LE formats?) Unfortunately, our Southern Islands GPUs no longer have facilities for byte-swapping vertex / texture data on the fly. If not, would it be feasible to byte-swap at state tracker level? That should certainly be feasible for texture data, as that generally involves at least one copy anyway. However, it might hurt for streaming vertex data. Also, we might have to be careful not to require double byte-swapping in cases where simple copies would work or no copies would be necessary in the first place. In short, in order to support BE platforms properly, there will be some pain regardless the approach we take. I really don't feel strongly about any approach -- just want a level of pain we (ie. the whole community) can sustain. Because if the right thing is onerous and few care I suspect this will quickly rot or never get completed. I agree. I'm hoping that dealing with byte order more explicitly will make it less likely to be ignored. But I'm not pretending to know what the best solution is. I'm mainly trying to raise awareness of the issues. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 60121] New: build - libvdpau_softpipe fails at runtime.
https://bugs.freedesktop.org/show_bug.cgi?id=60121 Priority: medium Bug ID: 60121 Assignee: mesa-dev@lists.freedesktop.org Summary: build - libvdpau_softpipe fails at runtime. Severity: normal Classification: Unclassified OS: All Reporter: li...@andyfurniss.entadsl.com Hardware: Other Status: NEW Version: git Component: Other Product: Mesa I think this is related to the new build system but can't be sure. Using VDPAU_DRIVER=r600 works fine but VDPAU_DRIVER=softpipe fails with - libvdpau_softpipe.so: cannot open shared object file: No such file or directory The lib is built and present, though. -rwxr-xr-x 1 root root 1.8K Jan 31 13:01 libvdpau_softpipe.la lrwxrwxrwx 1 root root 26 Jan 31 13:01 libvdpau_softpipe.so - libvdpau_softpipe.so.1.0.0 lrwxrwxrwx 1 root root 26 Jan 31 13:01 libvdpau_softpipe.so.1 - libvdpau_softpipe.so.1.0.0 -rwxr-xr-x 1 root root 27M Dec 19 23:28 libvdpau_softpipe.so.1.0 -rwxr-xr-x 1 root root 30M Jan 31 13:01 libvdpau_softpipe.so.1.0.0 As you can see due to the change of name I still have an old pre automake version of the driver. If I change the links to point to that the above command works. Looking at old and new with ldd the only difference (apart from ../) is that the new lib has libdrm.so.2 whereas the old doesn't. andy [ ~ ]$ ldd /usr/lib/vdpau/libvdpau_softpipe.so.1.0.0 | sort libc.so.6 = /lib/libc.so.6 (0x7f7faa1f) libdl.so.2 = /lib/libdl.so.2 (0x7f7faab8a000) libdrm.so.2 = /usr/lib/../lib/libdrm.so.2 (0x7f7fab1be000) libgcc_s.so.1 = /usr/lib/../lib/libgcc_s.so.1 (0x7f7fa9fdb000) /lib/ld-linux-x86-64.so.2 (0x7f7fadc49000) libm.so.6 = /lib/libm.so.6 (0x7f7faa596000) libpthread.so.0 = /lib/libpthread.so.0 (0x7f7faad8f000) librt.so.1 = /lib/librt.so.1 (0x7f7faafab000) libstdc++.so.6 = /usr/lib/../lib/libstdc++.so.6 (0x7f7faa88c000) libvdpau.so.1 = /usr/lib/../lib/libvdpau.so.1 (0x7f7fac343000) libX11.so.6 = /usr/lib/../lib/libX11.so.6 (0x7f7fabbf6000) libX11-xcb.so.1 = /usr/lib/../lib/libX11-xcb.so.1 (0x7f7fabf3) libXau.so.6 = /usr/lib/../lib/libXau.so.6 (0x7f7fab5d) libxcb-dri2.so.0 = /usr/lib/../lib/libxcb-dri2.so.0 (0x7f7fab9f2000) libxcb.so.1 = /usr/lib/../lib/libxcb.so.1 (0x7f7fab7d3000) libXdmcp.so.6 = /usr/lib/../lib/libXdmcp.so.6 (0x7f7fab3cb000) libXext.so.6 = /usr/lib/../lib/libXext.so.6 (0x7f7fac132000) linux-vdso.so.1 (0x7fff4193f000) andy [ ~ ]$ andy [ ~ ]$ andy [ ~ ]$ ldd /usr/lib/vdpau/libvdpau_softpipe.so.1.0 | sort libc.so.6 = /lib/libc.so.6 (0x7fb749e68000) libdl.so.2 = /lib/libdl.so.2 (0x7fb74b229000) libgcc_s.so.1 = /usr/lib/libgcc_s.so.1 (0x7fb74a20d000) /lib/ld-linux-x86-64.so.2 (0x7fb74cb33000) libm.so.6 = /lib/libm.so.6 (0x7fb74a929000) libpthread.so.0 = /lib/libpthread.so.0 (0x7fb74b42d000) librt.so.1 = /lib/librt.so.1 (0x7fb74a721000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fb74a423000) libvdpau.so.1 = /usr/lib/libvdpau.so.1 (0x7fb74b025000) libX11.so.6 = /usr/lib/libX11.so.6 (0x7fb74991c000) libX11-xcb.so.1 = /usr/lib/libX11-xcb.so.1 (0x7fb74ae24000) libXau.so.6 = /usr/lib/libXau.so.6 (0x7fb7494fb000) libxcb-dri2.so.0 = /usr/lib/libxcb-dri2.so.0 (0x7fb74ac2) libxcb.so.1 = /usr/lib/libxcb.so.1 (0x7fb7496fe000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x7fb7492f5000) libXext.so.6 = /usr/lib/libXext.so.6 (0x7fb749c57000) linux-vdso.so.1 (0x7fff6d452000) -- 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] Regading OpenGLES2 on Linux
On Don, 2013-01-31 at 14:01 +, Ramesh Reddy Emmadi wrote: Got the error1 while compiling mesa-8.0.4 with the following configuration options and commented the _mesa_BindBufferBase function in src/mesa/main/bufferobj.c file. After this change able to compile the code successfully, but while make install got one more error(error2). Does --disable-glx help for the second error? Can you please let us know, is there any thing wrong in the configuration Can't see anything wrong with it. and also any changes required for code to compile with --enable-gles2 only (without opengl and opengles1). All I can say is that I didn't hit your first error with current Git. I assume it would be the same on the 9.1 branch. It should be possible to isolate how it was fixed, e.g. with git bisect, and it might be possible to backport the fix to the 8.0 branch. if opengles2 only work without opengl and openles2, we want to know whether mesa-demos opengles2 folder will compile without any issues? or any code changes required to compile the es2 demos? for X11. None of this should matter for the compilation of the demos. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium pixel formats on big-endian
- Original Message - On Don, 2013-01-31 at 02:14 -0800, Jose Fonseca wrote: - Original Message - On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote: - Original Message - For another example (which I suspect is more relevant for this thread), wouldn't it be nice if the software rendering drivers could directly represent the window system renderbuffer format as a Gallium format in all cases? I'm missing your point, could you give an example of where that's currently not possible? E.g. an XImage of depth 16, where the pixels are generally packed in big endian if the X server runs on a big endian machine. It's impossible to represent that with PIPE_FORMAT_*5*6*5_UNORM packed in little endian. I see. Is this something that could be worked around? Basically anything can be worked around somehow, right? :) I meant in a satisfactory manner. But in this example, it seems like it would require some kind of sideband information to specify that PIPE_FORMAT_*5*6*5_UNORM actually has the reversed byte order now, and some layer of the stack to use that and swap the bytes accordingly. So, extra copies and an extra information channel (and possibly a layering violation). I was thinking more around blacklisting non RGBX8 visuals on the X server in BE platforms when GLX is enabled for this hardware. I mean, is it worth it to even support it? I can't help feeling it would be better to treat endianness explicitly rather than implicitly in the format description, so drivers and state trackers could choose to use little/big/native/foreign endian formats as appropriate for the hardware and APIs they're dealing with. What you mean by explicitly vs implicitly? Do you mean r5g6b5_be, r5g6b5_le, r32g32b32a32_unorm_le, r32g32b32a32_unorm_be, etc? Yeah, something like that, with the byte order only applying within each component for array formats. I don't oppose that. But it does seem a lot of work. I'm afraid so. How would hardware drivers handle this? Specially those that have a single LE/BE bit to choose? I guess drivers would advertise the formats they can and want to support given the hardware capabilities and target platforms. For drivers which only have to worry about little endian environments, basically nothing should change except for the format names and maybe other similar details. (BTW, I do believe we should unify Mesa format handling and Gallium's u_format module into a shared external helper library for formats before we venture into that though as the effort of doing that would pretty much double. That might be a good idea. The Mesa format code seems to have grown some warts of its own anyway. I think it is also worth considering the other extreme: all formats are expected to be LE on LE platforms, BE on BE platforms. Right. I think that might be preferable over LE always, if we decide not to support both LE/BE explicitly. Is this feasible, or are there APIs that need (i.e, require) to handle both LE/BE formats? Not sure, but my impression has been that APIs tend to prefer the CPU native byte order. Anything else makes little sense from an application POV. Still, I wouldn't be surprised if there were exceptions, e.g. with image/video APIs related to fixed file formats. (Or hardware only capable of LE formats?) Unfortunately, our Southern Islands GPUs no longer have facilities for byte-swapping vertex / texture data on the fly. If not, would it be feasible to byte-swap at state tracker level? That should certainly be feasible for texture data, as that generally involves at least one copy anyway. However, it might hurt for streaming vertex data. Also, we might have to be careful not to require double byte-swapping in cases where simple copies would work or no copies would be necessary in the first place. In short, in order to support BE platforms properly, there will be some pain regardless the approach we take. I really don't feel strongly about any approach -- just want a level of pain we (ie. the whole community) can sustain. Because if the right thing is onerous and few care I suspect this will quickly rot or never get completed. I agree. I'm hoping that dealing with byte order more explicitly will make it less likely to be ignored. But I'm not pretending to know what the best solution is. I'm mainly trying to raise awareness of the issues. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Disable GLX if OpenGL is not enabled
On Thu, Jan 31, 2013 at 11:50:46AM +0100, Michel Dänzer wrote: From: Michel Dänzer michel.daen...@amd.com GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL. This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=59364 Tested-by: Tom Stellard thomas.stell...@amd.com Signed-off-by: Michel Dänzer michel.daen...@amd.com --- configure.ac |8 1 file changed, 8 insertions(+) diff --git a/configure.ac b/configure.ac index cfd52bf..62cc32b 100644 --- a/configure.ac +++ b/configure.ac @@ -701,6 +701,14 @@ if test x$enable_dri$enable_xlib_glx = xyesyes; then AC_MSG_ERROR([DRI and Xlib-GLX cannot be built together]) fi +# Disable GLX if OpenGL is not enabled +if test x$enable_glx = xyes -a \ +x$enable_opengl = xno; then +AC_MSG_WARN([OpenGL not enabled, disabling GLX]) +enable_glx=no +enable_xlib_glx=no +fi + # Disable GLX if DRI and Xlib-GLX are not enabled if test x$enable_glx = xyes -a \ x$enable_dri = xno -a \ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Disable GLX if OpenGL is not enabled
On Jan 31, 2013 2:51 AM, Michel Dänzer mic...@daenzer.net wrote: From: Michel Dänzer michel.daen...@amd.com GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL. Signed-off-by: Michel Dänzer michel.daen...@amd.com --- configure.ac |8 1 file changed, 8 insertions(+) diff --git a/configure.ac b/configure.ac index cfd52bf..62cc32b 100644 --- a/configure.ac +++ b/configure.ac @@ -701,6 +701,14 @@ if test x$enable_dri$enable_xlib_glx = xyesyes; then AC_MSG_ERROR([DRI and Xlib-GLX cannot be built together]) fi +# Disable GLX if OpenGL is not enabled +if test x$enable_glx = xyes -a \ +x$enable_opengl = xno; then +AC_MSG_WARN([OpenGL not enabled, disabling GLX]) +enable_glx=no +enable_xlib_glx=no +fi Seems correct. I might prefer this to error, but warn is probably good enough. The option to disable opengl didn't exist back when these checks were written. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: handle unhandled PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT
On 01/31/2013 01:35 AM, Andreas Boll wrote: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60098 --- src/gallium/drivers/llvmpipe/lp_screen.c |1 + src/gallium/drivers/nv30/nv30_screen.c |1 + src/gallium/drivers/r300/r300_screen.c |1 + src/gallium/drivers/r600/r600_pipe.c |1 + src/gallium/drivers/radeonsi/radeonsi_pipe.c |1 + src/gallium/drivers/softpipe/sp_screen.c |2 ++ src/gallium/drivers/svga/svga_screen.c |1 + 7 files changed, 8 insertions(+) diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index 3769428..f3bc516 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -217,6 +217,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: case PIPE_CAP_CUBE_MAP_ARRAY: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; } /* should only get here on unhandled cases */ diff --git a/src/gallium/drivers/nv30/nv30_screen.c b/src/gallium/drivers/nv30/nv30_screen.c index f3faf8a..d30ae11 100644 --- a/src/gallium/drivers/nv30/nv30_screen.c +++ b/src/gallium/drivers/nv30/nv30_screen.c @@ -120,6 +120,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_MULTISAMPLE: case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY: case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY: diff --git a/src/gallium/drivers/r300/r300_screen.c b/src/gallium/drivers/r300/r300_screen.c index d0f0070..5a249ae 100644 --- a/src/gallium/drivers/r300/r300_screen.c +++ b/src/gallium/drivers/r300/r300_screen.c @@ -155,6 +155,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_MULTISAMPLE: case PIPE_CAP_CUBE_MAP_ARRAY: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: +case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; /* SWTCL-only features. */ diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index a59578d..c0dab9d 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -564,6 +564,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_FRAGMENT_COLOR_CLAMPED: case PIPE_CAP_VERTEX_COLOR_CLAMPED: case PIPE_CAP_USER_VERTEX_BUFFERS: + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c b/src/gallium/drivers/radeonsi/radeonsi_pipe.c index 471dd48..98f72eb 100644 --- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c +++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c @@ -355,6 +355,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_QUERY_TIMESTAMP: case PIPE_CAP_CUBE_MAP_ARRAY: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; /* Stream output. */ diff --git a/src/gallium/drivers/softpipe/sp_screen.c b/src/gallium/drivers/softpipe/sp_screen.c index af40261..16aba5a 100644 --- a/src/gallium/drivers/softpipe/sp_screen.c +++ b/src/gallium/drivers/softpipe/sp_screen.c @@ -171,6 +171,8 @@ softpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) return 1; case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: return 1; + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: + return 0; } /* should only get here on unhandled cases */ debug_printf(Unexpected PIPE_CAP %d query\n, param); diff --git a/src/gallium/drivers/svga/svga_screen.c b/src/gallium/drivers/svga/svga_screen.c index c6f0343..c2492f9 100644 --- a/src/gallium/drivers/svga/svga_screen.c +++ b/src/gallium/drivers/svga/svga_screen.c @@ -256,6 +256,7 @@ svga_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: case PIPE_CAP_CUBE_MAP_ARRAY: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: + case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: return 0; case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY: return 1; Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium pixel formats on big-endian
- Original Message - On Don, 2013-01-31 at 02:14 -0800, Jose Fonseca wrote: - Original Message - On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote: - Original Message - For another example (which I suspect is more relevant for this thread), wouldn't it be nice if the software rendering drivers could directly represent the window system renderbuffer format as a Gallium format in all cases? I'm missing your point, could you give an example of where that's currently not possible? E.g. an XImage of depth 16, where the pixels are generally packed in big endian if the X server runs on a big endian machine. It's impossible to represent that with PIPE_FORMAT_*5*6*5_UNORM packed in little endian. I see. Is this something that could be worked around? Basically anything can be worked around somehow, right? :) But in this example, it seems like it would require some kind of sideband information to specify that PIPE_FORMAT_*5*6*5_UNORM actually has the reversed byte order now, and some layer of the stack to use that and swap the bytes accordingly. So, extra copies and an extra information channel (and possibly a layering violation). I can't help feeling it would be better to treat endianness explicitly rather than implicitly in the format description, so drivers and state trackers could choose to use little/big/native/foreign endian formats as appropriate for the hardware and APIs they're dealing with. What you mean by explicitly vs implicitly? Do you mean r5g6b5_be, r5g6b5_le, r32g32b32a32_unorm_le, r32g32b32a32_unorm_be, etc? Yeah, something like that, with the byte order only applying within each component for array formats. I don't oppose that. But it does seem a lot of work. I'm afraid so. How would hardware drivers handle this? Specially those that have a single LE/BE bit to choose? I guess drivers would advertise the formats they can and want to support given the hardware capabilities and target platforms. For drivers which only have to worry about little endian environments, basically nothing should change except for the format names and maybe other similar details. (BTW, I do believe we should unify Mesa format handling and Gallium's u_format module into a shared external helper library for formats before we venture into that though as the effort of doing that would pretty much double. That might be a good idea. The Mesa format code seems to have grown some warts of its own anyway. I think it is also worth considering the other extreme: all formats are expected to be LE on LE platforms, BE on BE platforms. Right. I think that might be preferable over LE always, if we decide not to support both LE/BE explicitly. Is this feasible, or are there APIs that need (i.e, require) to handle both LE/BE formats? Not sure, but my impression has been that APIs tend to prefer the CPU native byte order. Anything else makes little sense from an application POV. Still, I wouldn't be surprised if there were exceptions, e.g. with image/video APIs related to fixed file formats. I'm not an expert on video, but the if video formats are exceptional we could treat them exceptionally (e.g., they are always defined in LE). I also suspect that certain compressed formats like DXTn are always defined in LE terms. (Or hardware only capable of LE formats?) Unfortunately, our Southern Islands GPUs no longer have facilities for byte-swapping vertex / texture data on the fly. Hmm.. forcing such drivers to byte-swap internally is a tall order (it would be easier if state trackers could do it for all such hardware), so this kills the gallium == native idea... If not, would it be feasible to byte-swap at state tracker level? That should certainly be feasible for texture data, as that generally involves at least one copy anyway. However, it might hurt for streaming vertex data. Also, we might have to be careful not to require double byte-swapping in cases where simple copies would work or no copies would be necessary in the first place. We could consider a PIPE_CAP_BYTE_ORDER, with two values: NATIVE, or LE. Drivers for hardware with LE/BE would advertise NATIVE and implement it trivially. For drivers with LE hardware, the state tracker would be responsible for byteswapping when platform is BE (or just invert swizzles for RG8/RGBA8 formats). (With exception of eventual video/compressed formats which are only defined on a given ). State trackers would also disable user pointers and always create VBOs/IBOs. Byteswapping can be done in a fairly generic way independent of the format -- one just needs to know the swap unit (1,2,4, or 8 bytes) for the format, and strides. That is, we could have an helper
Re: [Mesa-dev] Gallium pixel formats on big-endian
On Thu, Jan 31, 2013 at 9:34 AM, Michel Dänzer mic...@daenzer.net wrote: On Don, 2013-01-31 at 02:14 -0800, Jose Fonseca wrote: - Original Message - On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote: - Original Message - For another example (which I suspect is more relevant for this thread), wouldn't it be nice if the software rendering drivers could directly represent the window system renderbuffer format as a Gallium format in all cases? I'm missing your point, could you give an example of where that's currently not possible? E.g. an XImage of depth 16, where the pixels are generally packed in big endian if the X server runs on a big endian machine. It's impossible to represent that with PIPE_FORMAT_*5*6*5_UNORM packed in little endian. I see. Is this something that could be worked around? Basically anything can be worked around somehow, right? :) But in this example, it seems like it would require some kind of sideband information to specify that PIPE_FORMAT_*5*6*5_UNORM actually has the reversed byte order now, and some layer of the stack to use that and swap the bytes accordingly. So, extra copies and an extra information channel (and possibly a layering violation). I can't help feeling it would be better to treat endianness explicitly rather than implicitly in the format description, so drivers and state trackers could choose to use little/big/native/foreign endian formats as appropriate for the hardware and APIs they're dealing with. What you mean by explicitly vs implicitly? Do you mean r5g6b5_be, r5g6b5_le, r32g32b32a32_unorm_le, r32g32b32a32_unorm_be, etc? Yeah, something like that, with the byte order only applying within each component for array formats. I don't oppose that. But it does seem a lot of work. I'm afraid so. How would hardware drivers handle this? Specially those that have a single LE/BE bit to choose? I guess drivers would advertise the formats they can and want to support given the hardware capabilities and target platforms. For drivers which only have to worry about little endian environments, basically nothing should change except for the format names and maybe other similar details. (BTW, I do believe we should unify Mesa format handling and Gallium's u_format module into a shared external helper library for formats before we venture into that though as the effort of doing that would pretty much double. That might be a good idea. The Mesa format code seems to have grown some warts of its own anyway. I think it is also worth considering the other extreme: all formats are expected to be LE on LE platforms, BE on BE platforms. Right. I think that might be preferable over LE always, if we decide not to support both LE/BE explicitly. Is this feasible, or are there APIs that need (i.e, require) to handle both LE/BE formats? Not sure, but my impression has been that APIs tend to prefer the CPU native byte order. Anything else makes little sense from an application POV. Still, I wouldn't be surprised if there were exceptions, e.g. with image/video APIs related to fixed file formats. (Or hardware only capable of LE formats?) Unfortunately, our Southern Islands GPUs no longer have facilities for byte-swapping vertex / texture data on the fly. The DMA engine still supports endian swaps so if we used that for uploads like r600g now does, we could use the facilities there. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: add cs memory usage accounting and limit it
On Wed, Jan 30, 2013 at 10:35 PM, Marek Olšák mar...@gmail.com wrote:
On Wed, Jan 30, 2013 at 6:14 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
We are now seing cs that can go over the vram+gtt size to avoid
failing flush early cs that goes over 70% (gtt+vram) usage. 70%
is use to allow some fragmentation.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c| 4
src/gallium/drivers/r600/r600.h | 1 +
src/gallium/drivers/r600/r600_buffer.c| 1 +
src/gallium/drivers/r600/r600_hw_context.c| 12
src/gallium/drivers/r600/r600_pipe.c | 3 +++
src/gallium/drivers/r600/r600_pipe.h | 21 +
src/gallium/drivers/r600/r600_state.c | 3 +++
src/gallium/drivers/r600/r600_state_common.c | 17 -
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 11 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 10 ++
10 files changed, 82 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index be1c427..84f8dce 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1668,6 +1668,8 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
surf = (struct r600_surface*)state-cbufs[i];
rtex = (struct r600_texture*)surf-base.texture;
+ r600_context_add_resource_size(ctx,
state-cbufs[i]-texture);
+
if (!surf-color_initialized) {
evergreen_init_color_surface(rctx, surf);
}
@@ -1699,6 +1701,8 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
if (state-zsbuf) {
surf = (struct r600_surface*)state-zsbuf;
+ r600_context_add_resource_size(ctx, state-zsbuf-texture);
+
if (!surf-depth_initialized) {
evergreen_init_depth_surface(rctx, surf);
}
diff --git a/src/gallium/drivers/r600/r600.h
b/src/gallium/drivers/r600/r600.h
index a383c90..b9f7d3d 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -50,6 +50,7 @@ struct r600_resource {
/* Resource state. */
unsigneddomains;
+ uint64_tsize;
Don't add this. Use r600_resource::buf::size instead, which is already
initialized.
};
#define R600_BLOCK_MAX_BO 32
diff --git a/src/gallium/drivers/r600/r600_buffer.c
b/src/gallium/drivers/r600/r600_buffer.c
index 6df0d91..92f549a 100644
--- a/src/gallium/drivers/r600/r600_buffer.c
+++ b/src/gallium/drivers/r600/r600_buffer.c
@@ -250,6 +250,7 @@ bool r600_init_resource(struct r600_screen *rscreen,
break;
}
+ res-size = size;
res-buf = rscreen-ws-buffer_create(rscreen-ws, size, alignment,
use_reusable_pool,
initial_domain);
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index ebafd97..44d3b4d 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -359,6 +359,16 @@ out_err:
void r600_need_cs_space(struct r600_context *ctx, unsigned num_dw,
boolean count_draw_in)
{
+ if (!ctx-ws-cs_memory_below_limit(ctx-rings.gfx.cs, ctx-vram,
ctx-gtt)) {
+ ctx-gtt = 0;
+ ctx-vram = 0;
+ ctx-rings.gfx.flush(ctx, RADEON_FLUSH_ASYNC);
+ return;
+ }
+ /* all will be accounted once relocation are emited */
+ ctx-gtt = 0;
+ ctx-vram = 0;
+
/* The number of dwords we already used in the CS so far. */
num_dw += ctx-rings.gfx.cs-cdw;
@@ -784,6 +794,8 @@ void r600_begin_new_cs(struct r600_context *ctx)
ctx-pm4_dirty_cdwords = 0;
ctx-flags = 0;
+ ctx-gtt = 0;
+ ctx-vram = 0;
/* Begin a new CS. */
r600_emit_command_buffer(ctx-rings.gfx.cs, ctx-start_cs_cmd);
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index a59578d..cb50cfe 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -333,6 +333,9 @@ static struct pipe_context *r600_create_context(struct
pipe_screen *screen, void
rctx-chip_class = rscreen-chip_class;
rctx-keep_tiling_flags = rscreen-info.drm_minor = 12;
+ rctx-gtt = 0;
+ rctx-vram = 0;
There is no reason to initialize anything to 0 in context_create. The
whole context structure is calloc'd.
+
LIST_INITHEAD(rctx-active_nontimer_queries);
[Mesa-dev] [PATCH] r600g: add cs memory usage accounting and limit it v2
From: Jerome Glisse jgli...@redhat.com
We are now seing cs that can go over the vram+gtt size to avoid
failing flush early cs that goes over 70% (gtt+vram) usage. 70%
is use to allow some fragmentation.
The idea is to compute a gross estimate of memory requirement of
each draw call. After each draw call, memory will be precisely
accounted. So the uncertainty is only on the current draw call.
In practice this gave very good estimate (+/- 10% of the target
memory limit).
v2: Remove left over from testing version, remove useless NULL
checking. Improve commit message.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c| 4
src/gallium/drivers/r600/r600_hw_context.c| 12
src/gallium/drivers/r600/r600_pipe.h | 21 +
src/gallium/drivers/r600/r600_state.c | 3 +++
src/gallium/drivers/r600/r600_state_common.c | 13 -
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 11 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 10 ++
7 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 0a3861f..5dd8b13 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1668,6 +1668,8 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
surf = (struct r600_surface*)state-cbufs[i];
rtex = (struct r600_texture*)surf-base.texture;
+ r600_context_add_resource_size(ctx, state-cbufs[i]-texture);
+
if (!surf-color_initialized) {
evergreen_init_color_surface(rctx, surf);
}
@@ -1699,6 +1701,8 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
if (state-zsbuf) {
surf = (struct r600_surface*)state-zsbuf;
+ r600_context_add_resource_size(ctx, state-zsbuf-texture);
+
if (!surf-depth_initialized) {
evergreen_init_depth_surface(rctx, surf);
}
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 23f488a..a89f230 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -359,6 +359,16 @@ out_err:
void r600_need_cs_space(struct r600_context *ctx, unsigned num_dw,
boolean count_draw_in)
{
+ if (!ctx-ws-cs_memory_below_limit(ctx-rings.gfx.cs, ctx-vram,
ctx-gtt)) {
+ ctx-gtt = 0;
+ ctx-vram = 0;
+ ctx-rings.gfx.flush(ctx, RADEON_FLUSH_ASYNC);
+ return;
+ }
+ /* all will be accounted once relocation are emited */
+ ctx-gtt = 0;
+ ctx-vram = 0;
+
/* The number of dwords we already used in the CS so far. */
num_dw += ctx-rings.gfx.cs-cdw;
@@ -784,6 +794,8 @@ void r600_begin_new_cs(struct r600_context *ctx)
ctx-pm4_dirty_cdwords = 0;
ctx-flags = 0;
+ ctx-gtt = 0;
+ ctx-vram = 0;
/* Begin a new CS. */
r600_emit_command_buffer(ctx-rings.gfx.cs, ctx-start_cs_cmd);
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 3ff42d3..42b4e7c 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -447,6 +447,10 @@ struct r600_context {
unsignedbackend_mask;
unsignedmax_db; /* for OQ */
+ /* current unaccounted memory usage */
+ uint64_tvram;
+ uint64_tgtt;
+
/* Miscellaneous state objects. */
void*custom_dsa_flush;
void*custom_blend_resolve;
@@ -998,4 +1002,21 @@ static INLINE unsigned u_max_layer(struct pipe_resource
*r, unsigned level)
}
}
+static INLINE void r600_context_add_resource_size(struct pipe_context *ctx,
struct pipe_resource *r)
+{
+ struct r600_context *rctx = (struct r600_context *)ctx;
+ struct r600_resource *rr = (struct r600_resource *)r;
+
+ if (r == NULL) {
+ return;
+ }
+
+ if (rr-domains RADEON_DOMAIN_GTT) {
+ rctx-gtt += rr-buf-size;
+ }
+ if (rr-domains RADEON_DOMAIN_VRAM) {
+ rctx-vram += rr-buf-size;
+ }
+}
+
#endif
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index c0bc2a5..44cd00e 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -1544,6 +1544,7 @@ static void r600_set_framebuffer_state(struct
pipe_context *ctx,
surf = (struct r600_surface*)state-cbufs[i];
rtex = (struct r600_texture*)surf-base.texture;
+
[Mesa-dev] [PATCH 1/3] trace: allow GALLIUM_TRACE=stdout/stderr
---
src/gallium/drivers/trace/tr_dump.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/trace/tr_dump.c
b/src/gallium/drivers/trace/tr_dump.c
index 90befb0..0714e9a 100644
--- a/src/gallium/drivers/trace/tr_dump.c
+++ b/src/gallium/drivers/trace/tr_dump.c
@@ -244,9 +244,17 @@ boolean trace_dump_trace_begin()
if(!stream) {
- stream = fopen(filename, wt);
- if(!stream)
- return FALSE;
+ if (strcmp(filename, stderr) == 0) {
+ stream = stderr;
+ }
+ else if (strcmp(filename, stdout) == 0) {
+ stream = stdout;
+ }
+ else {
+ stream = fopen(filename, wt);
+ if (!stream)
+return FALSE;
+ }
trace_dump_writes(?xml version='1.0' encoding='UTF-8'?\n);
trace_dump_writes(?xml-stylesheet type='text/xsl'
href='trace.xsl'?\n);
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] trace: add void to function definition
---
src/gallium/drivers/trace/tr_dump.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/trace/tr_dump.c
b/src/gallium/drivers/trace/tr_dump.c
index 0714e9a..cd106af 100644
--- a/src/gallium/drivers/trace/tr_dump.c
+++ b/src/gallium/drivers/trace/tr_dump.c
@@ -234,7 +234,8 @@ trace_dump_trace_close(void)
}
}
-boolean trace_dump_trace_begin()
+boolean
+trace_dump_trace_begin(void)
{
const char *filename;
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] trace: measure time for each gallium call
To get a rough idea of how much time is spent in each gallium driver
function. The time is measured in microseconds.
---
src/gallium/drivers/trace/tr_dump.c | 24
src/gallium/tools/trace/model.py|7 +--
src/gallium/tools/trace/parse.py| 11 ++-
3 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/trace/tr_dump.c
b/src/gallium/drivers/trace/tr_dump.c
index cd106af..48c8914 100644
--- a/src/gallium/drivers/trace/tr_dump.c
+++ b/src/gallium/drivers/trace/tr_dump.c
@@ -45,6 +45,7 @@
#include pipe/p_compiler.h
#include os/os_thread.h
+#include os/os_time.h
#include util/u_debug.h
#include util/u_memory.h
#include util/u_string.h
@@ -234,6 +235,20 @@ trace_dump_trace_close(void)
}
}
+
+static void
+trace_dump_call_time(int64_t time)
+{
+ if (stream) {
+ trace_dump_indent(2);
+ trace_dump_tag_begin(time);
+ trace_dump_int(time);
+ trace_dump_tag_end(time);
+ trace_dump_newline();
+ }
+}
+
+
boolean
trace_dump_trace_begin(void)
{
@@ -345,6 +360,8 @@ boolean trace_dumping_enabled(void)
* Dump functions
*/
+static int64_t call_start_time = 0;
+
void trace_dump_call_begin_locked(const char *klass, const char *method)
{
if (!dumping)
@@ -360,13 +377,20 @@ void trace_dump_call_begin_locked(const char *klass,
const char *method)
trace_dump_escape(method);
trace_dump_writes(\');
trace_dump_newline();
+
+ call_start_time = os_time_get();
}
void trace_dump_call_end_locked(void)
{
+ int64_t call_end_time;
+
if (!dumping)
return;
+ call_end_time = os_time_get();
+
+ trace_dump_call_time(call_end_time - call_start_time);
trace_dump_indent(1);
trace_dump_tag_end(call);
trace_dump_newline();
diff --git a/src/gallium/tools/trace/model.py b/src/gallium/tools/trace/model.py
index 9f2d5bc..8276a8f 100755
--- a/src/gallium/tools/trace/model.py
+++ b/src/gallium/tools/trace/model.py
@@ -101,12 +101,13 @@ class Pointer(Node):
class Call:
-def __init__(self, no, klass, method, args, ret):
+def __init__(self, no, klass, method, args, ret, time):
self.no = no
self.klass = klass
self.method = method
self.args = args
self.ret = ret
+self.time = time
def visit(self, visitor):
visitor.visit_call(self)
@@ -210,7 +211,9 @@ class PrettyPrinter:
if node.ret is not None:
self.formatter.text(' = ')
node.ret.visit(self)
-
+self.formatter.text(' // time ')
+node.time.visit(self)
+
def visit_trace(self, node):
for call in node.calls:
call.visit(self)
diff --git a/src/gallium/tools/trace/parse.py b/src/gallium/tools/trace/parse.py
index feb0b64..07f2d6c 100755
--- a/src/gallium/tools/trace/parse.py
+++ b/src/gallium/tools/trace/parse.py
@@ -215,6 +215,7 @@ class TraceParser(XmlParser):
method = attrs['method']
args = []
ret = None
+time = 0
while self.token.type == ELEMENT_START:
if self.token.name_or_data == 'arg':
arg = self.parse_arg()
@@ -224,11 +225,13 @@ class TraceParser(XmlParser):
elif self.token.name_or_data == 'call':
# ignore nested function calls
self.parse_call()
+elif self.token.name_or_data == 'time':
+time = self.parse_time()
else:
raise TokenMismatch(arg ... or ret ..., self.token)
self.element_end('call')
-return Call(no, klass, method, args, ret)
+return Call(no, klass, method, args, ret, time)
def parse_arg(self):
attrs = self.element_start('arg')
@@ -245,6 +248,12 @@ class TraceParser(XmlParser):
return value
+def parse_time(self):
+attrs = self.element_start('time')
+time = self.parse_value();
+self.element_end('time')
+return time
+
def parse_value(self):
expected_tokens = ('null', 'bool', 'int', 'uint', 'float', 'string',
'enum', 'array', 'struct', 'ptr', 'bytes')
if self.token.type == ELEMENT_START:
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Disable GLX if OpenGL is not enabled
2013/1/31 Michel Dänzer mic...@daenzer.net: From: Michel Dänzer michel.daen...@amd.com GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL. NOTE: This is a candidate for the stable branches. Reviewed-by: Andreas Boll andreas.boll@gmail.com Signed-off-by: Michel Dänzer michel.daen...@amd.com --- configure.ac |8 1 file changed, 8 insertions(+) diff --git a/configure.ac b/configure.ac index cfd52bf..62cc32b 100644 --- a/configure.ac +++ b/configure.ac @@ -701,6 +701,14 @@ if test x$enable_dri$enable_xlib_glx = xyesyes; then AC_MSG_ERROR([DRI and Xlib-GLX cannot be built together]) fi +# Disable GLX if OpenGL is not enabled +if test x$enable_glx = xyes -a \ +x$enable_opengl = xno; then +AC_MSG_WARN([OpenGL not enabled, disabling GLX]) +enable_glx=no +enable_xlib_glx=no +fi + # Disable GLX if DRI and Xlib-GLX are not enabled if test x$enable_glx = xyes -a \ x$enable_dri = xno -a \ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] trace: allow GALLIUM_TRACE=stdout/stderr
On Don, 2013-01-31 at 08:41 -0700, Brian Paul wrote:
---
src/gallium/drivers/trace/tr_dump.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/trace/tr_dump.c
b/src/gallium/drivers/trace/tr_dump.c
index 90befb0..0714e9a 100644
--- a/src/gallium/drivers/trace/tr_dump.c
+++ b/src/gallium/drivers/trace/tr_dump.c
@@ -244,9 +244,17 @@ boolean trace_dump_trace_begin()
if(!stream) {
- stream = fopen(filename, wt);
- if(!stream)
- return FALSE;
+ if (strcmp(filename, stderr) == 0) {
+ stream = stderr;
+ }
+ else if (strcmp(filename, stdout) == 0) {
+ stream = stdout;
+ }
+ else {
+ stream = fopen(filename, wt);
+ if (!stream)
+return FALSE;
+ }
What if one wants to trace to a file called 'stdout' or 'stderr'? :)
Slightly more seriously, I have /dev/std{out,err} files for the purpose
of this patch, but I suppose those probably aren't available everywhere
this code can run...
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] trace: allow GALLIUM_TRACE=stdout/stderr
I haven't got patch 3/3 but 1-2 look good. Below is a good idea.
(Of course, if would be even nicer if we redirected output to
src/gallium/tools/trace/dump.py via pipe/fdopen but that's quite hard to do in
a cross platform fashion)
- Original Message -
---
src/gallium/drivers/trace/tr_dump.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/trace/tr_dump.c
b/src/gallium/drivers/trace/tr_dump.c
index 90befb0..0714e9a 100644
--- a/src/gallium/drivers/trace/tr_dump.c
+++ b/src/gallium/drivers/trace/tr_dump.c
@@ -244,9 +244,17 @@ boolean trace_dump_trace_begin()
if(!stream) {
- stream = fopen(filename, wt);
- if(!stream)
- return FALSE;
+ if (strcmp(filename, stderr) == 0) {
+ stream = stderr;
+ }
+ else if (strcmp(filename, stdout) == 0) {
+ stream = stdout;
+ }
+ else {
+ stream = fopen(filename, wt);
+ if (!stream)
+return FALSE;
+ }
trace_dump_writes(?xml version='1.0' encoding='UTF-8'?\n);
trace_dump_writes(?xml-stylesheet type='text/xsl'
href='trace.xsl'?\n);
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Regarding Mesa python files
On 01/30/2013 04:16 AM, Ramesh Reddy Emmadi wrote: Hi, We are working on mesa-8.0.4 and compiling with opengles2 option and using the default glapi_gentable.c and glapitemp.h. We would like to know whether we can generate these two files for opengles2 specific . if it is please let us know the command to generate. 1) glapi_gnetable.c 2) glapitemp.h If you want OpenGL ES2, you should add these flags when you call the configure script: --enable-shared-glapi --enable-gles2. This will give Mesa support for OpenGL and OpenGL ES 2. It is not yet possible to build Mesa without OpenGL (that is, non-ES) support. The glapi dispatch tables always contain the OpenGL entries even if you don't want them. That doesn't cause any bugs, it just wastes a little bit of space. We want to fix that, but haven't had time yet. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 59967] [regression] configure: error: Could not find llvm shared libraries
https://bugs.freedesktop.org/show_bug.cgi?id=59967 --- Comment #9 from Johannes Obermayr johannesoberm...@gmx.de --- (In reply to comment #7) Johannes, I totally fail to see how your rant explains this problem at all. Michel, thanks to making me thinking on this issue a second time. First I thought it was an error because llvm-config was not found ... But it does not matter for question whether it is Mesa's problem: We can either make configure to find libs with an own compile/link function and shoot possibility to try whether it is a shared lib because $CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS $LLVM_LDFLAGS conftest.$ac_ext -l$LIB succeeds on shared and static libs and we do not know which and where $LIB was found (LLVM_LDFLAGS or compiler's default search path) to try whether it is shared or we let current implementation and fail if it doesn't work on stupid systems and preserve runtime functionality. Because I want to preserve runtime functionality I am voting for: RESOLVED / NOTOURBUG -- 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] glsl: Change loop_analysis to not look like a resource leak
On 01/30/2013 11:27 AM, Ian Romanick wrote: From: Ian Romanick ian.d.roman...@intel.com Previously the loop_state was allocated in the loop_analysis constructor, but not freed in the (nonexistent) destructor. Moving the allocation of the loop_state makes this code appear less sketchy. Either way, there is no actual leak. The loop_state is freed by the single caller of analyze_loop_variables. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Cc: Dave Airlie airl...@freedesktop.org Cc: Matt Turner matts...@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57753 --- src/glsl/loop_analysis.cpp | 13 ++--- src/glsl/loop_analysis.h | 2 +- 2 files changed, 7 insertions(+), 8 deletions(-) Oh, Coverity. This patch shouldn't matter, but it shouldn't hurt, so...meh. Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: add cs memory usage accounting and limit it
On Thu, Jan 31, 2013 at 4:29 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Wed, Jan 30, 2013 at 10:35 PM, Marek Olšák mar...@gmail.com wrote:
On Wed, Jan 30, 2013 at 6:14 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
We are now seing cs that can go over the vram+gtt size to avoid
failing flush early cs that goes over 70% (gtt+vram) usage. 70%
is use to allow some fragmentation.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c| 4
src/gallium/drivers/r600/r600.h | 1 +
src/gallium/drivers/r600/r600_buffer.c| 1 +
src/gallium/drivers/r600/r600_hw_context.c| 12
src/gallium/drivers/r600/r600_pipe.c | 3 +++
src/gallium/drivers/r600/r600_pipe.h | 21 +
src/gallium/drivers/r600/r600_state.c | 3 +++
src/gallium/drivers/r600/r600_state_common.c | 17 -
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 11 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 10 ++
10 files changed, 82 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index be1c427..84f8dce 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1668,6 +1668,8 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
surf = (struct r600_surface*)state-cbufs[i];
rtex = (struct r600_texture*)surf-base.texture;
+ r600_context_add_resource_size(ctx,
state-cbufs[i]-texture);
+
if (!surf-color_initialized) {
evergreen_init_color_surface(rctx, surf);
}
@@ -1699,6 +1701,8 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
if (state-zsbuf) {
surf = (struct r600_surface*)state-zsbuf;
+ r600_context_add_resource_size(ctx, state-zsbuf-texture);
+
if (!surf-depth_initialized) {
evergreen_init_depth_surface(rctx, surf);
}
diff --git a/src/gallium/drivers/r600/r600.h
b/src/gallium/drivers/r600/r600.h
index a383c90..b9f7d3d 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -50,6 +50,7 @@ struct r600_resource {
/* Resource state. */
unsigneddomains;
+ uint64_tsize;
Don't add this. Use r600_resource::buf::size instead, which is already
initialized.
};
#define R600_BLOCK_MAX_BO 32
diff --git a/src/gallium/drivers/r600/r600_buffer.c
b/src/gallium/drivers/r600/r600_buffer.c
index 6df0d91..92f549a 100644
--- a/src/gallium/drivers/r600/r600_buffer.c
+++ b/src/gallium/drivers/r600/r600_buffer.c
@@ -250,6 +250,7 @@ bool r600_init_resource(struct r600_screen *rscreen,
break;
}
+ res-size = size;
res-buf = rscreen-ws-buffer_create(rscreen-ws, size, alignment,
use_reusable_pool,
initial_domain);
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index ebafd97..44d3b4d 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -359,6 +359,16 @@ out_err:
void r600_need_cs_space(struct r600_context *ctx, unsigned num_dw,
boolean count_draw_in)
{
+ if (!ctx-ws-cs_memory_below_limit(ctx-rings.gfx.cs, ctx-vram,
ctx-gtt)) {
+ ctx-gtt = 0;
+ ctx-vram = 0;
+ ctx-rings.gfx.flush(ctx, RADEON_FLUSH_ASYNC);
+ return;
+ }
+ /* all will be accounted once relocation are emited */
+ ctx-gtt = 0;
+ ctx-vram = 0;
+
/* The number of dwords we already used in the CS so far. */
num_dw += ctx-rings.gfx.cs-cdw;
@@ -784,6 +794,8 @@ void r600_begin_new_cs(struct r600_context *ctx)
ctx-pm4_dirty_cdwords = 0;
ctx-flags = 0;
+ ctx-gtt = 0;
+ ctx-vram = 0;
/* Begin a new CS. */
r600_emit_command_buffer(ctx-rings.gfx.cs, ctx-start_cs_cmd);
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index a59578d..cb50cfe 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -333,6 +333,9 @@ static struct pipe_context *r600_create_context(struct
pipe_screen *screen, void
rctx-chip_class = rscreen-chip_class;
rctx-keep_tiling_flags = rscreen-info.drm_minor = 12;
+ rctx-gtt = 0;
+ rctx-vram = 0;
There is no reason to initialize anything to 0 in context_create. The
whole context structure is calloc'd.
+
Re: [Mesa-dev] [PATCH] r600g: add cs memory usage accounting and limit it v2
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Thu, Jan 31, 2013 at 4:38 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
We are now seing cs that can go over the vram+gtt size to avoid
failing flush early cs that goes over 70% (gtt+vram) usage. 70%
is use to allow some fragmentation.
The idea is to compute a gross estimate of memory requirement of
each draw call. After each draw call, memory will be precisely
accounted. So the uncertainty is only on the current draw call.
In practice this gave very good estimate (+/- 10% of the target
memory limit).
v2: Remove left over from testing version, remove useless NULL
checking. Improve commit message.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
src/gallium/drivers/r600/evergreen_state.c| 4
src/gallium/drivers/r600/r600_hw_context.c| 12
src/gallium/drivers/r600/r600_pipe.h | 21 +
src/gallium/drivers/r600/r600_state.c | 3 +++
src/gallium/drivers/r600/r600_state_common.c | 13 -
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 11 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 10 ++
7 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 0a3861f..5dd8b13 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1668,6 +1668,8 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
surf = (struct r600_surface*)state-cbufs[i];
rtex = (struct r600_texture*)surf-base.texture;
+ r600_context_add_resource_size(ctx, state-cbufs[i]-texture);
+
if (!surf-color_initialized) {
evergreen_init_color_surface(rctx, surf);
}
@@ -1699,6 +1701,8 @@ static void evergreen_set_framebuffer_state(struct
pipe_context *ctx,
if (state-zsbuf) {
surf = (struct r600_surface*)state-zsbuf;
+ r600_context_add_resource_size(ctx, state-zsbuf-texture);
+
if (!surf-depth_initialized) {
evergreen_init_depth_surface(rctx, surf);
}
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 23f488a..a89f230 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -359,6 +359,16 @@ out_err:
void r600_need_cs_space(struct r600_context *ctx, unsigned num_dw,
boolean count_draw_in)
{
+ if (!ctx-ws-cs_memory_below_limit(ctx-rings.gfx.cs, ctx-vram,
ctx-gtt)) {
+ ctx-gtt = 0;
+ ctx-vram = 0;
+ ctx-rings.gfx.flush(ctx, RADEON_FLUSH_ASYNC);
+ return;
+ }
+ /* all will be accounted once relocation are emited */
+ ctx-gtt = 0;
+ ctx-vram = 0;
+
/* The number of dwords we already used in the CS so far. */
num_dw += ctx-rings.gfx.cs-cdw;
@@ -784,6 +794,8 @@ void r600_begin_new_cs(struct r600_context *ctx)
ctx-pm4_dirty_cdwords = 0;
ctx-flags = 0;
+ ctx-gtt = 0;
+ ctx-vram = 0;
/* Begin a new CS. */
r600_emit_command_buffer(ctx-rings.gfx.cs, ctx-start_cs_cmd);
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 3ff42d3..42b4e7c 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -447,6 +447,10 @@ struct r600_context {
unsignedbackend_mask;
unsignedmax_db; /* for OQ */
+ /* current unaccounted memory usage */
+ uint64_tvram;
+ uint64_tgtt;
+
/* Miscellaneous state objects. */
void*custom_dsa_flush;
void*custom_blend_resolve;
@@ -998,4 +1002,21 @@ static INLINE unsigned u_max_layer(struct pipe_resource
*r, unsigned level)
}
}
+static INLINE void r600_context_add_resource_size(struct pipe_context *ctx,
struct pipe_resource *r)
+{
+ struct r600_context *rctx = (struct r600_context *)ctx;
+ struct r600_resource *rr = (struct r600_resource *)r;
+
+ if (r == NULL) {
+ return;
+ }
+
+ if (rr-domains RADEON_DOMAIN_GTT) {
+ rctx-gtt += rr-buf-size;
+ }
+ if (rr-domains RADEON_DOMAIN_VRAM) {
+ rctx-vram += rr-buf-size;
+ }
+}
+
#endif
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index c0bc2a5..44cd00e 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
Re: [Mesa-dev] [PATCH] mesa: adjust usage of swapBytes/littleEndian in format_matches_format_and_type
On Don, 2013-01-31 at 17:06 +0100, Marek Olšák wrote: - swapBytes has no effect on 8-bit single-component formats - GL_SHORT is in host byte order, so checking for littleEndian is unnecessary, I decided to make the change for single-component formats only Fair enough. BTW, the same is true for GL_INT. :) - for 8_8 formats, instead of littleEndian !swapBytes, use littleEndian != swapBytes to include big endian hosts Based on suggestions from Michel Dänzer. Thanks for tackling this! case MESA_FORMAT_DUDV8: return (format == GL_DU8DV8_ATI || format == GL_DUDV_ATI) - type == GL_BYTE littleEndian !swapBytes; + type == GL_BYTE littleEndian != swapBytes; [...] case MESA_FORMAT_SIGNED_RG88_REV: - return format == GL_RG type == GL_BYTE littleEndian - !swapBytes; + return format == GL_RG type == GL_BYTE littleEndian != swapBytes; [...] case MESA_FORMAT_SIGNED_AL88: return format == GL_LUMINANCE_ALPHA type == GL_BYTE - littleEndian !swapBytes; + littleEndian != swapBytes; I'm afraid these are not quite correct yet. I'm not 100% sure after looking at the red book and the GL 3.x spec — this is head spinning material, isn't it? :\ — but I think swapBytes only applies to the basic type, in these cases GL_BYTE, so it's irrelevant. However, because the Mesa formats are defined as 16 bit packed values in host byte order, these cases can only match directly on little endian hosts, i.e. if (type == GL_BYTE littleEndian). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] configure.ac: Disable GLX if OpenGL is not enabled
From: Michel Dänzer michel.daen...@amd.com GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL. NOTE: This is a candidate for the stable branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59364 Tested-by: Tom Stellard thomas.stell...@amd.com Signed-off-by: Michel Dänzer michel.daen...@amd.com --- v2: Error out on --enable-xlib-glx --disable-opengl, which is self-contradictory. configure.ac | 10 ++ 1 file changed, 10 insertions(+) diff --git a/configure.ac b/configure.ac index cfd52bf..95c9f3d 100644 --- a/configure.ac +++ b/configure.ac @@ -701,6 +701,16 @@ if test x$enable_dri$enable_xlib_glx = xyesyes; then AC_MSG_ERROR([DRI and Xlib-GLX cannot be built together]) fi +if test x$enable_opengl$enable_xlib_glx = xnoyes; then +AC_MSG_ERROR([Xlib-GLX cannot be built without OpenGL]) +fi + +# Disable GLX if OpenGL is not enabled +if test x$enable_glx$enable_opengl = xyesno; then +AC_MSG_WARN([OpenGL not enabled, disabling GLX]) +enable_glx=no +fi + # Disable GLX if DRI and Xlib-GLX are not enabled if test x$enable_glx = xyes -a \ x$enable_dri = xno -a \ -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: adjust usage of swapBytes/littleEndian in format_matches_format_and_type
On Thu, Jan 31, 2013 at 5:39 PM, Michel Dänzer mic...@daenzer.net wrote: I'm afraid these are not quite correct yet. I'm not 100% sure after looking at the red book and the GL 3.x spec — this is head spinning material, isn't it? :\ — but I think swapBytes only applies to the basic type, in these cases GL_BYTE, so it's irrelevant. However, because the Mesa formats are defined as 16 bit packed values in host byte order, these cases can only match directly on little endian hosts, i.e. if (type == GL_BYTE littleEndian). I don't really know. This is the first time I have to worry about endiannes. I discarded the modifications where we are unsure. The updated patch is here: - swapBytes has no effect on 8-bit single-component formats - GL_SHORT is in host byte order, so checking for littleEndian is unnecessary, I decided to make the change for single-component formats only Based on suggestions from Michel Dänzer. --- src/mesa/main/formats.c | 42 +- 1 file changed, 17 insertions(+), 25 deletions(-) diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c index 4598d65..68ce984 100644 --- a/src/mesa/main/formats.c +++ b/src/mesa/main/formats.c @@ -3006,19 +3006,16 @@ _mesa_format_matches_format_and_type(gl_format gl_format, case MESA_FORMAT_A8: return format == GL_ALPHA type == GL_UNSIGNED_BYTE; case MESA_FORMAT_A16: - return format == GL_ALPHA type == GL_UNSIGNED_SHORT - littleEndian !swapBytes; + return format == GL_ALPHA type == GL_UNSIGNED_SHORT !swapBytes; case MESA_FORMAT_L8: case MESA_FORMAT_SL8: return format == GL_LUMINANCE type == GL_UNSIGNED_BYTE; case MESA_FORMAT_L16: - return format == GL_LUMINANCE type == GL_UNSIGNED_SHORT - littleEndian !swapBytes; + return format == GL_LUMINANCE type == GL_UNSIGNED_SHORT !swapBytes; case MESA_FORMAT_I8: return format == GL_INTENSITY type == GL_UNSIGNED_BYTE; case MESA_FORMAT_I16: - return format == GL_INTENSITY type == GL_UNSIGNED_SHORT - littleEndian !swapBytes; + return format == GL_INTENSITY type == GL_UNSIGNED_SHORT !swapBytes; case MESA_FORMAT_YCBCR: return format == GL_YCBCR_MESA @@ -3037,7 +3034,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_R16: - return format == GL_RED type == GL_UNSIGNED_SHORT littleEndian + return format == GL_RED type == GL_UNSIGNED_SHORT !swapBytes; case MESA_FORMAT_GR1616: return format == GL_RG type == GL_UNSIGNED_SHORT littleEndian @@ -3125,8 +3122,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return format == GL_RG type == GL_HALF_FLOAT !swapBytes; case MESA_FORMAT_ALPHA_UINT8: - return format == GL_ALPHA_INTEGER type == GL_UNSIGNED_BYTE - !swapBytes; + return format == GL_ALPHA_INTEGER type == GL_UNSIGNED_BYTE; case MESA_FORMAT_ALPHA_UINT16: return format == GL_ALPHA_INTEGER type == GL_UNSIGNED_SHORT !swapBytes; @@ -3134,7 +3130,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return format == GL_ALPHA_INTEGER type == GL_UNSIGNED_INT !swapBytes; case MESA_FORMAT_ALPHA_INT8: - return format == GL_ALPHA_INTEGER type == GL_BYTE !swapBytes; + return format == GL_ALPHA_INTEGER type == GL_BYTE; case MESA_FORMAT_ALPHA_INT16: return format == GL_ALPHA_INTEGER type == GL_SHORT !swapBytes; case MESA_FORMAT_ALPHA_INT32: @@ -3150,8 +3146,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_LUMINANCE_UINT8: - return format == GL_LUMINANCE_INTEGER_EXT type == GL_UNSIGNED_BYTE - !swapBytes; + return format == GL_LUMINANCE_INTEGER_EXT type == GL_UNSIGNED_BYTE; case MESA_FORMAT_LUMINANCE_UINT16: return format == GL_LUMINANCE_INTEGER_EXT type == GL_UNSIGNED_SHORT !swapBytes; @@ -3159,8 +3154,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return format == GL_LUMINANCE_INTEGER_EXT type == GL_UNSIGNED_INT !swapBytes; case MESA_FORMAT_LUMINANCE_INT8: - return format == GL_LUMINANCE_INTEGER_EXT type == GL_BYTE - !swapBytes; + return format == GL_LUMINANCE_INTEGER_EXT type == GL_BYTE; case MESA_FORMAT_LUMINANCE_INT16: return format == GL_LUMINANCE_INTEGER_EXT type == GL_SHORT !swapBytes; @@ -3187,7 +3181,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, !swapBytes; case MESA_FORMAT_R_INT8: - return format == GL_RED_INTEGER type == GL_BYTE !swapBytes; + return format == GL_RED_INTEGER type == GL_BYTE; case MESA_FORMAT_RG_INT8: return format == GL_RG_INTEGER type == GL_BYTE !swapBytes; case MESA_FORMAT_RGB_INT8: @@ -3212,7 +3206,7 @@
[Mesa-dev] [Bug 60121] build - libvdpau_softpipe fails at runtime.
https://bugs.freedesktop.org/show_bug.cgi?id=60121 --- Comment #1 from Matt Turner matts...@gmail.com --- Try running under strace to see what's going wrong. -- 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] [PATCH] intel: implement create image from texture (v8)
Save miptree level info to DRIImage:
- Appropriately-aligned base offset pointing to the image
- Additional x/y adjustment offsets from above.
In non-tile-aligned surface cases where resolving back to the original image
located in mip-levels higher than the base level proves problematic due to
offset alignment issues, report INVALID_OPERATION as per spec wording.
v8: Bump intelImageExtension version
Reviewed-by: Eric Anholt e...@anholt.net (v6)
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 181 +
1 file changed, 160 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index b39bc46..0e11554 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -31,11 +31,13 @@
#include main/context.h
#include main/framebuffer.h
#include main/renderbuffer.h
+#include main/texobj.h
#include main/hash.h
#include main/fbobject.h
#include main/mfeatures.h
#include main/version.h
#include swrast/s_renderbuffer.h
+#include egl/main/eglcurrent.h
#include utils.h
#include xmlpool.h
@@ -105,6 +107,10 @@ const GLuint __driNConfigOptions = 16;
#include intel_tex.h
#include intel_regions.h
+#ifndef I915
+#include brw_context.h
+#endif
+
#include i915_drm.h
#ifdef USE_NEW_INTERFACE
@@ -296,6 +302,87 @@ intel_allocate_image(int dri_format, void *loaderPrivate)
return image;
}
+static void
+intel_image_set_level_info(__DRIimage *image, struct intel_mipmap_tree *mt,
+ int level, int slice)
+{
+ unsigned int draw_x, draw_y;
+ uint32_t mask_x, mask_y;
+
+ intel_region_get_tile_masks(mt-region, mask_x, mask_y, false);
+ intel_miptree_get_image_offset(mt, level, slice, draw_x, draw_y);
+
+ image-width = mt-level[level].width;
+ image-height = mt-level[level].height;
+ image-tile_x = draw_x mask_x;
+ image-tile_y = draw_y mask_y;
+
+ image-offset = intel_region_get_aligned_offset(mt-region,
+ draw_x ~mask_x,
+ draw_y ~mask_y,
+ false);
+}
+
+/**
+ * Sets up a DRIImage structure to point to our shared image in a region
+ */
+static bool
+intel_setup_image_from_mipmap_tree(struct intel_context *intel, __DRIimage
*image,
+ struct intel_mipmap_tree *mt, GLuint level,
+ GLuint zoffset)
+{
+ bool has_surface_tile_offset = false;
+ uint32_t draw_x, draw_y;
+
+ intel_miptree_check_level_layer(mt, level, zoffset);
+ intel_miptree_get_tile_offsets(mt, level, zoffset, draw_x, draw_y);
+
+#ifndef I915
+ has_surface_tile_offset = brw_context(intel-ctx)-has_surface_tile_offset;
+#endif
+ if (!has_surface_tile_offset
+ (draw_x != 0 || draw_y != 0))
+ /* Non-tile aligned sufaces in gen4 hw and earlier have problems
resolving
+ * back to our destination due to alignment issues. Bail-out and report
error
+ */
+ return false;
+
+ intel_image_set_level_info(image, mt, level, zoffset);
+ intel_region_reference(image-region, mt-region);
+
+ return true;
+}
+
+static void
+intel_setup_image_from_dimensions(__DRIimage *image)
+{
+ image-width= image-region-width;
+ image-height = image-region-height;
+ image-tile_x = 0;
+ image-tile_y = 0;
+}
+
+static inline uint32_t
+intel_dri_format(GLuint format)
+{
+ switch (format) {
+ case MESA_FORMAT_RGB565:
+ return __DRI_IMAGE_FORMAT_RGB565;
+ case MESA_FORMAT_XRGB:
+ return __DRI_IMAGE_FORMAT_XRGB;
+ case MESA_FORMAT_ARGB:
+ return __DRI_IMAGE_FORMAT_ARGB;
+ case MESA_FORMAT_RGBA_REV:
+ return __DRI_IMAGE_FORMAT_ABGR;
+ case MESA_FORMAT_R8:
+ return __DRI_IMAGE_FORMAT_R8;
+ case MESA_FORMAT_RG88:
+ return __DRI_IMAGE_FORMAT_GR88;
+ }
+
+ return MESA_FORMAT_NONE;
+}
+
static __DRIimage *
intel_create_image_from_name(__DRIscreen *screen,
int width, int height, int format,
@@ -318,6 +405,8 @@ intel_create_image_from_name(__DRIscreen *screen,
return NULL;
}
+intel_setup_image_from_dimensions(image);
+
return image;
}
@@ -347,26 +436,69 @@ intel_create_image_from_renderbuffer(__DRIcontext
*context,
image-offset = 0;
image-data = loaderPrivate;
intel_region_reference(image-region, irb-mt-region);
+ intel_setup_image_from_dimensions(image);
+ image-dri_format = intel_dri_format(image-format);
- switch (image-format) {
- case MESA_FORMAT_RGB565:
- image-dri_format = __DRI_IMAGE_FORMAT_RGB565;
- break;
- case MESA_FORMAT_XRGB:
- image-dri_format = __DRI_IMAGE_FORMAT_XRGB;
- break;
- case MESA_FORMAT_ARGB:
- image-dri_format = __DRI_IMAGE_FORMAT_ARGB;
-
Re: [Mesa-dev] [PATCH V7 0/8] intel: add support for EGL_KHR_gl_image
FYI, I'm investigating now why the series breaks the Android build. On 01/30/2013 05:40 AM, Abdiel Janulgue wrote: Mostly similar to V6 but rebased from 0ca384fb39f6d98af2de5654c46394743147d228. The only slight change is in patch 5 which uses bit-shifting to account for offsets instead of structs because of the recent change in Gen7 SURFACE_STATE entries. Series lives on git://gitorious.org/mesa3d/mesa.git KHR_gl_image7 branch CC: Eric Anholt e...@anholt.net Reviewed-by: Eric Anholt e...@anholt.net (v6) Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: adjust usage of swapBytes/littleEndian in format_matches_format_and_type
On Don, 2013-01-31 at 18:03 +0100, Marek Olšák wrote: On Thu, Jan 31, 2013 at 5:39 PM, Michel Dänzer mic...@daenzer.net wrote: I'm afraid these are not quite correct yet. I'm not 100% sure after looking at the red book and the GL 3.x spec — this is head spinning material, isn't it? :\ — but I think swapBytes only applies to the basic type, in these cases GL_BYTE, so it's irrelevant. However, because the Mesa formats are defined as 16 bit packed values in host byte order, these cases can only match directly on little endian hosts, i.e. if (type == GL_BYTE littleEndian). I don't really know. This is the first time I have to worry about endiannes. I discarded the modifications where we are unsure. The updated patch is here: Looks good, but the above discussion shouldn't be included in the commit log (things like that can be put after the --- marker). Other than that, Reviewed-by: Michel Dänzer michel.daen...@amd.com -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 59967] [regression] configure: error: Could not find llvm shared libraries
https://bugs.freedesktop.org/show_bug.cgi?id=59967 Mike Lothian m...@fireburn.co.uk changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #10 from Mike Lothian m...@fireburn.co.uk --- Would it be possible to update mesa to accept llvm config and llvm library locations as switches rather than it being an environmental variable? -- 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] intel: implement create image from texture (v8)
On 01/31/2013 09:35 AM, Abdiel Janulgue wrote:
Save miptree level info to DRIImage:
- Appropriately-aligned base offset pointing to the image
- Additional x/y adjustment offsets from above.
In non-tile-aligned surface cases where resolving back to the original image
located in mip-levels higher than the base level proves problematic due to
offset alignment issues, report INVALID_OPERATION as per spec wording.
v8: Bump intelImageExtension version
Reviewed-by: Eric Anholt e...@anholt.net (v6)
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c | 181
+
1 file changed, 160 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index b39bc46..0e11554 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -31,11 +31,13 @@
+#include egl/main/eglcurrent.h
+static __DRIimage *
+intel_create_image_from_texture(__DRIcontext *context, int target,
+unsigned texture, int zoffset,
+int level,
+void *loaderPrivate)
+{
This function directly calls _eglError(). Nowhere else
in the i965 driver are direct calls made to GLX or EGL. If,
in the future, we wish to use this function when a GLXContext
is current, the behavior would be undefined.
To fix this, I would add an out parameter `int *dri_error` to
__DRIimageExtensionRec::createImageFromTexture. Then
dri2_create_image_khr_texture() would inspect the DRI error
code and emit the matching EGL error. This is exactly what the DRI interface
does for
DRIdri2ExtensionRec::CreateContext, which is implemented by
intelCreateContext().
However, dri_interface.h does not define any appropriate error codes for
EGL_BAD_{ALLOC,PARAMETER,MATCH}. So you would need to define
new ones. I would name them to match the EGL names, such
as __DRI_ERROR_BAD_{ALLOC,PARAMETER,MATCH}. Since the set of
possible error codes is part of a function's ABI, the
__DRIimageExtensionRec::createImageFromTexture documentation
should explain what that set is.
+ __DRIimage *image;
+ struct intel_context *intel = context-driverPrivate;
+ struct gl_texture_object *obj;
+ struct intel_texture_object *iobj;
+ GLuint face = 0;
+
+ obj = _mesa_lookup_texture(intel-ctx, texture);
+ if (!obj || obj-Target != target) {
+ _eglError(EGL_BAD_PARAMETER, __func__);
+ return NULL;
+ }
+
+ if (target == GL_TEXTURE_CUBE_MAP)
+ face = zoffset;
+
+ _mesa_test_texobj_completeness(intel-ctx, obj);
+ iobj = intel_texture_object(obj);
+ if (!obj-_BaseComplete || (level 0 !obj-_MipmapComplete)) {
+ _eglError(EGL_BAD_PARAMETER, __func__);
+ return NULL;
+ }
+
+ if (level obj-BaseLevel || level obj-_MaxLevel) {
+ _eglError(EGL_BAD_MATCH, __func__);
+ return NULL;
+ }
+
+ if (target == GL_TEXTURE_3D obj-Image[face][level]-Depth zoffset) {
+ _eglError(EGL_BAD_MATCH, __func__);
+ return NULL;
+ }
+ image = calloc(1, sizeof *image);
+ if (image == NULL) {
+ _eglError(EGL_BAD_ALLOC, __func__);
+ return NULL;
+ }
+
+ image-internal_format = obj-Image[face][level]-InternalFormat;
+ image-format = obj-Image[face][level]-TexFormat;
+ image-data = loaderPrivate;
+ if (iobj-mt-stencil_mt ||
+ !intel_setup_image_from_mipmap_tree(intel, image, iobj-mt, level,
zoffset)) {
+ _mesa_error(intel-ctx, GL_INVALID_OPERATION, __func__);
This function emits a mixture of EGL and GL errors. Is that allowed by the
extension spec?
+ free(image);
+ return NULL;
+ }
+ image-dri_format = intel_dri_format(image-format);
+ if (image-dri_format == MESA_FORMAT_NONE) {
+ fprintf(stderr, %s: Cannot make EGL image from invalid format.\n,
__func__);
+ free(image);
An error code needs to be emitted here, or the EGL client might get
confused. Perhaps __DRI_ERROR_BAD_PARAMETER?
+ return NULL;
}
Removing the calls to _eglError fixes the Android build.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallivm: fix issues with trunc/round/floor/ceil with no arch rounding
From: Roland Scheidegger srol...@vmware.com
The emulation of these if there's no rounding instruction available
is a bit more complicated than what the code did.
In particular, doing fp-to-int/int-to-fp will not work if the exponent
is large enough (and with NaNs, Infs). Hence such values need to be filtered
out and the original value returned in this case (which fortunately should
always be exact). This comes at the expense of performance (if your cpu
doesn't support rounding instructions).
Furthermore, floor/ifloor/ceil/iceil were affected by precision issues for
values near negative (for floor) or positive (for ceil) zero, fix that as well
(fixing this issue might not actually be slower except for ceil/iceil if the
type is not signed which is probably rare - note iceil has no callers left
in any case).
Also add some new rounding test values in lp_test_arit to actually test
for that stuff (which previously would have failed without sse41).
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=59701.
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 253 ---
src/gallium/drivers/llvmpipe/lp_test_arit.c | 12 ++
2 files changed, 199 insertions(+), 66 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index d930f09..cc9b6df 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -1590,12 +1590,37 @@ lp_build_trunc(struct lp_build_context *bld,
return lp_build_round_arch(bld, a, LP_BUILD_ROUND_TRUNCATE);
}
else {
- LLVMTypeRef vec_type = lp_build_vec_type(bld-gallivm, type);
- LLVMTypeRef int_vec_type = lp_build_int_vec_type(bld-gallivm, type);
- LLVMValueRef res;
- res = LLVMBuildFPToSI(builder, a, int_vec_type, );
- res = LLVMBuildSIToFP(builder, res, vec_type, );
- return res;
+ const struct lp_type type = bld-type;
+ struct lp_type inttype;
+ struct lp_build_context intbld;
+ LLVMValueRef cmpval = lp_build_const_vec(bld-gallivm, type, 2^24);
+ LLVMValueRef trunc, res, anosign, mask;
+ LLVMTypeRef int_vec_type = bld-int_vec_type;
+ LLVMTypeRef vec_type = bld-vec_type;
+
+ assert(type.width == 32); /* might want to handle doubles at some point
*/
+
+ inttype = type;
+ inttype.floating = 0;
+ lp_build_context_init(intbld, bld-gallivm, inttype);
+
+ /* round by truncation */
+ trunc = LLVMBuildFPToSI(builder, a, int_vec_type, );
+ res = LLVMBuildSIToFP(builder, trunc, vec_type, floor.trunc);
+
+ /* mask out sign bit */
+ anosign = lp_build_abs(bld, a);
+ /*
+ * mask out all values if anosign 2^24
+ * This should work both for large ints (all rounding is no-op for them
+ * because such floats are always exact) as well as special cases like
+ * NaNs, Infs (taking advantage of the fact they use max exponent).
+ * (2^24 is arbitrary anything between 2^24 and 2^31 should work.)
+ */
+ anosign = LLVMBuildBitCast(builder, anosign, int_vec_type, );
+ cmpval = LLVMBuildBitCast(builder, cmpval, int_vec_type, );
+ mask = lp_build_cmp(intbld, PIPE_FUNC_GREATER, anosign, cmpval);
+ return lp_build_select(bld, mask, a, res);
}
}
@@ -1620,11 +1645,36 @@ lp_build_round(struct lp_build_context *bld,
return lp_build_round_arch(bld, a, LP_BUILD_ROUND_NEAREST);
}
else {
- LLVMTypeRef vec_type = lp_build_vec_type(bld-gallivm, type);
- LLVMValueRef res;
+ const struct lp_type type = bld-type;
+ struct lp_type inttype;
+ struct lp_build_context intbld;
+ LLVMValueRef cmpval = lp_build_const_vec(bld-gallivm, type, 2^24);
+ LLVMValueRef res, anosign, mask;
+ LLVMTypeRef int_vec_type = bld-int_vec_type;
+ LLVMTypeRef vec_type = bld-vec_type;
+
+ assert(type.width == 32); /* might want to handle doubles at some point
*/
+
+ inttype = type;
+ inttype.floating = 0;
+ lp_build_context_init(intbld, bld-gallivm, inttype);
+
res = lp_build_iround(bld, a);
res = LLVMBuildSIToFP(builder, res, vec_type, );
- return res;
+
+ /* mask out sign bit */
+ anosign = lp_build_abs(bld, a);
+ /*
+ * mask out all values if anosign 2^24
+ * This should work both for large ints (all rounding is no-op for them
+ * because such floats are always exact) as well as special cases like
+ * NaNs, Infs (taking advantage of the fact they use max exponent).
+ * (2^24 is arbitrary anything between 2^24 and 2^31 should work.)
+ */
+ anosign = LLVMBuildBitCast(builder, anosign, int_vec_type, );
+ cmpval = LLVMBuildBitCast(builder, cmpval, int_vec_type, );
+ mask = lp_build_cmp(intbld, PIPE_FUNC_GREATER, anosign, cmpval);
+ return lp_build_select(bld, mask, a, res);
}
}
@@ -1648,11 +1698,52 @@ lp_build_floor(struct lp_build_context *bld,
return
Re: [Mesa-dev] [PATCH 1/8] mesa: fill in SRGB cases in _mesa_format_matches_format_and_type
Here's the branch: git://people.freedesktop.org/~mareko/mesa rgbx-and-texstore Please let me know when it can be pushed to master. Marek On Tue, Jan 29, 2013 at 7:00 PM, Ian Romanick i...@freedesktop.org wrote: I like these changes, but this hits some twitchy code. Do you have a branch somewhere that I could have my QA team test? On 01/29/2013 05:43 AM, Marek Olšák wrote: Texstore takes the same codepath as the corresponding linear formats. --- src/mesa/main/formats.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c index 0a06200..9dab545 100644 --- a/src/mesa/main/formats.c +++ b/src/mesa/main/formats.c @@ -2870,6 +2870,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_RGBA: + case MESA_FORMAT_SRGBA8: if (format == GL_RGBA type == GL_UNSIGNED_INT_8_8_8_8 !swapBytes) return GL_TRUE; @@ -2917,6 +2918,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_ARGB: + case MESA_FORMAT_SARGB8: if (format == GL_BGRA type == GL_UNSIGNED_INT_8_8_8_8_REV !swapBytes) return GL_TRUE; @@ -2951,6 +2953,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return GL_FALSE; case MESA_FORMAT_RGB888: + case MESA_FORMAT_SRGB8: return format == GL_BGR type == GL_UNSIGNED_BYTE littleEndian; case MESA_FORMAT_BGR888: @@ -2987,6 +2990,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, case MESA_FORMAT_AL44: return GL_FALSE; case MESA_FORMAT_AL88: + case MESA_FORMAT_SLA8: return format == GL_LUMINANCE_ALPHA type == GL_UNSIGNED_BYTE littleEndian; case MESA_FORMAT_AL88_REV: return GL_FALSE; @@ -3005,6 +3009,7 @@ _mesa_format_matches_format_and_type(gl_format gl_format, return format == GL_ALPHA type == GL_UNSIGNED_SHORT littleEndian !swapBytes; case MESA_FORMAT_L8: + case MESA_FORMAT_SL8: return format == GL_LUMINANCE type == GL_UNSIGNED_BYTE; case MESA_FORMAT_L16: return format == GL_LUMINANCE type == GL_UNSIGNED_SHORT @@ -3060,11 +3065,6 @@ _mesa_format_matches_format_and_type(gl_format gl_format, case MESA_FORMAT_S8: return format == GL_STENCIL_INDEX type == GL_UNSIGNED_BYTE; - case MESA_FORMAT_SRGB8: - case MESA_FORMAT_SRGBA8: - case MESA_FORMAT_SARGB8: - case MESA_FORMAT_SL8: - case MESA_FORMAT_SLA8: case MESA_FORMAT_SRGB_DXT1: case MESA_FORMAT_SRGBA_DXT1: case MESA_FORMAT_SRGBA_DXT3: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: RFC: ISA information tables and shader disassembler
Do you plan to merge this branch anytime soon? Marek On Sat, Dec 29, 2012 at 5:36 PM, Vadim Girlin vadimgir...@gmail.com wrote: The patches are pretty big so you can find the branch here: http://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-disasm My primary goal was to have a shader disassembler in the driver to simplify the debugging. The disassembler itself is small, but it relies on the big patch that introduces the tables with ISA information - names of the instructions, opcodes for different chip classes, flags to simplify instruction classification, etc. Although the disassembler needs the names only, I had the complete tables already prepared for other work on shader optimization, so I think that it makes sense to use other stuff as well while I'm at it. All bytecode structs now contain the indices of instruction records in the tables instead of native opcodes - this allows easy access to all related information in the tables - e.g. number of operands for alu instructions, native opcode for current chip class, etc. Also this allows to use single id for instruction even if it has different opcodes on different chips, that is, e.g. we don't have to check for all possible opcodes to say that current instruction is DOT4, we can simply compare alu-op with ALU_OP2_DOT4 constant that represents the index in the table, so this simplifies the processing of the shader code. Also alu table contains the information about allowed slots (vector/scalar) for different chip classes and some additional flags - e.g. instead of comparing some opcode with all possible KILLxx opcodes we can simply check the flag that is set in the table for all KILLxx instructions. The branch was tested on evergreen and there are no regressions with both shader backends (llvm and old), but I won't be surprised if there are bugs for another chip classes. I'll appreciate testing on r6xx/r7xx/cayman, but be ready to possible lockups etc. New disassembler can be activated with R600_DUMP_SHADERS=2. R600_DUMP_SHADERS=1 still uses old dump method, 3 - produces both dumps for every shader. Vadim ___ 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] [PATCH 1/2] R600: Add an explicit default processor
From: Tom Stellard thomas.stell...@amd.com This is for the case when no processor is passed to the backend. This prevents the '' is not a recognized processor for this target (ignoring processor) warning from being generated by clang. --- lib/Target/R600/Processors.td |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/Target/R600/Processors.td b/lib/Target/R600/Processors.td index 3dc1ecd..868810c 100644 --- a/lib/Target/R600/Processors.td +++ b/lib/Target/R600/Processors.td @@ -13,6 +13,7 @@ class Procstring Name, ProcessorItineraries itin, listSubtargetFeature Features : ProcessorName, itin, Features; +def : Proc, R600_EG_Itin, [FeatureR600ALUInst]; def : Procr600, R600_EG_Itin, [FeatureR600ALUInst]; def : Procrv710, R600_EG_Itin, []; def : Procrv730, R600_EG_Itin, []; -- 1.7.8.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] cl-program-tester: Fix parsing of vec16 types
From: Tom Stellard thomas.stell...@amd.com
---
tests/cl/program/program-tester.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/cl/program/program-tester.c
b/tests/cl/program/program-tester.c
index 096cd2a..189b617 100644
--- a/tests/cl/program/program-tester.c
+++ b/tests/cl/program/program-tester.c
@@ -964,9 +964,9 @@ get_test_arg(const char* src, struct test* test, bool
arg_in)
/* Set type, cl_size, cl_mem_size and size (partially for buffers) */
regex_get_match_str(type, src, pmatch, 2);
- if(regex_match(type, [[:digit:]])) {
+ if(regex_match(type, [[:digit:]]+)) {
char* type_size_str;
- regex_get_str(type_size_str, type, [[:digit:]], 0,
REG_NEWLINE);
+ regex_get_str(type_size_str, type, [[:digit:]]+, 0,
REG_NEWLINE);
test_arg.cl_size = get_int(type_size_str);
test_arg.cl_mem_size = test_arg.cl_size != 3 ? test_arg.cl_size
: 4; // test if we have type3
free(type_size_str);
--
1.7.8.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 60121] build - libvdpau_softpipe fails at runtime.
https://bugs.freedesktop.org/show_bug.cgi?id=60121
--- Comment #2 from Andy Furniss li...@andyfurniss.entadsl.com ---
(In reply to comment #1)
Try running under strace to see what's going wrong.
Below is what happens - I don't know why - it opens /usr/lib/vdpau OK but then
there are a bunch of fails and it ends up trying /lib and /usr/lib.
open(/usr/lib/vdpau/libvdpau_softpipe.so.1, O_RDONLY|O_CLOEXEC) = 6
read(6,
\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\200\350\32\0\0\0\0\0..., 832)
= 832
fstat(6, {st_mode=S_IFREG|0755, st_size=31041050, ...}) = 0
mmap(NULL, 24122432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) =
0x7fc6e4b34000
mprotect(0x7fc6e5cef000, 2093056, PROT_NONE) = 0
mmap(0x7fc6e5eee000, 475136, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x11ba000) = 0x7fc6e5eee000
mmap(0x7fc6e5f62000, 2962496, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc6e5f62000
close(6)= 0
open(/usr/lib/../lib/tls/x86_64/libstdc++.so.6, O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
stat(/usr/lib/../lib/tls/x86_64, 0x7fff67a3fd10) = -1 ENOENT (No such file or
directory)
open(/usr/lib/../lib/tls/libstdc++.so.6, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
stat(/usr/lib/../lib/tls, 0x7fff67a3fd10) = -1 ENOENT (No such file or
directory)
open(/usr/lib/../lib/x86_64/libstdc++.so.6, O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
stat(/usr/lib/../lib/x86_64, 0x7fff67a3fd10) = -1 ENOENT (No such file or
directory)
open(/usr/lib/../lib/libstdc++.so.6, O_RDONLY|O_CLOEXEC) = 6
read(6,
\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\360\221\5\0\0\0\0\0..., 832) =
832
fstat(6, {st_mode=S_IFREG|0755, st_size=5730036, ...}) = 0
mmap(NULL, 3134384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) =
0x7fc6e4836000
mprotect(0x7fc6e4916000, 2093056, PROT_NONE) = 0
mmap(0x7fc6e4b15000, 40960, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0xdf000) = 0x7fc6e4b15000
mmap(0x7fc6e4b1f000, 82864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc6e4b1f000
close(6)= 0
open(/usr/lib/../lib/libgcc_s.so.1, O_RDONLY|O_CLOEXEC) = 6
read(6, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\20(\0\0\0\0\0\0...,
832) = 832
fstat(6, {st_mode=S_IFREG|0644, st_size=486560, ...}) = 0
mmap(NULL, 2182520, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) =
0x7fc6e4621000
mprotect(0x7fc6e4636000, 2093056, PROT_NONE) = 0
mmap(0x7fc6e4835000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x14000) = 0x7fc6e4835000
close(6)= 0
mprotect(0x7fc6e4b15000, 32768, PROT_READ) = 0
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=43792, ...}) = 0
mmap(NULL, 43792, PROT_READ, MAP_PRIVATE, 6, 0) = 0x7fc6eda39000
close(6)= 0
open(/lib/libvdpau_softpipe.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
open(/usr/lib/libvdpau_softpipe.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
munmap(0x7fc6eda39000, 43792) = 0
write(2, Failed to open VDPAU backend lib..., 109Failed to open VDPAU backend
libvdpau_softpipe.so: cannot open shared object file: No such file or directory
--
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] [PATCH 1/2] r600g: report correct flow control depth, taking hardware bugs into account
---
src/gallium/drivers/r600/r600_pipe.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index a59578d..1698cb3 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -640,6 +640,8 @@ static float r600_get_paramf(struct pipe_screen* pscreen,
static int r600_get_shader_param(struct pipe_screen* pscreen, unsigned shader,
enum pipe_shader_cap param)
{
+ struct r600_screen *rscreen = (struct r600_screen *)pscreen;
+
switch(shader)
{
case PIPE_SHADER_FRAGMENT:
@@ -654,7 +656,6 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
return 0;
}
- /* XXX: all these should be fixed, since r600 surely supports much
more! */
switch (param) {
case PIPE_SHADER_CAP_MAX_INSTRUCTIONS:
case PIPE_SHADER_CAP_MAX_ALU_INSTRUCTIONS:
@@ -662,7 +663,11 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
case PIPE_SHADER_CAP_MAX_TEX_INDIRECTIONS:
return 16384;
case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH:
- return 8; /* XXX */
+ /* There is a bug on certain Evergreen cards which limits
+* the control flow depth. */
+ return rscreen-chip_class == EVERGREEN
+ rscreen-family != CHIP_CYPRESS
+ rscreen-family != CHIP_HEMLOCK ? 3 : 32;
case PIPE_SHADER_CAP_MAX_INPUTS:
return 32;
case PIPE_SHADER_CAP_MAX_TEMPS:
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radeonsi: port some of get_shader_param changes from r600g
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
index 471dd48..860e70f 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
@@ -438,7 +438,6 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
return 0;
}
- /* TODO: all these should be fixed, since r600 surely supports much
more! */
switch (param) {
case PIPE_SHADER_CAP_MAX_INSTRUCTIONS:
case PIPE_SHADER_CAP_MAX_ALU_INSTRUCTIONS:
@@ -446,12 +445,9 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
case PIPE_SHADER_CAP_MAX_TEX_INDIRECTIONS:
return 16384;
case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH:
- return 8; /* FIXME */
+ return 32;
case PIPE_SHADER_CAP_MAX_INPUTS:
- if(shader == PIPE_SHADER_FRAGMENT)
- return 34;
- else
- return 32;
+ return 32;
case PIPE_SHADER_CAP_MAX_TEMPS:
return 256; /* Max native temporaries. */
case PIPE_SHADER_CAP_MAX_ADDRS:
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: fix incorrect comment about do_common_optimization
--- src/glsl/glsl_parser_extras.cpp |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp index c8dbc89..7d826e3 100644 --- a/src/glsl/glsl_parser_extras.cpp +++ b/src/glsl/glsl_parser_extras.cpp @@ -1195,8 +1195,8 @@ ast_struct_specifier::ast_struct_specifier(const char *identifier, *The setting of this flag only matters if *\c linked is \c true. * \param max_unroll_iterations Maximum number of loop iterations to be - *unrolled. Setting to 0 forces all loops - *to be unrolled. + *unrolled. Setting to 0 disables loop + *unrolling. */ bool do_common_optimization(exec_list *ir, bool linked, -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] st/mesa: remove dead code depending on EmitCondCodes
EmitCondCodes is always false.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index c6ac634..bc29f8a 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2925,32 +2925,12 @@ glsl_to_tgsi_visitor::visit(ir_discard *ir)
void
glsl_to_tgsi_visitor::visit(ir_if *ir)
{
- glsl_to_tgsi_instruction *cond_inst, *if_inst;
- glsl_to_tgsi_instruction *prev_inst;
-
- prev_inst = (glsl_to_tgsi_instruction *)this-instructions.get_tail();
+ glsl_to_tgsi_instruction *if_inst;
ir-condition-accept(this);
assert(this-result.file != PROGRAM_UNDEFINED);
- if (this-options-EmitCondCodes) {
- cond_inst = (glsl_to_tgsi_instruction *)this-instructions.get_tail();
-
- /* See if we actually generated any instruction for generating
- * the condition. If not, then cook up a move to a temp so we
- * have something to set cond_update on.
- */
- if (cond_inst == prev_inst) {
- st_src_reg temp = get_temp(glsl_type::bool_type);
- cond_inst = emit(ir-condition, TGSI_OPCODE_MOV, st_dst_reg(temp),
result);
- }
- cond_inst-cond_update = GL_TRUE;
-
- if_inst = emit(ir-condition, TGSI_OPCODE_IF);
- if_inst-dst.cond_mask = COND_NE;
- } else {
- if_inst = emit(ir-condition, TGSI_OPCODE_IF, undef_dst, this-result);
- }
+ if_inst = emit(ir-condition, TGSI_OPCODE_IF, undef_dst, this-result);
this-instructions.push_tail(if_inst);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] st/mesa: do most of GLSL lowering outside of the optimization do-while loop
based on the intel driver
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 65 +---
1 file changed, 29 insertions(+), 36 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index bc29f8a..994a551 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -5141,21 +5141,37 @@ st_link_shader(struct gl_context *ctx, struct
gl_shader_program *prog)
const struct gl_shader_compiler_options *options =
ctx-ShaderCompilerOptions[_mesa_shader_type_to_index(prog-_LinkedShaders[i]-Type)];
- do {
- unsigned what_to_lower = MOD_TO_FRACT | DIV_TO_MUL_RCP |
-EXP_TO_EXP2 | LOG_TO_LOG2;
- if (options-EmitNoPow)
-what_to_lower |= POW_TO_EXP2;
- if (!ctx-Const.NativeIntegers)
-what_to_lower |= INT_DIV_TO_MUL_RCP;
-
- progress = false;
+ /* If there are forms of indirect addressing that the driver
+ * cannot handle, perform the lowering pass.
+ */
+ if (options-EmitNoIndirectInput || options-EmitNoIndirectOutput ||
+ options-EmitNoIndirectTemp || options-EmitNoIndirectUniform) {
+ lower_variable_index_to_cond_assign(ir,
+ options-EmitNoIndirectInput,
+ options-EmitNoIndirectOutput,
+ options-EmitNoIndirectTemp,
+ options-EmitNoIndirectUniform);
+ }
- /* Lowering */
- do_mat_op_to_vec(ir);
- lower_instructions(ir, what_to_lower);
+ do_mat_op_to_vec(ir);
+ lower_instructions(ir,
+ MOD_TO_FRACT |
+ DIV_TO_MUL_RCP |
+ EXP_TO_EXP2 |
+ LOG_TO_LOG2 |
+ (options-EmitNoPow ? POW_TO_EXP2 : 0) |
+ (!ctx-Const.NativeIntegers ? INT_DIV_TO_MUL_RCP :
0));
+
+ lower_ubo_reference(prog-_LinkedShaders[i], ir);
+ do_vec_index_to_cond_assign(ir);
+ lower_quadop_vector(ir, false);
+ lower_noise(ir);
+ if (options-MaxIfDepth == 0) {
+ lower_discard(ir);
+ }
- lower_ubo_reference(prog-_LinkedShaders[i], ir);
+ do {
+ progress = false;
progress = do_lower_jumps(ir, true, true, options-EmitNoMainReturn,
options-EmitNoCont, options-EmitNoLoops) || progress;
@@ -5163,31 +5179,8 @@ st_link_shader(struct gl_context *ctx, struct
gl_shader_program *prog)
options-MaxUnrollIterations)
|| progress;
- progress = lower_quadop_vector(ir, false) || progress;
-
- if (options-MaxIfDepth == 0)
-progress = lower_discard(ir) || progress;
-
progress = lower_if_to_cond_assign(ir, options-MaxIfDepth) ||
progress;
- if (options-EmitNoNoise)
-progress = lower_noise(ir) || progress;
-
- /* If there are forms of indirect addressing that the driver
- * cannot handle, perform the lowering pass.
- */
- if (options-EmitNoIndirectInput || options-EmitNoIndirectOutput
- || options-EmitNoIndirectTemp || options-EmitNoIndirectUniform)
- progress =
- lower_variable_index_to_cond_assign(ir,
-options-EmitNoIndirectInput,
-options-EmitNoIndirectOutput,
-options-EmitNoIndirectTemp,
-options-EmitNoIndirectUniform)
- || progress;
-
- progress = do_vec_index_to_cond_assign(ir) || progress;
-
} while (progress);
validate_ir_tree(ir);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] st/mesa: emit saturates in the vertex shader if GLSL = 1.30 is supported
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 994a551..6d556a2 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -1286,10 +1286,10 @@
glsl_to_tgsi_visitor::try_emit_mad_for_and_not(ir_expression *ir, int try_operan
bool
glsl_to_tgsi_visitor::try_emit_sat(ir_expression *ir)
{
- /* Saturates were only introduced to vertex programs in
-* NV_vertex_program3, so don't give them to drivers in the VP.
+ /* Emit saturates in the vertex shader only if GLSL 1.30 is supported.
*/
- if (this-prog-Target == GL_VERTEX_PROGRAM_ARB)
+ if (this-prog-Target == GL_VERTEX_PROGRAM_ARB
+ this-ctx-Const.GLSLVersion 130)
return false;
ir_rvalue *sat_src = ir-as_rvalue_to_saturate();
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] st/mesa: advertise ARB_shading_language_packing for GLSL = 1.30
---
src/mesa/state_tracker/st_extensions.c |1 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 15 +++
2 files changed, 16 insertions(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 214588f..4d2d43d 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -597,6 +597,7 @@ void st_init_extensions(struct st_context *st)
/* Extensions that either depend on GLSL 1.30 or are a subset thereof. */
ctx-Extensions.ARB_conservative_depth = GL_TRUE;
ctx-Extensions.ARB_shader_bit_encoding = GL_TRUE;
+ ctx-Extensions.ARB_shading_language_packing = GL_TRUE;
ctx-Extensions.OES_depth_texture_cube_map = GL_TRUE;
} else {
/* Optional integer support for GLSL 1.2. */
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 6d556a2..f612b99 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -5153,6 +5153,21 @@ st_link_shader(struct gl_context *ctx, struct
gl_shader_program *prog)
options-EmitNoIndirectUniform);
}
+ if (ctx-Extensions.ARB_shading_language_packing) {
+ unsigned lower_inst = LOWER_PACK_SNORM_2x16 |
+ LOWER_UNPACK_SNORM_2x16 |
+ LOWER_PACK_UNORM_2x16 |
+ LOWER_UNPACK_UNORM_2x16 |
+ LOWER_PACK_SNORM_4x8 |
+ LOWER_UNPACK_SNORM_4x8 |
+ LOWER_UNPACK_UNORM_4x8 |
+ LOWER_PACK_UNORM_4x8 |
+ LOWER_PACK_HALF_2x16 |
+ LOWER_UNPACK_HALF_2x16;
+
+ lower_packing_builtins(ir, lower_inst);
+ }
+
do_mat_op_to_vec(ir);
lower_instructions(ir,
MOD_TO_FRACT |
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] mesa/glsl: Separate parsing logic from _mesa_get_uniform_location.
The parsing logic is moved to a new function in the GLSL module,
parse_program_resource_name(). This name was chosen because it should
eventually be useful for handling everything that OpenGL 4.3 calls
program resources (e.g. uniforms, vertex inputs, fragment outputs,
and transform feedback varyings).
Future patches will make use of this function for linking transform
feedback varyings.
NOTE: This is a candidate for the 9.1 branch.
---
src/glsl/linker.cpp | 59
src/glsl/program.h | 4 ++
src/mesa/main/uniform_query.cpp | 85 -
src/mesa/main/uniforms.h| 4 ++
4 files changed, 91 insertions(+), 61 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 63ce178..57e7a9a 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -200,6 +200,65 @@ linker_warning(gl_shader_program *prog, const char *fmt,
...)
}
+/**
+ * Given a string identifying a program resource, break it into a base name
+ * and an optional array index in square brackets.
+ *
+ * If an array index is present, \c out_base_name_end is set to point to the
+ * [ that precedes the array index, and the array index itself is returned
+ * as a long.
+ *
+ * If no array index is present (or if the array index is negative or
+ * mal-formed), \c out_base_name_end, is set to point to the null terminator
+ * at the end of the input string, and -1 is returned.
+ *
+ * Only the final array index is parsed; if the string contains other array
+ * indices (or structure field accesses), they are left in the base name.
+ *
+ * No attempt is made to check that the base name is properly formed;
+ * typically the caller will look up the base name in a hash table, so
+ * ill-formed base names simply turn into hash table lookup failures.
+ */
+long
+parse_program_resource_name(const GLchar *name,
+const GLchar **out_base_name_end)
+{
+ /* Section 7.3.1 (Program Interfaces) of the OpenGL 4.3 spec says:
+*
+* When an integer array element or block instance number is part of
+* the name string, it will be specified in decimal form without a +
+* or - sign or any extra leading zeroes. Additionally, the name
+* string will not include white space anywhere in the string.
+*/
+
+ const size_t len = strlen(name);
+ *out_base_name_end = name + len;
+
+ if (len == 0 || name[len-1] != ']')
+ return -1;
+
+ /* Walk backwards over the string looking for a non-digit character. This
+* had better be the opening bracket for an array index.
+*
+* Initially, i specifies the location of the ']'. Since the string may
+* contain only the ']' charcater, walk backwards very carefully.
+*/
+ unsigned i;
+ for (i = len - 1; (i 0) isdigit(name[i-1]); --i)
+ /* empty */ ;
+
+ if ((i == 0) || name[i-1] != '[')
+ return -1;
+
+ long array_index = strtol(name[i], NULL, 10);
+ if (array_index 0)
+ return -1;
+
+ *out_base_name_end = name + (i - 1);
+ return array_index;
+}
+
+
void
link_invalidate_variable_locations(gl_shader *sh, int input_base,
int output_base)
diff --git a/src/glsl/program.h b/src/glsl/program.h
index 437ca14..46ce9dc 100644
--- a/src/glsl/program.h
+++ b/src/glsl/program.h
@@ -33,3 +33,7 @@ linker_error(gl_shader_program *prog, const char *fmt, ...)
extern void
linker_warning(gl_shader_program *prog, const char *fmt, ...)
PRINTFLIKE(2, 3);
+
+extern long
+parse_program_resource_name(const GLchar *name,
+const GLchar **out_base_name_end);
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index dc550bc..b8335fe 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -929,6 +929,7 @@ _mesa_uniform_matrix(struct gl_context *ctx, struct
gl_shader_program *shProg,
_mesa_propagate_uniforms_to_driver_storage(uni, offset, count);
}
+
/**
* Called via glGetUniformLocation().
*
@@ -944,73 +945,35 @@ _mesa_get_uniform_location(struct gl_context *ctx,
const GLchar *name,
unsigned *out_offset)
{
- const size_t len = strlen(name);
- long offset;
- bool array_lookup;
- char *name_copy;
-
- /* If the name ends with a ']', assume that it refers to some element of an
-* array. Malformed array references will fail the hash table look up
-* below, so it doesn't matter that they are not caught here. This code
-* only wants to catch the leaf array references so that arrays of
-* structures containing arrays will be handled correctly.
+ /* Page 80 (page 94 of the PDF) of the OpenGL 2.1 spec says:
+*
+* The first element of a uniform array is identified using the
+* name of the uniform array appended with [0]. Except if the last
+* part of the string name indicates a uniform
[Mesa-dev] [PATCH 2/4] glsl: Rename uniform_field_visitor to program_resource_visitor.
There's actually nothing uniform-specific in uniform_field_visitor.
It is potentially useful for all kinds of program resources (in
particular, future patches will use it for transform feedback
varyings).
This patch renames it to program_resource_visitor, and clarifies
several comments, to reflect the fact that it is useful for more than
just uniforms.
NOTE: This is a candidate for the 9.1 branch.
---
src/glsl/link_uniform_blocks.cpp | 6 +++---
src/glsl/link_uniforms.cpp | 24
src/glsl/linker.h| 33 +
src/mesa/program/ir_to_mesa.cpp | 4 ++--
4 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/src/glsl/link_uniform_blocks.cpp b/src/glsl/link_uniform_blocks.cpp
index 74fe1e2..c72d1d8 100644
--- a/src/glsl/link_uniform_blocks.cpp
+++ b/src/glsl/link_uniform_blocks.cpp
@@ -29,7 +29,7 @@
#include main/hash_table.h
#include program.h
-class ubo_visitor : public uniform_field_visitor {
+class ubo_visitor : public program_resource_visitor {
public:
ubo_visitor(void *mem_ctx, gl_uniform_buffer_variable *variables,
unsigned num_variables)
@@ -44,7 +44,7 @@ public:
this-offset = 0;
this-buffer_size = 0;
this-is_array_instance = strchr(name, ']') != NULL;
- this-uniform_field_visitor::process(type, name);
+ this-program_resource_visitor::process(type, name);
}
unsigned index;
@@ -112,7 +112,7 @@ private:
}
};
-class count_block_size : public uniform_field_visitor {
+class count_block_size : public program_resource_visitor {
public:
count_block_size() : num_active_uniforms(0)
{
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index f1284ad..d457e4d 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -52,7 +52,7 @@ values_for_type(const glsl_type *type)
}
void
-uniform_field_visitor::process(const glsl_type *type, const char *name)
+program_resource_visitor::process(const glsl_type *type, const char *name)
{
assert(type-is_record()
|| (type-is_array() type-fields.array-is_record())
@@ -65,7 +65,7 @@ uniform_field_visitor::process(const glsl_type *type, const
char *name)
}
void
-uniform_field_visitor::process(ir_variable *var)
+program_resource_visitor::process(ir_variable *var)
{
const glsl_type *t = var-type;
@@ -93,8 +93,8 @@ uniform_field_visitor::process(ir_variable *var)
}
void
-uniform_field_visitor::recursion(const glsl_type *t, char **name,
- size_t name_length, bool row_major)
+program_resource_visitor::recursion(const glsl_type *t, char **name,
+size_t name_length, bool row_major)
{
/* Records need to have each field processed individually.
*
@@ -110,7 +110,7 @@ uniform_field_visitor::recursion(const glsl_type *t, char
**name,
if (t-fields.structure[i].type-is_record())
this-visit_field(t-fields.structure[i]);
- /* Append '.field' to the current uniform name. */
+ /* Append '.field' to the current variable name. */
if (name_length == 0) {
ralloc_asprintf_rewrite_tail(name, new_length, %s, field);
} else {
@@ -125,7 +125,7 @@ uniform_field_visitor::recursion(const glsl_type *t, char
**name,
for (unsigned i = 0; i t-length; i++) {
size_t new_length = name_length;
-/* Append the subscript to the current uniform name */
+/* Append the subscript to the current variable name */
ralloc_asprintf_rewrite_tail(name, new_length, [%u], i);
recursion(t-fields.array, name, new_length,
@@ -137,7 +137,7 @@ uniform_field_visitor::recursion(const glsl_type *t, char
**name,
}
void
-uniform_field_visitor::visit_field(const glsl_struct_field *field)
+program_resource_visitor::visit_field(const glsl_struct_field *field)
{
(void) field;
/* empty */
@@ -153,7 +153,7 @@ uniform_field_visitor::visit_field(const glsl_struct_field
*field)
* If the same uniform is added multiple times (i.e., once for each shader
* target), it will only be accounted once.
*/
-class count_uniform_size : public uniform_field_visitor {
+class count_uniform_size : public program_resource_visitor {
public:
count_uniform_size(struct string_to_uint_map *map)
: num_active_uniforms(0), num_values(0), num_shader_samplers(0),
@@ -171,10 +171,10 @@ public:
void process(ir_variable *var)
{
if (var-is_interface_instance())
- uniform_field_visitor::process(var-interface_type,
-var-interface_type-name);
+ program_resource_visitor::process(var-interface_type,
+ var-interface_type-name);
else
- uniform_field_visitor::process(var);
+ program_resource_visitor::process(var);
}
/**
@@ -258,7 +258,7 @@ private:
* the \c
[Mesa-dev] [PATCH 3/4] glsl: Use parse_program_resource_name to parse transform feedback varyings.
Previously, transform feedback varyings were parsed in an ad-hoc
fashion that wasn't compatible with structs (or array of structs).
This patch makes it use parse_program_resource_name(), which correctly
handles both.
Note that parse_program_resource_name()'s technique for handling
mal-formed input strings is to simply let them through and rely on the
fact that a future name lookup will fail. Because of this,
tfeedback_decl::init() no longer needs to return a boolean error
code--it always suceeds, and if the input was mal-formed the error
will be detected later.
NOTE: This is a candidate for the 9.1 branch.
---
src/glsl/link_varyings.cpp | 33 +++--
src/glsl/link_varyings.h | 2 +-
2 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 25681d6..980b8d0 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -35,6 +35,7 @@
#include linker.h
#include link_varyings.h
#include main/macros.h
+#include program.h
/**
@@ -154,10 +155,13 @@ cross_validate_outputs_to_inputs(struct gl_shader_program
*prog,
/**
* Initialize this object based on a string that was passed to
- * glTransformFeedbackVaryings. If there is a parse error, the error is
- * reported using linker_error(), and false is returned.
+ * glTransformFeedbackVaryings.
+ *
+ * If the input is mal-formed, this call still succeeds, but it sets
+ * this-var_name to a mal-formed input, so tfeedback_decl::find_output_var()
+ * will fail to find any matching variable.
*/
-bool
+void
tfeedback_decl::init(struct gl_context *ctx, struct gl_shader_program *prog,
const void *mem_ctx, const char *input)
{
@@ -175,7 +179,7 @@ tfeedback_decl::init(struct gl_context *ctx, struct
gl_shader_program *prog,
/* Parse gl_NextBuffer. */
if (strcmp(input, gl_NextBuffer) == 0) {
this-next_buffer_separator = true;
- return true;
+ return;
}
/* Parse gl_SkipComponents. */
@@ -189,21 +193,17 @@ tfeedback_decl::init(struct gl_context *ctx, struct
gl_shader_program *prog,
this-skip_components = 4;
if (this-skip_components)
- return true;
+ return;
}
/* Parse a declaration. */
- const char *bracket = strrchr(input, '[');
-
- if (bracket) {
- this-var_name = ralloc_strndup(mem_ctx, input, bracket - input);
- if (sscanf(bracket, [%u], this-array_subscript) != 1) {
- linker_error(prog, Cannot parse transform feedback varying %s,
input);
- return false;
- }
+ const char *base_name_end;
+ long subscript = parse_program_resource_name(input, base_name_end);
+ this-var_name = ralloc_strndup(mem_ctx, input, base_name_end - input);
+ if (subscript = 0) {
+ this-array_subscript = subscript;
this-is_subscripted = true;
} else {
- this-var_name = ralloc_strdup(mem_ctx, input);
this-is_subscripted = false;
}
@@ -215,8 +215,6 @@ tfeedback_decl::init(struct gl_context *ctx, struct
gl_shader_program *prog,
strcmp(this-var_name, gl_ClipDistance) == 0) {
this-is_clip_distance_mesa = true;
}
-
- return true;
}
@@ -449,8 +447,7 @@ parse_tfeedback_decls(struct gl_context *ctx, struct
gl_shader_program *prog,
char **varying_names, tfeedback_decl *decls)
{
for (unsigned i = 0; i num_names; ++i) {
- if (!decls[i].init(ctx, prog, mem_ctx, varying_names[i]))
- return false;
+ decls[i].init(ctx, prog, mem_ctx, varying_names[i]);
if (!decls[i].is_varying())
continue;
diff --git a/src/glsl/link_varyings.h b/src/glsl/link_varyings.h
index 057e4b2..806bd1c 100644
--- a/src/glsl/link_varyings.h
+++ b/src/glsl/link_varyings.h
@@ -48,7 +48,7 @@ class ir_variable;
class tfeedback_decl
{
public:
- bool init(struct gl_context *ctx, struct gl_shader_program *prog,
+ void init(struct gl_context *ctx, struct gl_shader_program *prog,
const void *mem_ctx, const char *input);
static bool is_same(const tfeedback_decl x, const tfeedback_decl y);
bool assign_location(struct gl_context *ctx, struct gl_shader_program *prog,
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] glsl: Support transform feedback of varying structs.
Since transform feedback needs to be able to access individual fields
of varying structs, we can no longer match up the arguments to
glTransformFeedbackVaryings() with variables in the vertex shader.
Instead, we build up a hashtable which records information about each
possible name that is a candidate for transform feedback, and then
match up the arguments to glTransformFeedbackVaryings() with the
contents of that hashtable.
Populating the hashtable uses the program_resource_visitor
infrastructure, which so the logic is shared with how we handle
uniforms.
NOTE: This is a candidate for the 9.1 branch.
---
src/glsl/link_varyings.cpp | 194 ++---
src/glsl/link_varyings.h | 57 -
2 files changed, 184 insertions(+), 67 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 980b8d0..e2cb46e 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -35,6 +35,7 @@
#include linker.h
#include link_varyings.h
#include main/macros.h
+#include program/hash_table.h
#include program.h
@@ -174,6 +175,7 @@ tfeedback_decl::init(struct gl_context *ctx, struct
gl_shader_program *prog,
this-is_clip_distance_mesa = false;
this-skip_components = 0;
this-next_buffer_separator = false;
+ this-matched_candidate = NULL;
if (ctx-Extensions.ARB_transform_feedback3) {
/* Parse gl_NextBuffer. */
@@ -238,27 +240,32 @@ tfeedback_decl::is_same(const tfeedback_decl x, const
tfeedback_decl y)
/**
- * Assign a location for this tfeedback_decl object based on the location
- * assignment in output_var.
+ * Assign a location for this tfeedback_decl object based on the transform
+ * feedback candidate found by find_candidate.
*
* If an error occurs, the error is reported through linker_error() and false
* is returned.
*/
bool
tfeedback_decl::assign_location(struct gl_context *ctx,
-struct gl_shader_program *prog,
-ir_variable *output_var)
+struct gl_shader_program *prog)
{
assert(this-is_varying());
- if (output_var-type-is_array()) {
+ unsigned fine_location
+ = this-matched_candidate-toplevel_var-location * 4
+ + this-matched_candidate-toplevel_var-location_frac
+ + this-matched_candidate-offset;
+
+ if (this-matched_candidate-type-is_array()) {
/* Array variable */
const unsigned matrix_cols =
- output_var-type-fields.array-matrix_columns;
+ this-matched_candidate-type-fields.array-matrix_columns;
const unsigned vector_elements =
- output_var-type-fields.array-vector_elements;
+ this-matched_candidate-type-fields.array-vector_elements;
unsigned actual_array_size = this-is_clip_distance_mesa ?
- prog-Vert.ClipDistanceArraySize : output_var-type-array_size();
+ prog-Vert.ClipDistanceArraySize :
+ this-matched_candidate-type-array_size();
if (this-is_subscripted) {
/* Check array bounds. */
@@ -269,22 +276,11 @@ tfeedback_decl::assign_location(struct gl_context *ctx,
actual_array_size);
return false;
}
- if (this-is_clip_distance_mesa) {
-this-location =
- output_var-location + this-array_subscript / 4;
-this-location_frac = this-array_subscript % 4;
- } else {
-unsigned fine_location
- = output_var-location * 4 + output_var-location_frac;
-unsigned array_elem_size = vector_elements * matrix_cols;
-fine_location += array_elem_size * this-array_subscript;
-this-location = fine_location / 4;
-this-location_frac = fine_location % 4;
- }
+ unsigned array_elem_size = this-is_clip_distance_mesa ?
+1 : vector_elements * matrix_cols;
+ fine_location += array_elem_size * this-array_subscript;
this-size = 1;
} else {
- this-location = output_var-location;
- this-location_frac = output_var-location_frac;
this-size = actual_array_size;
}
this-vector_elements = vector_elements;
@@ -292,7 +288,7 @@ tfeedback_decl::assign_location(struct gl_context *ctx,
if (this-is_clip_distance_mesa)
this-type = GL_FLOAT;
else
- this-type = output_var-type-fields.array-gl_type;
+ this-type = this-matched_candidate-type-fields.array-gl_type;
} else {
/* Regular variable (scalar, vector, or matrix) */
if (this-is_subscripted) {
@@ -301,13 +297,13 @@ tfeedback_decl::assign_location(struct gl_context *ctx,
this-orig_name, this-var_name);
return false;
}
- this-location = output_var-location;
- this-location_frac = output_var-location_frac;
this-size = 1;
- this-vector_elements = output_var-type-vector_elements;
-
Re: [Mesa-dev] [PATCH 3/3] R600: Add support for SET*_DX10 instructions
From: Tom Stellard thomas.stellard at amd.com
These instructions compare two floating point values and return an
integer true (-1) or false (0) value.
When compiling code generated by the Mesa GLSL frontend, the SET*_DX10
instructions save us four instructions for most branch decisions that
use floating-point comparisons.
---
lib/Target/R600/R600ISelLowering.cpp | 108 +++---
lib/Target/R600/R600Instructions.td | 52 +
test/CodeGen/R600/fcmp.ll|4 +-
test/CodeGen/R600/set-dx10.ll| 137
++
test/CodeGen/R600/unsuported-cc.ll | 24 +++---
5 files changed, 281 insertions(+), 44 deletions(-)
create mode 100644 test/CodeGen/R600/set-dx10.ll
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Target/R600/R600ISelLowering.cpp
index abfee16..c4aa172 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target/R600/R600ISelLowering.cpp
@@ -90,7 +90,9 @@ R600TargetLowering::R600TargetLowering(TargetMachine TM)
:
setOperationAction(ISD::FrameIndex, MVT::i32, Custom);
setTargetDAGCombine(ISD::FP_ROUND);
+ setTargetDAGCombine(ISD::FP_TO_SINT);
setTargetDAGCombine(ISD::EXTRACT_VECTOR_ELT);
+ setTargetDAGCombine(ISD::SELECT_CC);
setSchedulingPreference(Sched::VLIW);
}
@@ -663,9 +665,12 @@ SDValue R600TargetLowering::LowerSELECT_CC(SDValue Op,
SelectionDAG DAG) const
}
// Try to lower to a SET* instruction:
- // We need all the operands of SELECT_CC to have the same value type, so
if
- // necessary we need to change True and False to be the same type as LHS
and
- // RHS, and then convert the result of the select_cc back to the correct
type.
+ //
+ // CompareVT == MVT::f32 and VT == MVT::i32 is supported by the hardware,
+ // but for the other case where CompareVT != VT, all operands of
+ // SELECT_CC to have the same value type, so we need to change True and
False
all operands of SELECT_CC to have. Maybe need to have?
+ // to be the same type as LHS and RHS, and then convert the result of the
+ // select_cc back to the correct type.
// Move hardware True/False values to the correct operand.
if (isHWTrueValue(False) isHWFalseValue(True)) {
@@ -675,32 +680,17 @@ SDValue R600TargetLowering::LowerSELECT_CC(SDValue
Op, SelectionDAG DAG) const
}
if (isHWTrueValue(True) isHWFalseValue(False)) {
-if (CompareVT != VT) {
- if (VT == MVT::f32 CompareVT == MVT::i32) {
-SDValue Boolean = DAG.getNode(ISD::SELECT_CC, DL, CompareVT,
-LHS, RHS,
-DAG.getConstant(-1, MVT::i32),
-DAG.getConstant(0, MVT::i32),
-CC);
-// Convert integer values of true (-1) and false (0) to fp values
of
-// true (1.0f) and false (0.0f).
-SDValue LSB = DAG.getNode(ISD::AND, DL, MVT::i32, Boolean,
- DAG.getConstant(1,
MVT::i32));
-return DAG.getNode(ISD::UINT_TO_FP, DL, VT, LSB);
- } else if (VT == MVT::i32 CompareVT == MVT::f32) {
-SDValue BoolAsFlt = DAG.getNode(ISD::SELECT_CC, DL, CompareVT,
-LHS, RHS,
-DAG.getConstantFP(1.0f, MVT::f32),
-DAG.getConstantFP(0.0f, MVT::f32),
-CC);
-// Convert fp values of true (1.0f) and false (0.0f) to integer
values
-// of true (-1) and false (0).
-SDValue Neg = DAG.getNode(ISD::FNEG, DL, MVT::f32, BoolAsFlt);
-return DAG.getNode(ISD::FP_TO_SINT, DL, VT, Neg);
- } else {
-// I don't think there will be any other type pairings.
-assert(!Unhandled operand type parings in SELECT_CC);
- }
+if (CompareVT != VT VT == MVT::f32 CompareVT == MVT::i32) {
+ SDValue Boolean = DAG.getNode(ISD::SELECT_CC, DL, CompareVT,
+ LHS, RHS,
+ DAG.getConstant(-1, MVT::i32),
+ DAG.getConstant(0, MVT::i32),
+ CC);
+ // Convert integer values of true (-1) and false (0) to fp values of
+ // true (1.0f) and false (0.0f).
+ SDValue LSB = DAG.getNode(ISD::AND, DL, MVT::i32, Boolean,
+DAG.getConstant(1,
MVT::i32));
+ return DAG.getNode(ISD::UINT_TO_FP, DL, VT, LSB);
} else {
// This SELECT_CC is already legal.
return DAG.getNode(ISD::SELECT_CC, DL, VT, LHS, RHS, True, False,
CC);
@@ -1121,6 +,35 @@ SDValue R600TargetLowering::PerformDAGCombine(SDNode
*N,
}
break;
}
+
+ // (i32 fp_to_sint (fneg (select_cc f32, f32, 1.0, 0.0 cc))) -
+ // (i32 select_cc f32, f32, -1, 0 cc)
+ //
+ // Mesa's GLSL frontend generates the above pattern a lot and we can
lower
+ // this to one of the SET*_DX10 instructions.
+ case ISD::FP_TO_SINT: {
+SDValue FNeg = N-getOperand(0);
+if (FNeg.getOpcode() != ISD::FNEG) {
+ return SDValue();
+}
+SDValue SelectCC = FNeg.getOperand(0);
+if (SelectCC.getOpcode() != ISD::SELECT_CC ||
+SelectCC.getOperand(0).getValueType() !=
[Mesa-dev] [PATCH 2/2] st/mesa: don't choose DXT formats if we can't do DXT compression
If we call glTexImage2D() with a generic compression format (e.g.
intFormat=GL_COMPRESSED_RGBA) we can't choose a DXT format if we
don't have the external DXT compression library.
We weren't actually enforcing this before since the
pipe_screen::is_format_supported(DXT) query has no dependency on
the DXT compression library.
Now if we're given a generic compressed format and we can't do DXT
compression we'll fall back to a non-compressed format.
Note: This is a candidate for the stable branches.
---
src/mesa/state_tracker/st_cb_drawpixels.c |6 ++-
src/mesa/state_tracker/st_cb_texture.c|2 +-
src/mesa/state_tracker/st_format.c| 47 -
src/mesa/state_tracker/st_format.h|2 +-
src/mesa/state_tracker/st_texture.c |3 +-
5 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
index c944b81..c3c5326 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -1499,14 +1499,16 @@ st_CopyPixels(struct gl_context *ctx, GLint srcx, GLint
srcy,
if (type == GL_DEPTH) {
texFormat = st_choose_format(screen, GL_DEPTH_COMPONENT,
GL_NONE, GL_NONE, st-internal_target,
- sample_count, PIPE_BIND_DEPTH_STENCIL);
+ sample_count, PIPE_BIND_DEPTH_STENCIL,
+ FALSE);
assert(texFormat != PIPE_FORMAT_NONE);
}
else {
/* default color format */
texFormat = st_choose_format(screen, GL_RGBA,
GL_NONE, GL_NONE, st-internal_target,
- sample_count, PIPE_BIND_SAMPLER_VIEW);
+ sample_count, PIPE_BIND_SAMPLER_VIEW,
+ FALSE);
assert(texFormat != PIPE_FORMAT_NONE);
}
}
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 3cea2df..80a440d 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -597,7 +597,7 @@ decompress_with_blit(struct gl_context * ctx,
/* Find the best match for the format+type combo. */
pipe_format = st_choose_format(pipe-screen, GL_RGBA8, format, type,
- pipe_target, 0, bind);
+ pipe_target, 0, bind, FALSE);
if (pipe_format == PIPE_FORMAT_NONE) {
/* unable to get an rgba format!?! */
_mesa_problem(ctx, %s: cannot find a supported format, __func__);
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 7ef0639..c3b286a 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -1397,19 +1397,48 @@ static const struct format_mapping format_map[] = {
/**
+ * Is the given pipe format a DXT format?
+ */
+static boolean
+is_dxt_format(enum pipe_format format)
+{
+ switch (format) {
+ case PIPE_FORMAT_DXT1_RGB:
+ case PIPE_FORMAT_DXT1_RGBA:
+ case PIPE_FORMAT_DXT3_RGBA:
+ case PIPE_FORMAT_DXT5_RGBA:
+ case PIPE_FORMAT_DXT1_SRGB:
+ case PIPE_FORMAT_DXT1_SRGBA:
+ case PIPE_FORMAT_DXT3_SRGBA:
+ case PIPE_FORMAT_DXT5_SRGBA:
+ return TRUE;
+ default:
+ return FALSE;
+ }
+}
+
+
+/**
* Return first supported format from the given list.
+ * \param allow_dxt indicates whether it's OK to return a DXT format.
*/
static enum pipe_format
find_supported_format(struct pipe_screen *screen,
const enum pipe_format formats[],
enum pipe_texture_target target,
unsigned sample_count,
- unsigned tex_usage)
+ unsigned tex_usage,
+ boolean allow_dxt)
{
uint i;
for (i = 0; formats[i]; i++) {
if (screen-is_format_supported(screen, formats[i], target,
sample_count, tex_usage)) {
+ if (!allow_dxt is_dxt_format(formats[i])) {
+/* we can't return a dxt format, continue searching */
+continue;
+ }
+
return formats[i];
}
}
@@ -1519,7 +1548,7 @@ enum pipe_format
st_choose_format(struct pipe_screen *screen, GLenum internalFormat,
GLenum format, GLenum type,
enum pipe_texture_target target, unsigned sample_count,
- unsigned bindings)
+ unsigned bindings, boolean allow_dxt)
{
GET_CURRENT_CONTEXT(ctx); /* XXX this should be a function parameter */
int i, j;
@@ -1547,7 +1576,8 @@ st_choose_format(struct pipe_screen *screen, GLenum
internalFormat,
* which is supported by the driver.
*/
return find_supported_format(screen,
[Mesa-dev] [PATCH 1/2] mesa: don't use format chooser code for glCompressedTexImage
When glCompressedTexImage is called the internalFormat is a specific
format for the incoming image and the the hardware format should be
the same (since we never do format transcoding). So use the simpler
_mesa_glenum_to_compressed_format() function. This change is also
needed for the next patch.
Note: This is a candidate for the stable branches.
--
Note: I haven't completed my full piglit regression test yet but I
wanted to get this out for review anyway.
---
src/mesa/main/teximage.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index f03e84a..ff3c92c 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -3004,8 +3004,18 @@ teximage(struct gl_context *ctx, GLboolean compressed,
GLuint dims,
texObj = _mesa_get_current_tex_object(ctx, target);
assert(texObj);
- texFormat = _mesa_choose_texture_format(ctx, texObj, target, level,
- internalFormat, format, type);
+ if (compressed) {
+ /* For glCompressedTexImage() the driver has no choice about the
+ * texture format since we'll never transcode the user's compressed
+ * image data. The internalFormat was error checked earlier.
+ */
+ texFormat = _mesa_glenum_to_compressed_format(internalFormat);
+ }
+ else {
+ texFormat = _mesa_choose_texture_format(ctx, texObj, target, level,
+ internalFormat, format, type);
+ }
+
assert(texFormat != MESA_FORMAT_NONE);
/* check that width, height, depth are legal for the mipmap level */
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: RFC: ISA information tables and shader disassembler
On 02/01/2013 01:53 AM, Marek Olšák wrote: Do you plan to merge this branch anytime soon? Sorry, I almost forgot about that. Though, in theory, I'd like to get some testing reports first confirming that it doesn't break everything for the non-evergreen chips (I can only test on evergreen), but I guess the problems (if any) may be sorted out in master. I'll rebase updated version on the current master and test if it still works without regressions at least on evergreen, then I'll push it, probably in a few hours. Vadim Marek On Sat, Dec 29, 2012 at 5:36 PM, Vadim Girlin vadimgir...@gmail.com wrote: The patches are pretty big so you can find the branch here: http://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-disasm My primary goal was to have a shader disassembler in the driver to simplify the debugging. The disassembler itself is small, but it relies on the big patch that introduces the tables with ISA information - names of the instructions, opcodes for different chip classes, flags to simplify instruction classification, etc. Although the disassembler needs the names only, I had the complete tables already prepared for other work on shader optimization, so I think that it makes sense to use other stuff as well while I'm at it. All bytecode structs now contain the indices of instruction records in the tables instead of native opcodes - this allows easy access to all related information in the tables - e.g. number of operands for alu instructions, native opcode for current chip class, etc. Also this allows to use single id for instruction even if it has different opcodes on different chips, that is, e.g. we don't have to check for all possible opcodes to say that current instruction is DOT4, we can simply compare alu-op with ALU_OP2_DOT4 constant that represents the index in the table, so this simplifies the processing of the shader code. Also alu table contains the information about allowed slots (vector/scalar) for different chip classes and some additional flags - e.g. instead of comparing some opcode with all possible KILLxx opcodes we can simply check the flag that is set in the table for all KILLxx instructions. The branch was tested on evergreen and there are no regressions with both shader backends (llvm and old), but I won't be surprised if there are bugs for another chip classes. I'll appreciate testing on r6xx/r7xx/cayman, but be ready to possible lockups etc. New disassembler can be activated with R600_DUMP_SHADERS=2. R600_DUMP_SHADERS=1 still uses old dump method, 3 - produces both dumps for every shader. Vadim ___ 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 59494] [Bisected]Piglit glean_depthStencil fails
https://bugs.freedesktop.org/show_bug.cgi?id=59494 lu hua huax...@intel.com changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #5 from lu hua huax...@intel.com --- Verified. Fixed by commit a527b2192e3cb4a68af927ab405e38181d2fcf75. commit a527b2192e3cb4a68af927ab405e38181d2fcf75 Author: Matt Turner Date: Tue Jan 29 16:35:30 2013 -0800 Revert mesa: Return INVALID_OPERATION when type is known but not allowed This reverts commit 2906e2034c9d674601960a5b586b6e986e6ef04f. Fixes a regression in the glean depthStencil test. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] r600g: report correct flow control depth, taking hardware bugs into account
On 02/01/2013 03:20 AM, Marek Olšák wrote:
---
src/gallium/drivers/r600/r600_pipe.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index a59578d..1698cb3 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -640,6 +640,8 @@ static float r600_get_paramf(struct pipe_screen* pscreen,
static int r600_get_shader_param(struct pipe_screen* pscreen, unsigned
shader, enum pipe_shader_cap param)
{
+ struct r600_screen *rscreen = (struct r600_screen *)pscreen;
+
switch(shader)
{
case PIPE_SHADER_FRAGMENT:
@@ -654,7 +656,6 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
return 0;
}
- /* XXX: all these should be fixed, since r600 surely supports much
more! */
switch (param) {
case PIPE_SHADER_CAP_MAX_INSTRUCTIONS:
case PIPE_SHADER_CAP_MAX_ALU_INSTRUCTIONS:
@@ -662,7 +663,11 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
case PIPE_SHADER_CAP_MAX_TEX_INDIRECTIONS:
return 16384;
case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH:
- return 8; /* XXX */
+ /* There is a bug on certain Evergreen cards which limits
+* the control flow depth. */
+ return rscreen-chip_class == EVERGREEN
+ rscreen-family != CHIP_CYPRESS
+ rscreen-family != CHIP_HEMLOCK ? 3 : 32;
I guess we can use more strict condition regarding the affected chips if
the bug description in the evergreen isa pdf is correct (Chapter 4. ALU
Clauses):
NOTE: For the 54xx and 55xx AMD GPU series only, the CF_INST_ALU*
instructions do not save the active mask correctly. The branching can be wrong,
possibly producing incorrect results and infinite loops. The three possible
work-
arounds are:
a. Avoid using the CF_ALU_PUSH_BEFORE, CF_ALU_ELSE_AFTER
CF_ALU_BREAK, and CF_ALU_CONTINUE instructions.
b. Do not use the CF_INST_ALU* instructions when your stack depth
exceeds three elements (not entries); for the 54XX series AMD GPUs,
do not exceed a stack size of seven, since this GPU series has a vector
size 32.
c. Do not use these instructions when your non-zero stack depth mod 4 is
0 (or mod 8 is 0, for vector size 32).
E.g. it seems juniper isn't affected according to the doc.
Also I'm not sure how the meaning of the max control flow depth in
gallium maps to the hw's meaning - I suspect each loop is counted as a
single level, but hw uses 4 or 8 stack elements (subentries) per loop
(EG ISA PDF, Section 3.6.5 Stack Allocation). So it seems we can't use
ALU_xxx instructions even in a single top-level loop on affected chips,
if I understand it right.
Vadim
case PIPE_SHADER_CAP_MAX_INPUTS:
return 32;
case PIPE_SHADER_CAP_MAX_TEMPS:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radeonsi: port some of get_shader_param changes from r600g
On Fre, 2013-02-01 at 00:20 +0100, Marek Olšák wrote:
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
index 471dd48..860e70f 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
@@ -438,7 +438,6 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
return 0;
}
- /* TODO: all these should be fixed, since r600 surely supports much
more! */
switch (param) {
case PIPE_SHADER_CAP_MAX_INSTRUCTIONS:
case PIPE_SHADER_CAP_MAX_ALU_INSTRUCTIONS:
@@ -446,12 +445,9 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
case PIPE_SHADER_CAP_MAX_TEX_INDIRECTIONS:
return 16384;
case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH:
- return 8; /* FIXME */
+ return 32;
case PIPE_SHADER_CAP_MAX_INPUTS:
- if(shader == PIPE_SHADER_FRAGMENT)
- return 34;
- else
- return 32;
+ return 32;
case PIPE_SHADER_CAP_MAX_TEMPS:
return 256; /* Max native temporaries. */
case PIPE_SHADER_CAP_MAX_ADDRS:
Reviewed-by: Michel Dänzer michel.daen...@amd.com
P.S. The subject of patch 1 should say 'control flow' instead of 'flow
control'. :)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 60143] gbm_dri_bo_create fails to initialize bo-base.base.format
https://bugs.freedesktop.org/show_bug.cgi?id=60143 Daniel van Vugt daniel.van.v...@canonical.com changed: What|Removed |Added See Also||https://launchpad.net/bugs/ ||1112147 -- 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 60143] gbm_dri_bo_create fails to initialize bo-base.base.format
https://bugs.freedesktop.org/show_bug.cgi?id=60143 --- Comment #1 from Daniel van Vugt daniel.van.v...@canonical.com --- Or even simpler fix... bo-base.base.format = format; -- 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] GL_INVALID_OPERATION in glFramebufferTexture2D(textarget=0x3)
Hi, I am getting the following error while using glFramebufferTexture2D in mesa es2 demos in mesa-9.0.2 and mesa-8.0.4 code . Can you please let me know, how to resolve this error. GL_INVALID_OPERATION in glFramebufferTexture2D(textarget=0x3) Thanks and Regards, Ramesh CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] swrast: Fix memory leak.
Fixes resource leak defect reported by Coverity. Signed-off-by: Vinson Lee v...@freedesktop.org --- src/mesa/drivers/dri/swrast/swrast.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/drivers/dri/swrast/swrast.c b/src/mesa/drivers/dri/swrast/swrast.c index 9638271..b380de3 100644 --- a/src/mesa/drivers/dri/swrast/swrast.c +++ b/src/mesa/drivers/dri/swrast/swrast.c @@ -363,6 +363,7 @@ swrast_new_renderbuffer(const struct gl_config *visual, __DRIdrawable *dPriv, xrb-bpp = 8; break; default: + free(xrb); return NULL; } -- 1.8.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] nvc0: Fix memory leak.
Fixes resource leak defect reported by Coverity. Signed-off-by: Vinson Lee v...@freedesktop.org --- src/gallium/drivers/nvc0/nvc0_vbo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/nvc0/nvc0_vbo.c b/src/gallium/drivers/nvc0/nvc0_vbo.c index 61a6341..3ae437a 100644 --- a/src/gallium/drivers/nvc0/nvc0_vbo.c +++ b/src/gallium/drivers/nvc0/nvc0_vbo.c @@ -89,6 +89,7 @@ nvc0_vertex_state_create(struct pipe_context *pipe, case 4: fmt = PIPE_FORMAT_R32G32B32A32_FLOAT; break; default: assert(0); +FREE(so); return NULL; } so-element[i].state = nvc0_format_table[fmt].vtx; -- 1.8.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] nv50: Fix memory leak.
Fixes resource leak defect reported by Coverity. Signed-off-by: Vinson Lee v...@freedesktop.org --- src/gallium/drivers/nv50/nv50_vbo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/nv50/nv50_vbo.c b/src/gallium/drivers/nv50/nv50_vbo.c index 6e81b7b..d050062 100644 --- a/src/gallium/drivers/nv50/nv50_vbo.c +++ b/src/gallium/drivers/nv50/nv50_vbo.c @@ -85,6 +85,7 @@ nv50_vertex_state_create(struct pipe_context *pipe, case 4: fmt = PIPE_FORMAT_R32G32B32A32_FLOAT; break; default: assert(0); +FREE(so); return NULL; } so-element[i].state = nv50_format_table[fmt].vtx; -- 1.8.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] nv30: Fix memory leak.
Fixes resource leak defect reported by Coverity. Signed-off-by: Vinson Lee v...@freedesktop.org --- src/gallium/drivers/nv30/nv30_vbo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/nv30/nv30_vbo.c b/src/gallium/drivers/nv30/nv30_vbo.c index 128457f..d7a774f 100644 --- a/src/gallium/drivers/nv30/nv30_vbo.c +++ b/src/gallium/drivers/nv30/nv30_vbo.c @@ -278,6 +278,7 @@ nv30_vertex_state_create(struct pipe_context *pipe, unsigned num_elements, case 4: fmt = PIPE_FORMAT_R32G32B32A32_FLOAT; break; default: assert(0); +FREE(so); return NULL; } so-element[i].state = nv30_vtxfmt(pipe-screen, fmt)-hw; -- 1.8.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] egl/dri2: Fix memory leak.
Fixes resource leak defect reported by Coverity. Signed-off-by: Vinson Lee v...@freedesktop.org --- src/egl/drivers/dri2/egl_dri2.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index 351fbf4..ab06247 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -763,6 +763,7 @@ dri2_create_context(_EGLDriver *drv, _EGLDisplay *disp, _EGLConfig *conf, break; default: _eglError(EGL_BAD_PARAMETER, eglCreateContext); + free(dri2_ctx); return NULL; } -- 1.8.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] r600g: Fix memory leak.
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/drivers/r600/r600_hw_context.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index a89f230..ebcd682 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -201,8 +201,10 @@ int r600_context_add_block(struct r600_context *ctx, const
struct r600_reg *reg,
/* create block table if it doesn't exist */
if (!range-blocks)
range-blocks = calloc(1 HASH_SHIFT,
sizeof(void *));
- if (!range-blocks)
+ if (!range-blocks) {
+ free(block);
return -1;
+ }
range-blocks[CTX_BLOCK_ID(reg[i + j].offset)] = block;
}
--
1.8.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
