[Mesa-dev] [PATCH] st/mesa: remove extra calculation of sampler count
This code was introduced in 5b542681dc05b8b9eba677ee74323ac0ff85a5f0 to fix
https://bugs.freedesktop.org/show_bug.cgi?id=53617 however llvmpipe (and
others) no longer return early if the count doesnt include old views as of
around 177c9be61535a66607e0de9b0ecf00c8d5d451ac.
Also I believe 2355a6441435b8e66a032c44f0794066338e30a3 passes the correct
count but from a better location anyway.
Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
---
src/mesa/state_tracker/st_atom_texture.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index afc6d9d..2ce88e0 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -354,7 +354,7 @@ update_textures(struct st_context *st,
{
const GLuint old_max = *num_textures;
GLbitfield samplers_used = prog-SamplersUsed;
- GLuint unit, new_count;
+ GLuint unit;
if (samplers_used == 0x0 old_max == 0)
return;
@@ -383,16 +383,9 @@ update_textures(struct st_context *st,
pipe_sampler_view_reference((sampler_views[unit]), sampler_view);
}
- /* Ex: if old_max = 3 and *num_textures = 1, we need to pass an
-* array of views={X, NULL, NULL} to unref the old texture views
-* at positions [1] and [2].
-*/
- new_count = MAX2(*num_textures, old_max);
- assert(new_count = max_units);
-
cso_set_sampler_views(st-cso_context,
shader_stage,
- new_count,
+ *num_textures,
sampler_views);
}
--
1.9.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78914] [llvmpipe] Front/Backfaces do not cover the same pixels when rasterized
https://bugs.freedesktop.org/show_bug.cgi?id=78914 --- Comment #2 from Florian Link florianl...@gmail.com --- Created attachment 99394 -- https://bugs.freedesktop.org/attachment.cgi?id=99394action=edit some screenshots showing the problem I rendered the same cube two times, first culling the front faces, then culling the back faces. The backside has a red light, so that backside pixels are draw red. Since the front side is painted, no red pixels should ever be seen. As you can see on the screenshots, there are red pixels on the edges, depending on the angle. -- 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 78773] Doom3 BFG doesnt start
https://bugs.freedesktop.org/show_bug.cgi?id=78773 --- Comment #5 from Jan jan.e...@yandex.com --- Created attachment 99395 -- https://bugs.freedesktop.org/attachment.cgi?id=99395action=edit log file i attached the log file. game also started to lower to my resolution to 640x480 which it didnt do in my first try. -- 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 78914] [llvmpipe] Front/Backfaces do not cover the same pixels when rasterized
https://bugs.freedesktop.org/show_bug.cgi?id=78914 --- Comment #3 from Florian Link florianl...@gmail.com --- So regarding your comment, rasterization of back/front faces with shared edges seems to rasterize to different (at least on some pixels). So it is not about the interpolated vertex attributes, but about the screen pixels. I tested this with LLVM pipe and with softpipe and only LLVM pipe shows the artifacts (softpipe does not show any red pixels in my example setup). The example scene was done using MeVisLab (www.mevislab.de) and the Mesa opengl32.dll with LLVM pipe, I can send you that MeVisLab scene (MeVisLab is free to install). Or do you need a C++ example to reproduce this? -- 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 3/3] Fix build of appleglx
Reviewed-by: Jeremy Huddleston Sequoia jerem...@apple.com with one minor change (see below): On May 13, 2014, at 05:15, Jon TURNEY jon.tur...@dronecode.org.uk wrote: ... diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am index eee7c2c..c18d1c5 100644 --- a/src/glx/Makefile.am +++ b/src/glx/Makefile.am @@ -24,7 +24,7 @@ SHARED_GLAPI_CFLAGS = -DGLX_SHARED_GLAPI SHARED_GLAPI_LIB = $(top_builddir)/src/mapi/shared-glapi/libglapi.la endif -SUBDIRS=. tests +SUBDIRS= if HAVE_XF86VIDMODE EXTRA_DEFINES_XF86VIDMODE = -DXF86VIDMODE @@ -88,6 +88,8 @@ libglx_la_SOURCES = \ drisw_glx.c \ glxhash.c +libglx_la_LIBADD = $(top_builddir)/src/loader/libloader.la + if HAVE_DRICOMMON libglx_la_SOURCES += \ dri_common.c @@ -110,9 +112,10 @@ endif if HAVE_APPLEDRI libglx_la_SOURCES += \ applegl_glx.c -endif -libglx_la_LIBADD = $(top_builddir)/src/loader/libloader.la +SUBDIRS += apple +libglx_la_LIBADD += $(builddir)/apple/libappleglx.la +endif GL_LIBS = \ libglx.la \ @@ -131,4 +134,6 @@ lib@GL_LIB@_la_SOURCES = lib@GL_LIB@_la_LIBADD = $(GL_LIBS) lib@GL_LIB@_la_LDFLAGS = $(GL_LDFLAGS) +SUBDIRS+=. tests + include $(top_srcdir)/install-lib-links.mk Because SUBDIRS is set conditionally, you should add: DIST_SUBDIRS = tests apple to handle what I assume is an eventual goal of supporting 'make dist' ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] Make DRI dependencies and build depend on the target
Reviewed-by: Jeremy Huddleston Sequoia jerem...@apple.com On May 13, 2014, at 05:15, Jon TURNEY jon.tur...@dronecode.org.uk wrote: - Don't require xcb-dri[23] etc. if we aren't building for a target with DRM, as we won't be using dri[23] - Enable a more fine-grained control of what DRI code is built, so that a libGL using direct swrast can be built on targets which don't have DRM. The HAVE_DRI automake conditional is retired in favour of a number of other conditionals: HAVE_DRI2 enables building of code using the DRI2 interface (and possibly DRI3 with HAVE_DRI3) HAVE_DRISW enables building of DRI swrast HAVE_DRICOMMON enables building of target-independent DRI code, and also enables some makefile cases where a more detailled decision is made at a lower level. HAVE_APPLEDRI enables building of an Apple-specific direct rendering interface, still which requires additional fixing up to build properly. Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- configure.ac | 55 +- src/gallium/state_trackers/Makefile.am | 2 +- src/gallium/state_trackers/dri/Makefile.am | 6 +++- src/gallium/targets/Makefile.am| 18 +- src/gallium/targets/gbm/Makefile.am| 2 +- src/gallium/targets/opencl/Makefile.am | 2 +- src/gallium/targets/xa/Makefile.am | 2 +- src/gallium/tests/trivial/Makefile.am | 2 +- src/gallium/winsys/Makefile.am | 2 +- src/gbm/Makefile.am| 2 +- src/glx/Makefile.am| 20 --- src/mesa/Makefile.am | 2 +- 12 files changed, 77 insertions(+), 38 deletions(-) diff --git a/configure.ac b/configure.ac index f571af1..6eeb2ea 100644 --- a/configure.ac +++ b/configure.ac @@ -765,8 +765,22 @@ fi AM_CONDITIONAL(HAVE_DRI_GLX, test x$enable_glx = xyes -a \ x$enable_dri = xyes) -AM_CONDITIONAL(HAVE_DRI, test x$enable_dri = xyes) -AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes) + +# Select which platform-dependent DRI code gets built +case $host_os in +darwin*) +dri_platform='apple' ;; +gnu*|mingw*|cygwin*) +dri_platform='none' ;; +*) +dri_platform='drm' ;; +esac + +AM_CONDITIONAL(HAVE_DRICOMMON, test x$enable_dri = xyes ) +AM_CONDITIONAL(HAVE_DRISW, test x$enable_dri = xyes ) +AM_CONDITIONAL(HAVE_DRI2, test x$enable_dri = xyes test x$dri_platform = xdrm ) +AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes test x$dri_platform = xdrm ) +AM_CONDITIONAL(HAVE_APPLEDRI, test x$enable_dri = xyes test x$dri_platform = xapple ) AC_ARG_ENABLE([shared-glapi], [AS_HELP_STRING([--enable-shared-glapi], @@ -891,23 +905,30 @@ xyesyes) xyesno) # DRI-based GLX PKG_CHECK_MODULES([GLPROTO], [glproto = $GLPROTO_REQUIRED]) -if test x$driglx_direct = xyes; then -if test x$have_libdrm != xyes; then -AC_MSG_ERROR([Direct rendering requires libdrm = $LIBDRM_REQUIRED]) -fi -PKG_CHECK_MODULES([DRI2PROTO], [dri2proto = $DRI2PROTO_REQUIRED]) -GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV libdrm = $LIBDRM_REQUIRED -if test x$enable_dri3 = xyes; then -PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED]) -PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = $PRESENTPROTO_REQUIRED]) -fi -fi # find the DRI deps for libGL -dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = $XCBGLX_REQUIRED xcb-dri2 = $XCBDRI2_REQUIRED +dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = $XCBGLX_REQUIRED -if test x$enable_dri3 = xyes; then -dri_modules=$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence = $XSHMFENCE_REQUIRED +if test x$driglx_direct = xyes; then +if test x$dri_platform = xdrm ; then +if test x$have_libdrm != xyes; then + AC_MSG_ERROR([Direct rendering requires libdrm = $LIBDRM_REQUIRED]) +fi + +PKG_CHECK_MODULES([DRI2PROTO], [dri2proto = $DRI2PROTO_REQUIRED]) +GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV libdrm = $LIBDRM_REQUIRED +if test x$enable_dri3 = xyes; then + PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = $DRI3PROTO_REQUIRED]) + PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = $PRESENTPROTO_REQUIRED]) +fi + +if test x$enable_dri = xyes; then + dri_modules=$dri_modules xcb-dri2 = $XCBDRI2_REQUIRED +fi + +if test x$enable_dri3 = xyes; then + dri_modules=$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence = $XSHMFENCE_REQUIRED +fi fi # add xf86vidmode if available @@ -2253,7 +2274,9 @@ xnono) ;; esac +echo if test x$enable_dri != xno; then +echo DRI platform:$dri_platform if test
Re: [Mesa-dev] [PATCH 16/23] targets/vdpau: convert to static and shared pipe-drivers
On 20/05/14 04:49, Jonathan Gray wrote: On Mon, May 19, 2014 at 11:57:58PM +0100, Emil Velikov wrote: On 18/05/14 12:22, Jonathan Gray wrote: [snip] Currently I run my autotools builds like this: export LDFLAGS=-L/usr/local/lib export CPPFLAGS=-I/usr/local/include -I/usr/local/include/libelf export AUTOMAKE_VERSION=1.12 export AUTOCONF_VERSION=2.69 export LEX=/usr/local/bin/gflex ./autogen.sh \ --with-gallium-drivers=r300,r600,radeonsi,swrast,nouveau \ --with-dri-drivers=i915,i965,r200,radeon,swrast \ --disable-silent-rules \ --enable-r600-llvm-compiler --enable-gallium-llvm \ --disable-llvm-shared-libs \ --enable-gles1 --enable-gles2 \ --enable-shared-glapi \ --disable-osmesa \ --enable-debug \ --enable-gbm \ --with-egl-platforms=x11,drm \ --prefix=/usr/mesa I'm a bit curious how xenocara's CVS is going to handle the symlinks when building dri/radeon, dri/r200 and st/dri (all gallium dri drivers). AFAICS it will fail miserably :\ If interested you can rework the former two and effectively drop a handful symbol redefinition, shed off some code and size off the classic dri. I'm planning to address the st/dri case after this series is merged. I'm not really sure what xenocara has to do with the autotools build? As said before xenocara uses it's own set of makefiles, ie http://www.openbsd.org/cgi-bin/cvsweb/xenocara/lib/libGL/dri/radeon/Makefile?rev=HEAD;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/xenocara/lib/libGL/dri/r600g/Makefile?rev=HEAD;content-type=text%2Fplain with seperate directories for libglapi libGL libEGL libGLESv1_CM libGLESv2 that refer to the source in http://www.openbsd.org/cgi-bin/cvsweb/xenocara/dist/Mesa/ Hmm... I assumed that the openbsd makefiles were a mere stripped down version of the ones generated by autohell. Seem like that is not the case :\ FWIW you guys can reuse the Makefile.sources if interested. From the above configure one cannot determine if you're building vdpau. Current code enables the vdpau targets if the vdpau package is available. Can you confirm if this is the case or not ? My autotools builds are not done on a system with vdpau installed. The resulting target list from configure here looks like: Gallium: yes Target dirs: dri-nouveau dri-swrast r300/dri r600/dri radeonsi/dri Winsys dirs: nouveau/drm radeon/drm sw sw/dri sw/xlib Driver dirs: galahad identity llvmpipe noop nouveau r300 r600 radeonsi rbug softpipe trace Trackers dirs: dri The build does not seem to reference gallium/state_trackers/vdpau but does build mesa/main/vdpau.c and mesa/state_tracker/st_vdpau.c It would be nice to have the possibility of building the gallium vdpau code in future however. Yes it would be very nice to have. I'm not sure that classifies as regression, as you haven't really built/used them. With that said the plan is to revisit the messy symlink creation at a later stage. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/23] scons: remove dri-i915 build target
Acked-by: Jakob Bornecrantz wallbra...@gmail.com
On Sun, May 18, 2014 at 9:07 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
Unmaintained and broken.
Cc: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
scons/gallium.py | 1 -
src/gallium/SConscript| 9 -
src/gallium/targets/dri-i915/SConscript | 29 -
src/gallium/targets/egl-static/SConscript | 9 -
src/gallium/winsys/i915/drm/SConscript| 14 --
5 files changed, 62 deletions(-)
delete mode 100644 src/gallium/targets/dri-i915/SConscript
delete mode 100644 src/gallium/winsys/i915/drm/SConscript
diff --git a/scons/gallium.py b/scons/gallium.py
index 5109ebf..4c194aa 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -591,7 +591,6 @@ def generate(env):
env.PkgCheckModules('XCB', ['x11-xcb', 'xcb-glx = 1.8.1'])
env.PkgCheckModules('XF86VIDMODE', ['xxf86vm'])
env.PkgCheckModules('DRM', ['libdrm = 2.4.38'])
-env.PkgCheckModules('DRM_INTEL', ['libdrm_intel = 2.4.52'])
env.PkgCheckModules('UDEV', ['libudev = 151'])
env['dri'] = env['x11'] and env['drm']
diff --git a/src/gallium/SConscript b/src/gallium/SConscript
index 32bbdbe..816c79c 100644
--- a/src/gallium/SConscript
+++ b/src/gallium/SConscript
@@ -85,11 +85,6 @@ if env['dri']:
'winsys/svga/drm/SConscript',
])
-if env['drm_intel']:
-SConscript([
-'winsys/i915/drm/SConscript',
-])
-
#
# Targets
#
@@ -126,10 +121,6 @@ if not env['embedded']:
'targets/dri-swrast/SConscript',
'targets/dri-vmwgfx/SConscript',
])
-if env['drm_intel']:
-SConscript([
-'targets/dri-i915/SConscript',
-])
#
diff --git a/src/gallium/targets/dri-i915/SConscript
b/src/gallium/targets/dri-i915/SConscript
deleted file mode 100644
index b3bd3dd..000
--- a/src/gallium/targets/dri-i915/SConscript
+++ /dev/null
@@ -1,29 +0,0 @@
-Import('*')
-
-env = drienv.Clone()
-
-env.PkgUseModules('DRM_INTEL')
-
-env.Append(CPPDEFINES = ['GALLIUM_RBUG', 'GALLIUM_TRACE', 'GALLIUM_GALAHAD'])
-
-env.Prepend(LIBS = [
-ws_wrapper,
-st_dri,
-i915drm,
-i915,
-galahad,
-trace,
-rbug,
-mesa,
-glsl,
-gallium,
-COMMON_DRI_DRM_OBJECTS
-])
-
-module = env.LoadableModule(
-target = 'i915_dri.so',
-source = 'target.c',
-SHLIBPREFIX = '',
-)
-
-env.Alias('dri-i915', module)
diff --git a/src/gallium/targets/egl-static/SConscript
b/src/gallium/targets/egl-static/SConscript
index 83937fe..afb5c11 100644
--- a/src/gallium/targets/egl-static/SConscript
+++ b/src/gallium/targets/egl-static/SConscript
@@ -91,15 +91,6 @@ if env['HAVE_X11']:
if env['HAVE_DRM']:
env.PkgUseModules('DRM')
-if env['HAVE_DRM_INTEL']:
-env.PkgUseModules('DRM_INTEL')
-env.Append(CPPDEFINES = ['_EGL_PIPE_I915'])
-env.Prepend(LIBS = [
-i915drm,
-i915,
-ws_wrapper,
-])
-
env.Append(CPPDEFINES = ['_EGL_PIPE_VMWGFX'])
env.Prepend(LIBS = [
svgadrm,
diff --git a/src/gallium/winsys/i915/drm/SConscript
b/src/gallium/winsys/i915/drm/SConscript
deleted file mode 100644
index 3d27628..000
--- a/src/gallium/winsys/i915/drm/SConscript
+++ /dev/null
@@ -1,14 +0,0 @@
-Import('*')
-
-env = env.Clone()
-
-env.PkgUseModules('DRM')
-
-i915drm_sources = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
-
-i915drm = env.ConvenienceLibrary(
-target ='i915drm',
-source = i915drm_sources,
-)
-
-Export('i915drm')
--
1.9.2
___
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 78914] [llvmpipe] Front/Backfaces do not cover the same pixels when rasterized
https://bugs.freedesktop.org/show_bug.cgi?id=78914 --- Comment #4 from Roland Scheidegger srol...@vmware.com --- I agree this looks like a rasterization problem. I'll look into it when I find some time. Right now I have no idea why that happens - there's the code which would rotate the vertices but this all happens with fixed point thus it should still produce the same fragments afaict. But there might be a bug in this logic somewhere. The more easy it is to reproduce the better. If you could get a apitrace that would be helpful. -- 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] mesa: Expose GL_OES_texture_float and GL_OES_texture_half_float.
On Tue, May 20, 2014 at 7:38 AM, Rogovin, Kevin kevin.rogo...@intel.com wrote: For OpenGL ES, I propose a simpler solution: - don't touch ARB_texture_float at all - add OES_texture_float to gl_extensions - add OES_texture_float_linear to gl_extensions - define OES_texture_half_float as o(OES_texture_float) - define OES_texture_half_float_linear as o(OES_texture_float_linear) Then, drivers can enable the extensions as they see fit. That sounds like a happy medium. It seems like we could use ARB_texture_float as the enable for OES_texture_float, but I'm not crying over one extra flag. I think it is actually the most unhappy medium. The patch as-is enable floating point textures in GLES2 on hardware targets without affecting any DRI drivers (or the Gallium state tracker). That was the original purpose of the patch. On one side: having 4 separate booleans then gives complete resolution to the situation for floating point textures. Having just -2- means that some resolution is provided but it is not complete and will then need to be revisited and leave whoever made or pushed the patch embarrassed about not dotting the i's and crossing the t's. Additionally, adding 2 or 4 and leaving ARB_texture_float, we are still left with the situation that the booleans are not orthogonal. Also, what does ARB_texture_float support then mean? What contract is it satisfying that mesa/main can rely upon? Going further what happens when/if we want to add support for GL_ARB_ES2_compatibility and also expose OES extensions (as NVIDIA does)? [I admit exposing OES extension in a non-ES context sounds gross, but the whole point of ES2_compatibility is to make ports from GLES to GL almost a no-op, so the OES extensions should come too]. It will mean that a bunch of extension checks in the code will need to be expanded. We'll probably also want a negative test that verifies an error is generated for glTexParameteri(..., GL_LINEAR_MIPMAP_LINEAR) when OES_texture_float_linear (or OES_texture_half_float_linear) is not supported. This is the other reason why I do not want to go down the multiple booleans initially as then the patch touches much more code; the all or nothing approach avoided all sorts of additional ickiness. Lets put the patch as-is (because from the point of view of mesa/main it looks correct) and then a subsequent patch, after some discussion, to support situations like the r300 partial floating point texture support. Sounds good to me. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/23] configure: add HAVE_GALLIUM_STATIC_TARGETS
On Sun, May 18, 2014 at 9:07 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Will be used to control the linking mode of pipe-drivers in gallium targets. XXX: Do we want to expose this via configure option ? I'm personally inclined to use pipe-drivers despite the unstable interface between them and the rest of mesa. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index ed80cd9..d802875 100644 --- a/configure.ac +++ b/configure.ac @@ -1985,6 +1985,9 @@ AM_CONDITIONAL(NEED_GALLIUM_LLVMPIPE_DRIVER, test x$HAVE_GALLIUM_I915 = xyes - x$HAVE_GALLIUM_SOFTPIPE = xyes \ test x$MESA_LLVM = x1) +# Disable static gallium targets for now +AM_CONDITIONAL(HAVE_GALLIUM_STATIC_TARGETS, test xyes = xyes) Did you mean to say Enable in the comment above? Marek + # NOTE: anything using xcb or other client side libs ends up in separate # _CLIENT variables. The pipe loader is built in two variants, # one that is standalone and does not link any x client libs (for -- 1.9.2 ___ 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 78914] [llvmpipe] Front/Backfaces do not cover the same pixels when rasterized
https://bugs.freedesktop.org/show_bug.cgi?id=78914 --- Comment #5 from Florian Link florianl...@gmail.com --- Created attachment 99406 -- https://bugs.freedesktop.org/attachment.cgi?id=99406action=edit apitrace of example The rendering is in frame 6, 7 and 9. I don't know how to strip the MeVisLab network rendering from the other frames... -- 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 3/3] Fix build of appleglx
On 20/05/2014 09:57, Jeremy Huddleston Sequoia wrote: Reviewed-by: Jeremy Huddleston Sequoia with one minor change (see below): Thanks very much for taking the time to review these. On May 13, 2014, at 05:15, Jon TURNEY wrote: +SUBDIRS+=. tests + include $(top_srcdir)/install-lib-links.mk Because SUBDIRS is set conditionally, you should add: DIST_SUBDIRS = tests apple to handle what I assume is an eventual goal of supporting 'make dist' I don't think that is needed in this case, as automake should be smart enough to work it out correctly. To quote the automake manual [1]: If SUBDIRS is defined conditionally using Automake conditionals, Automake will define DIST_SUBDIRS automatically from the possible values of SUBDIRS in all conditions. If SUBDIRS contains AC_SUBST variables, DIST_SUBDIRS will not be defined correctly because Automake does not know the possible values of these variables. In this case DIST_SUBDIRS needs to be defined manually. [1] http://www.gnu.org/software/automake/manual/html_node/SUBDIRS-vs-DIST_005fSUBDIRS.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.2 release candidate 3
Hey Ian, I wonder to what extent you might tolerate a late freedreno pull req? I've backported nearly all of the recent freedreno commits on master to a 10.2 based branch: https://github.com/freedreno/mesa/commits/freedreno-10.2 I guess it will be a while before 10.3 makes it in to distros, so it would be kinda nice to get this on 10.2 branch at some point, even if after 10.2.0. Nothing touched anything outside of freedreno, and there has been a pretty healthy increase in piglit passes recently (not to mention gl2.1 support), so seems like a worthwhile thing http://people.freedesktop.org/~robclark/summary/gpu.gl2/A320/index.html BR, -R On Sat, May 17, 2014 at 3:07 AM, Ian Romanick i...@freedesktop.org wrote: Mesa 10.2 release candidate 3 is now available for testing. The current plan of record is to have an additional release candidate each Friday until the 10.2 release on Friday, May 30th. The tag in the GIT repository for Mesa 10.2-rc3 is 'mesa-10.2-rc3'. I have verified that the tag is in the correct place in the tree. Mesa 10.2 release candidate 3 is available for download at ftp://freedesktop.org/pub/mesa/10.2/ md5sums: d6cce0f443073f127a7945d088bfea9e MesaLib-10.2.0-rc3.tar.gz 266264483d5f1e3513f48f95392c15a2 MesaLib-10.2.0-rc3.tar.bz2 0df1c6de88ae80e5282d7812b2d516fe MesaLib-10.2.0-rc3.zip I have verified building from the .tar.bz2 file by doing the following on my aging Fedora 18 system: tar -xjf Mesa-10.2.0-rc3.tar.bz2 cd Mesa-10.2.0-rc3 ./configure --enable-gallium-llvm make -j6 make check make install Changes since mesa-10.2-rc2: Brian Paul (1): mesa: fix double-freeing of dispatch tables inside glBegin/End. Chris Forbes (4): i965/Gen7: Set up layer constraints properly for renderbuffers i965/Gen8: Set up layer constraints properly for renderbuffers i965/Gen7: Set up layer constraints properly for depth buffers i965/Gen8: Set up layer constraints properly for depth buffers Emil Velikov (2): configure: correctly set LD_NO_UNDEFINED docs: Add a note about llvm-shared-libs and libxatracker Ian Romanick (2): Add .cherry-ignore file Bump version to 10.2-rc3 Ilia Mirkin (6): nv50/ir: make sure to reverse cond codes on all the OP_SET variants nv50: fix setting of texture ms info to be per-stage gallium: add bit to pipe_blit_info to leave current query enabled mesa/st: leave current query enabled during glBlitFramebuffer nv50,nvc0: leave queries on during blit, turn them on for 2d engine nv50,nvc0: fix blit 3d path for 1d array textures Jonathan Gray (1): glsl: simplify the M_PI*f macros, fixes build on OpenBSD Jordan Justen (6): i965/gen7 renderbuffer: Set depth size based on LOD0 for 3D textures i965/gen8 renderbuffer: Set depth size based on LOD0 for 3D textures i965/gen7 depth: Set depth size based on LOD0 for 3D textures i965/gen8 depth: Set depth size based on LOD0 for 3D textures i965/gen8: Set depth extent field i965 meta up/downsample: Fix renderbuffer _BaseFormat Kenneth Graunke (1): i965: Don't _swrast_BlitFramebuffer when doing CopyTexSubImage. Kristian Høgsberg (1): wayland: Move version 2 request to end of interface specification Michel Dänzer (2): radeonsi: Fix anisotropic filtering state setup glsl_to_tgsi: Make sure the 'shader' member is always initialized Roland Scheidegger (1): mesa/st: fix number of ubos being declared in a shader Topi Pohjolainen (13): i965/gen8: Use helper variables for surface parameters i965/blorp: Expose coordinate scissoring and mirroring meta: Merge compiling and linking of blit program meta: Refactor binding of renderbuffer as texture image meta: Refactor configuration of renderbuffer sampling i965/wm: Surface state overrides for configuring w-tiled as y-tiled i965/gen8: Surface state overriding for stencil i965: Extend brw_get_rb_for_first_slice() for specified level/layer meta: Refactor state save/restore for framebuffer texture blits i965/meta: Stencil blits i965/fb: Use meta path for stencil blits i965/meta: Stencil blit for miptree updownsampling i965/fb: Use meta path for stencil up/downsampling ___ 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 78773] Doom3 BFG doesnt start
https://bugs.freedesktop.org/show_bug.cgi?id=78773 --- Comment #6 from Brian Paul bri...@vmware.com --- Wasn't Doom 3 one of those older games that had a fixed-size buffer for storing the GL_EXTENSIONS string? If the extension string was too long the buffer would overflow and the game would crash/misbehave. Jan, you might try setting the MESA_EXTENSION_MAX_YEAR env var to something like 2005 so Mesa doesn't advertise extensions newer than that. -- 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 15/23] configure: add HAVE_GALLIUM_STATIC_TARGETS
On 20/05/14 13:08, Marek Olšák wrote: On Sun, May 18, 2014 at 9:07 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Will be used to control the linking mode of pipe-drivers in gallium targets. XXX: Do we want to expose this via configure option ? I'm personally inclined to use pipe-drivers despite the unstable interface between them and the rest of mesa. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index ed80cd9..d802875 100644 --- a/configure.ac +++ b/configure.ac @@ -1985,6 +1985,9 @@ AM_CONDITIONAL(NEED_GALLIUM_LLVMPIPE_DRIVER, test x$HAVE_GALLIUM_I915 = xyes - x$HAVE_GALLIUM_SOFTPIPE = xyes \ test x$MESA_LLVM = x1) +# Disable static gallium targets for now +AM_CONDITIONAL(HAVE_GALLIUM_STATIC_TARGETS, test xyes = xyes) Did you mean to say Enable in the comment above? Good catch. It's a leftover from the use pipe-loader by default approach. What is your opinion about providing a configure switch for it ? Thanks Emil Marek + # NOTE: anything using xcb or other client side libs ends up in separate # _CLIENT variables. The pipe loader is built in two variants, # one that is standalone and does not link any x client libs (for -- 1.9.2 ___ 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 78773] Doom3 BFG doesnt start
https://bugs.freedesktop.org/show_bug.cgi?id=78773 --- Comment #7 from Tapani Pälli lem...@gmail.com --- (In reply to comment #6) Wasn't Doom 3 one of those older games that had a fixed-size buffer for storing the GL_EXTENSIONS string? If the extension string was too long the buffer would overflow and the game would crash/misbehave. Jan, you might try setting the MESA_EXTENSION_MAX_YEAR env var to something like 2005 so Mesa doesn't advertise extensions newer than that. I've verified that original Doom3 works fine with current Mesa. Doom3 here is 'rbdoom3', this is a custom one that uses = OpenGL 3.2: https://github.com/RobertBeckebans/RBDOOM-3-BFG I haven't tried yet but my wild guess is that it uses core profile but still the old deprecated extensions query (not the new one). -- 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 15/23] configure: add HAVE_GALLIUM_STATIC_TARGETS
Well, I have never studied the build system, so I don't know exactly what this series does and how it affects the size of the drivers. Could you please summarize what binaries are created, how big they are, and compare the shared vs static approach vs the current way? And what is the role of the pipe loader? Marek On Tue, May 20, 2014 at 4:18 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 20/05/14 13:08, Marek Olšák wrote: On Sun, May 18, 2014 at 9:07 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Will be used to control the linking mode of pipe-drivers in gallium targets. XXX: Do we want to expose this via configure option ? I'm personally inclined to use pipe-drivers despite the unstable interface between them and the rest of mesa. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index ed80cd9..d802875 100644 --- a/configure.ac +++ b/configure.ac @@ -1985,6 +1985,9 @@ AM_CONDITIONAL(NEED_GALLIUM_LLVMPIPE_DRIVER, test x$HAVE_GALLIUM_I915 = xyes - x$HAVE_GALLIUM_SOFTPIPE = xyes \ test x$MESA_LLVM = x1) +# Disable static gallium targets for now +AM_CONDITIONAL(HAVE_GALLIUM_STATIC_TARGETS, test xyes = xyes) Did you mean to say Enable in the comment above? Good catch. It's a leftover from the use pipe-loader by default approach. What is your opinion about providing a configure switch for it ? Thanks Emil Marek + # NOTE: anything using xcb or other client side libs ends up in separate # _CLIENT variables. The pipe loader is built in two variants, # one that is standalone and does not link any x client libs (for -- 1.9.2 ___ 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] tgsi: add GS_INVOCATIONS to property names array
On 05/20/2014 04:56 AM, Ilia Mirkin wrote: In commit 4be146b1, I neglected to add the new property to the strings array. This leads to the string '(null)' to be printed instead when converting a GS shader to text. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Cc: 10.2 mesa-sta...@lists.freedesktop.org --- src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c b/src/gallium/auxiliary/tgsi/tgsi_strings.c index 5b6e47f..34dec4f 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c @@ -120,7 +120,8 @@ const char *tgsi_property_names[TGSI_PROPERTY_COUNT] = FS_COORD_PIXEL_CENTER, FS_COLOR0_WRITES_ALL_CBUFS, FS_DEPTH_LAYOUT, - VS_PROHIBIT_UCPS + VS_PROHIBIT_UCPS, + GS_INVOCATIONS, }; const char *tgsi_type_names[5] = Reviewed-by: Roland Scheidegger srol...@vmware.com This adds a trailing comma. But some arrays have them, some not, and I have no idea what the convention here should be ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] Fix build of appleglx
On May 20, 2014, at 05:57, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 20/05/2014 09:57, Jeremy Huddleston Sequoia wrote: Reviewed-by: Jeremy Huddleston Sequoia with one minor change (see below): Thanks very much for taking the time to review these. No, thank you for taking the time to do them. On May 13, 2014, at 05:15, Jon TURNEY wrote: +SUBDIRS+=. tests + include $(top_srcdir)/install-lib-links.mk Because SUBDIRS is set conditionally, you should add: DIST_SUBDIRS = tests apple to handle what I assume is an eventual goal of supporting 'make dist' I don't think that is needed in this case, as automake should be smart enough to work it out correctly. My experience is that automake isn't quite that smart (cf: DIST_SUBDIRS usage through xserver). I'd prefer to be on the safe side, but either way is fine with me (we can always just add it later if automake misbehaves). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] tgsi: add GS_INVOCATIONS to property names array
On Tue, May 20, 2014 at 11:28 AM, Roland Scheidegger srol...@vmware.com wrote: On 05/20/2014 04:56 AM, Ilia Mirkin wrote: In commit 4be146b1, I neglected to add the new property to the strings array. This leads to the string '(null)' to be printed instead when converting a GS shader to text. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Cc: 10.2 mesa-sta...@lists.freedesktop.org --- src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c b/src/gallium/auxiliary/tgsi/tgsi_strings.c index 5b6e47f..34dec4f 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c @@ -120,7 +120,8 @@ const char *tgsi_property_names[TGSI_PROPERTY_COUNT] = FS_COORD_PIXEL_CENTER, FS_COLOR0_WRITES_ALL_CBUFS, FS_DEPTH_LAYOUT, - VS_PROHIBIT_UCPS + VS_PROHIBIT_UCPS, + GS_INVOCATIONS, }; const char *tgsi_type_names[5] = Reviewed-by: Roland Scheidegger srol...@vmware.com Thanks! This adds a trailing comma. But some arrays have them, some not, and I have no idea what the convention here should be I've been sneakily adding them to arrays I've been modifying for a while, no one's complained of compilation failures/etc. I think it's better to have them, since the diffs look cleaner when adding items (no need to modify the last item anymore). -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/2] Import eglextchromium.h from Chromium.
It seems unusual for a new extension to be defined in its own header
file rather than the eglext.h file.
Is there a particular reason for that? Are there other vendors putting
their extensions in new header files like this?
-Brian
On 05/16/2014 04:05 PM, Chad Versace wrote:
Ian and Brian,
How do you feel about importing this EGL extension header from the
Chromium source tree? Do you prefer to import the header or just add its
content to eglmesaext.h?
I have a slight preference for importing the header.
-Chad
On Tue, May 06, 2014 at 12:10:56PM -0700, Sarah Sharp wrote:
In order to support the (currently unregistered) Chromium-specific EGL
extension eglGetSyncValuesCHROMIUM on Intel systems, we need to import
the Chromium header that defines it. The file was downloaded from
https://urldefense.proofpoint.com/v1/url?u=https://chromium.googlesource.com/chromium/chromium/%2B/trunk/ui/gl/EGL/eglextchromium.hk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=%2FVSNRsaKb7upderouQ%2FRftkP8qhPrxRicKdXx3XfVSc%3D%0As=f0cfb03f402ce20417a8171fea945e2a2c3dce6a0953f37c67ea2c42e71fec02
It is subject to the license found at
https://urldefense.proofpoint.com/v1/url?u=https://chromium.googlesource.com/chromium/chromium/%2B/trunk/LICENSEk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=%2FVSNRsaKb7upderouQ%2FRftkP8qhPrxRicKdXx3XfVSc%3D%0As=2407723a2ca5c591b15d9b78ec2362a9a3c0d624cec2f3005cc3caed97e518d7
I have imported the header file and added the license text to the top.
The only change was to fix the include guard on the Chromium header to
change the last line from a #define to a #endif, which makes the header
actually compile.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
Cc: Jamey Sharp ja...@minilop.net
Cc: Ian Romanick i...@freedesktop.org
Cc: Stéphane Marchesin stephane.marche...@gmail.com
---
v3: Add an include guard on Chromium header.
include/EGL/eglext.h | 1 +
include/EGL/eglextchromium.h | 60
src/egl/main/Makefile.am | 1 +
3 files changed, 62 insertions(+)
create mode 100644 include/EGL/eglextchromium.h
diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index 243da4a..88b39db 100644
--- a/include/EGL/eglext.h
+++ b/include/EGL/eglext.h
@@ -646,6 +646,7 @@ EGLAPI EGLuint64NV EGLAPIENTRY eglGetSystemTimeNV (void);
#endif /* EGL_NV_system_time */
#include EGL/eglmesaext.h
+#include EGL/eglextchromium.h
#ifdef __cplusplus
}
diff --git a/include/EGL/eglextchromium.h b/include/EGL/eglextchromium.h
new file mode 100644
index 000..0cc0976
--- /dev/null
+++ b/include/EGL/eglextchromium.h
@@ -0,0 +1,60 @@
+// Copyright (c) 2013 The Chromium Authors. All rights reserved.
+//
+// Redistribution and use in source and binary forms, with or without
+// modification, are permitted provided that the following conditions are
+// met:
+//
+//* Redistributions of source code must retain the above copyright
+// notice, this list of conditions and the following disclaimer.
+//* Redistributions in binary form must reproduce the above
+// copyright notice, this list of conditions and the following disclaimer
+// in the documentation and/or other materials provided with the
+// distribution.
+//* Neither the name of Google Inc. nor the names of its
+// contributors may be used to endorse or promote products derived from
+// this software without specific prior written permission.
+//
+// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+// AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+// This file contains Chromium-specific EGL extensions declarations.
+
+#ifndef GPU_EGL_EGLEXTCHROMIUM_H_
+#define GPU_EGL_EGLEXTCHROMIUM_H_
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+#include EGL/eglplatform.h
+
+/* EGLSyncControlCHROMIUM requires 64-bit uint support */
+#if KHRONOS_SUPPORT_INT64
+#ifndef EGL_CHROMIUM_sync_control
+#define EGL_CHROMIUM_sync_control 1
+typedef khronos_uint64_t EGLuint64CHROMIUM;
+#ifdef EGL_EGLEXT_PROTOTYPES
+EGLAPI EGLBoolean EGLAPIENTRY eglGetSyncValuesCHROMIUM(
+EGLDisplay dpy, EGLSurface surface, EGLuint64CHROMIUM *ust,
+EGLuint64CHROMIUM *msc,
Re: [Mesa-dev] glsl: ideas how to improve dead code elimination?
Matt Turner matts...@gmail.com writes: On Mon, May 19, 2014 at 10:56 AM, Aras Pranckevicius a...@unity3d.com wrote: Hi, When Mesa's GLSL compiler is faced with a code like this: // vec4 packednormal exists vec3 normal; normal.xy = packednormal.wy * 2.0 - 1.0; normal.z = sqrt(1.0 - dot(normal.xy, normal.xy)); // now do not use the normal at all anywhere Then the dead code elimination pass will not be able to eliminate the normal variable, nor anything that lead to it (possibly sampling textures into packed normal, etc.). This is because variable refcounting visitor sees normal as having four references, but only two assignments, and can not consider it dead. Even if these two references are from assignment to normal.z where both LHS RHS reference the same variable. Any ideas on how to improve this? If the original code was doing something like this, then dead code elimination is able to properly eliminate this whole thing: // vec4 packednormal exists vec3 normal; vec2 nxy = packednormal.wy * 2.0 - 1.0; float nz = sqrt(1.0 - dot(nxy, nxy)); normal.xy = nxy; normal.z = nz; // now do not use the normal at all anywhere Eric is working on a better GLSL IR dead code elimination pass. I'm not sure of the current status. It's in his tree: git://people.freedesktop.org/~anholt/mesa deadcode Yeah, the code is passing piglit iirc, and with Matt's register renaming, it's a nice win: total instructions in shared programs: 1826879 - 1813610 (-0.73%) instructions in affected programs: 270257 - 256988 (-4.91%) GAINED:15 LOST: 15 however, the nasty thing is that unigine heaven #208 now compiles forever, and I haven't tracked it down. I have noticed in Source engine shaders that a more aggressive register renaming at the GLSL IR level would be useful. Or rework tree grafting to deal with values used only once, not just whole variables used only once. With the live variables code in my deadcode branch, a better tree grafting might be easy. pgprN8F1Z23uk.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78914] [llvmpipe] Front/Backfaces do not cover the same pixels when rasterized
https://bugs.freedesktop.org/show_bug.cgi?id=78914 --- Comment #6 from Roland Scheidegger srol...@vmware.com --- Actually I think I know what's happening here. Our rasterizer can only handle counterclockwise triangles (so the edge function sign indicates if a fragment is inside or outside a plane and ultimately the tri). To make it work we rotate the triangle if the triangle is clockwise to make it counterclockwise (if backface culling is disabled). So far so good. But for correct fill rules (to get cases right where fragment centers are on edges) we also fix up the plane coefficients - and we do this based on the sign of the steepness of the plane function, but because we exchanged two vertices in case when we have front face culling instead of back face culling (so actual winding of the tri did not really change, we just treat it as if it would have changed) we get it wrong. Though this requires some further analysis, it is quite possible I made some mistake here, this is tricky to get right! -- 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] loader: allow alternative methods for PCI identification.
On Tue, May 20, 2014 at 12:07:15AM +0100, Emil Velikov wrote: As you can notice I'm not a huge fan of adding yet another way of retrieving the device/driver name although I would not object if you're willing to split this patch a bit, have the option off by default and fix bugs if/when they pop up :) Sure, I'm happy to disable the autoconf variable by default, and can sign up for bug fix duty. Do you have some way to split this patch a bit in mind? When I have a chance I can split it in two commits (one adding the generic loader_get_pci_id_for_fd and loader_get_device_name_for_fd functions but keeping the current behaviour; the other inserting the disabled-by-default sysfs hooks into the generic functions), but please let me know if you'd prefer a different approach. Thanks, Gary. -- Gary Wong g...@gnu.org http://www.cs.utah.edu/~gtw/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/2] Import eglextchromium.h from Chromium.
On Tue, May 20, 2014 at 9:14 AM, Brian Paul bri...@vmware.com wrote:
It seems unusual for a new extension to be defined in its own header file
rather than the eglext.h file.
Is there a particular reason for that? Are there other vendors putting
their extensions in new header files like this?
The reason we did that for Chrome is that it makes updating the khronos
headers easier (no need to untangle private vs khronos extensions, just
copy the new khronos headers over).
Stéphane
-Brian
On 05/16/2014 04:05 PM, Chad Versace wrote:
Ian and Brian,
How do you feel about importing this EGL extension header from the
Chromium source tree? Do you prefer to import the header or just add its
content to eglmesaext.h?
I have a slight preference for importing the header.
-Chad
On Tue, May 06, 2014 at 12:10:56PM -0700, Sarah Sharp wrote:
In order to support the (currently unregistered) Chromium-specific EGL
extension eglGetSyncValuesCHROMIUM on Intel systems, we need to import
the Chromium header that defines it. The file was downloaded from
https://urldefense.proofpoint.com/v1/url?u=https://chromium.
googlesource.com/chromium/chromium/%2B/trunk/ui/gl/EGL/
eglextchromium.hk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=
lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=
%2FVSNRsaKb7upderouQ%2FRftkP8qhPrxRicKdXx3XfVSc%3D%0As=
f0cfb03f402ce20417a8171fea945e2a2c3dce6a0953f37c67ea2c42e71fec02
It is subject to the license found at
https://urldefense.proofpoint.com/v1/url?u=https://chromium.
googlesource.com/chromium/chromium/%2B/trunk/LICENSEk=
oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%
2BTLs8wadB%2BiIj9xpBY%3D%0Am=%2FVSNRsaKb7upderouQ%
2FRftkP8qhPrxRicKdXx3XfVSc%3D%0As=2407723a2ca5c591b15d9b78ec2362
a9a3c0d624cec2f3005cc3caed97e518d7
I have imported the header file and added the license text to the top.
The only change was to fix the include guard on the Chromium header to
change the last line from a #define to a #endif, which makes the header
actually compile.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
Cc: Jamey Sharp ja...@minilop.net
Cc: Ian Romanick i...@freedesktop.org
Cc: Stéphane Marchesin stephane.marche...@gmail.com
---
v3: Add an include guard on Chromium header.
include/EGL/eglext.h | 1 +
include/EGL/eglextchromium.h | 60 ++
++
src/egl/main/Makefile.am | 1 +
3 files changed, 62 insertions(+)
create mode 100644 include/EGL/eglextchromium.h
diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index 243da4a..88b39db 100644
--- a/include/EGL/eglext.h
+++ b/include/EGL/eglext.h
@@ -646,6 +646,7 @@ EGLAPI EGLuint64NV EGLAPIENTRY eglGetSystemTimeNV
(void);
#endif /* EGL_NV_system_time */
#include EGL/eglmesaext.h
+#include EGL/eglextchromium.h
#ifdef __cplusplus
}
diff --git a/include/EGL/eglextchromium.h b/include/EGL/eglextchromium.h
new file mode 100644
index 000..0cc0976
--- /dev/null
+++ b/include/EGL/eglextchromium.h
@@ -0,0 +1,60 @@
+// Copyright (c) 2013 The Chromium Authors. All rights reserved.
+//
+// Redistribution and use in source and binary forms, with or without
+// modification, are permitted provided that the following conditions
are
+// met:
+//
+//* Redistributions of source code must retain the above copyright
+// notice, this list of conditions and the following disclaimer.
+//* Redistributions in binary form must reproduce the above
+// copyright notice, this list of conditions and the following
disclaimer
+// in the documentation and/or other materials provided with the
+// distribution.
+//* Neither the name of Google Inc. nor the names of its
+// contributors may be used to endorse or promote products derived from
+// this software without specific prior written permission.
+//
+// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+// AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+// This file contains Chromium-specific EGL extensions declarations.
+
+#ifndef GPU_EGL_EGLEXTCHROMIUM_H_
+#define GPU_EGL_EGLEXTCHROMIUM_H_
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+#include EGL/eglplatform.h
+
+/*
[Mesa-dev] [PATCH V2 2/2] meta: Use gl_FragColor to output color values to all the draw buffers
_mesa_meta_setup_blit_shader() currently generates a fragment shader
which, irrespective of the number of draw buffers, writes the color
to only one 'out' variable. Current shader rely on an undefined
behavior and possibly works by chance.
From OpenGL 4.0 spec, page 256:
If a fragment shader writes to gl_FragColor, DrawBuffers specifies a
set of draw buffers into which the single fragment color defined by
gl_FragColor is written. If a fragment shader writes to gl_FragData,
or a user-defined varying out variable, DrawBuffers specifies a set
of draw buffers into which each of the multiple output colors defined
by these variables are separately written. If a fragment shader writes
to none of gl_FragColor, gl_FragData, nor any user defined varying out
variables, the values of the fragment colors following shader execution
are undefined, and may differ for each fragment color.
OpenGL 4.4 spec, page 463, added an additional line in this section:
If some, but not all user-defined output variables are written, the
values of fragment colors corresponding to unwritten variables are
similarly undefined.
V2: Write color output to gl_FragColor instead of writing to multiple
'out' variables. This'll avoid recompiling the shader every time
draw buffers count is updated.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Reviewed-by: Matt Turner matts...@gmail.com (V1)
---
src/mesa/drivers/common/meta.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index fab9106..337be1b 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -246,7 +246,6 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
void *const mem_ctx = ralloc_context(NULL);
struct blit_shader *shader = choose_blit_shader(target, table);
const char *vs_input, *vs_output, *fs_input, *vs_preprocess, *fs_preprocess;
- const char *fs_output_var, *fs_output_var_decl;
if (ctx-Const.GLSLVersion 130) {
vs_preprocess = ;
@@ -254,16 +253,12 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
vs_output = varying;
fs_preprocess = #extension GL_EXT_texture_array : enable;
fs_input = varying;
- fs_output_var_decl = ;
- fs_output_var = gl_FragColor;
} else {
vs_preprocess = #version 130;
vs_input = in;
vs_output = out;
fs_preprocess = #version 130;
fs_input = in;
- fs_output_var_decl = out vec4 out_color;;
- fs_output_var = out_color;
shader-func = texture;
}
@@ -291,15 +286,13 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
#extension GL_ARB_texture_cube_map_array: enable\n
uniform %s texSampler;\n
%s vec4 texCoords;\n
-%s\n
void main()\n
{\n
- vec4 color = %s(texSampler, %s);\n
- %s = color;\n
- gl_FragDepth = color.x;\n
+ gl_FragColor = %s(texSampler, %s);\n
+ gl_FragDepth = gl_FragColor.x;\n
}\n,
-fs_preprocess, shader-type, fs_input, fs_output_decl,
-shader-func, shader-texcoords, fs_output);
+fs_preprocess, shader-type, fs_input,
+shader-func, shader-texcoords);
_mesa_meta_compile_and_link_program(ctx, vs_source, fs_source,
ralloc_asprintf(mem_ctx, %s blit,
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 1/2] meta: Refactor _mesa_meta_setup_blit_shader() to avoid duplicate shader code
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Reviewed-by: Matt Turner matts...@gmail.com
---
src/mesa/drivers/common/meta.c | 101 -
1 file changed, 48 insertions(+), 53 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 3ef3f79..fab9106 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -242,10 +242,30 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
GLenum target,
struct blit_shader_table *table)
{
- const char *vs_source;
- char *fs_source;
+ char *vs_source, *fs_source;
void *const mem_ctx = ralloc_context(NULL);
struct blit_shader *shader = choose_blit_shader(target, table);
+ const char *vs_input, *vs_output, *fs_input, *vs_preprocess, *fs_preprocess;
+ const char *fs_output_var, *fs_output_var_decl;
+
+ if (ctx-Const.GLSLVersion 130) {
+ vs_preprocess = ;
+ vs_input = attribute;
+ vs_output = varying;
+ fs_preprocess = #extension GL_EXT_texture_array : enable;
+ fs_input = varying;
+ fs_output_var_decl = ;
+ fs_output_var = gl_FragColor;
+ } else {
+ vs_preprocess = #version 130;
+ vs_input = in;
+ vs_output = out;
+ fs_preprocess = #version 130;
+ fs_input = in;
+ fs_output_var_decl = out vec4 out_color;;
+ fs_output_var = out_color;
+ shader-func = texture;
+ }
assert(shader != NULL);
@@ -254,57 +274,32 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
return;
}
- if (ctx-Const.GLSLVersion 130) {
- vs_source =
- attribute vec2 position;\n
- attribute vec4 textureCoords;\n
- varying vec4 texCoords;\n
- void main()\n
- {\n
-texCoords = textureCoords;\n
-gl_Position = vec4(position, 0.0, 1.0);\n
- }\n;
-
- fs_source = ralloc_asprintf(mem_ctx,
- #extension GL_EXT_texture_array : enable\n
- #extension GL_ARB_texture_cube_map_array:
enable\n
- uniform %s texSampler;\n
- varying vec4 texCoords;\n
- void main()\n
- {\n
- gl_FragColor = %s(texSampler, %s);\n
- gl_FragDepth = gl_FragColor.x;\n
- }\n,
- shader-type,
- shader-func, shader-texcoords);
- }
- else {
- vs_source = ralloc_asprintf(mem_ctx,
- #version 130\n
- in vec2 position;\n
- in vec4 textureCoords;\n
- out vec4 texCoords;\n
- void main()\n
- {\n
- texCoords = textureCoords;\n
- gl_Position = vec4(position, 0.0,
1.0);\n
- }\n);
- fs_source = ralloc_asprintf(mem_ctx,
- #version 130\n
- #extension GL_ARB_texture_cube_map_array:
enable\n
- uniform %s texSampler;\n
- in vec4 texCoords;\n
- out vec4 out_color;\n
- \n
- void main()\n
- {\n
- out_color = texture(texSampler, %s);\n
- gl_FragDepth = out_color.x;\n
- }\n,
- shader-type,
- shader-texcoords);
- }
-
+ vs_source = ralloc_asprintf(mem_ctx,
+%s\n
+%s vec2 position;\n
+%s vec4 textureCoords;\n
+%s vec4 texCoords;\n
+void main()\n
+{\n
+ texCoords = textureCoords;\n
+ gl_Position = vec4(position, 0.0, 1.0);\n
+}\n,
+vs_preprocess, vs_input, vs_input, vs_output);
+
+ fs_source = ralloc_asprintf(mem_ctx,
+%s\n
+#extension GL_ARB_texture_cube_map_array: enable\n
+uniform %s texSampler;\n
+%s vec4 texCoords;\n
+%s\n
+void main()\n
+{\n
+ vec4 color = %s(texSampler, %s);\n
+ %s = color;\n
+ gl_FragDepth = color.x;\n
+}\n,
+fs_preprocess, shader-type, fs_input, fs_output_decl,
+
[Mesa-dev] [PATCH] i965: Ask the VBO module to actually use VBOs.
Note that this covers the Begin/End rendering path, but not user vertex arrays (so we can't drop copy_array_to_vbo_array() code). Improves performance of isosurf GLVERTEX|TRIANGLES by 16.7506% +/- 4.98934% (n=20). No difference on openarena (n=10), which was why this was reverted back in cbde2765804a4fc62bcf092230a01376aedbf2cd. --- src/mesa/drivers/dri/i965/brw_context.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index 17ae685..39dd582 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -781,6 +781,9 @@ brwCreateContext(gl_api api, brw_init_performance_monitors(brw); } + vbo_use_buffer_objects(ctx); + vbo_always_unmap_buffers(ctx); + return true; } -- 2.0.0.rc2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 2/2] meta: Use gl_FragColor to output color values to all the draw buffers
On Tue, May 20, 2014 at 10:31:05AM -0700, Anuj Phogat wrote:
_mesa_meta_setup_blit_shader() currently generates a fragment shader
which, irrespective of the number of draw buffers, writes the color
to only one 'out' variable. Current shader rely on an undefined
behavior and possibly works by chance.
From OpenGL 4.0 spec, page 256:
If a fragment shader writes to gl_FragColor, DrawBuffers specifies a
set of draw buffers into which the single fragment color defined by
gl_FragColor is written. If a fragment shader writes to gl_FragData,
or a user-defined varying out variable, DrawBuffers specifies a set
of draw buffers into which each of the multiple output colors defined
by these variables are separately written. If a fragment shader writes
to none of gl_FragColor, gl_FragData, nor any user defined varying out
variables, the values of the fragment colors following shader execution
are undefined, and may differ for each fragment color.
OpenGL 4.4 spec, page 463, added an additional line in this section:
If some, but not all user-defined output variables are written, the
values of fragment colors corresponding to unwritten variables are
similarly undefined.
V2: Write color output to gl_FragColor instead of writing to multiple
'out' variables. This'll avoid recompiling the shader every time
draw buffers count is updated.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Reviewed-by: Matt Turner matts...@gmail.com (V1)
Fixes gles3 cts tests:
framebuffer_blit_functionality_color_and_depth_blit.test
framebuffer_blit_functionality_nearest_filter_color_blit.test
framebuffer_blit_functionality_linear_filter_color_blit.test
framebuffer_blit_functionality_color_and_stencil_blit.test
---
src/mesa/drivers/common/meta.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index fab9106..337be1b 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -246,7 +246,6 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
void *const mem_ctx = ralloc_context(NULL);
struct blit_shader *shader = choose_blit_shader(target, table);
const char *vs_input, *vs_output, *fs_input, *vs_preprocess,
*fs_preprocess;
- const char *fs_output_var, *fs_output_var_decl;
if (ctx-Const.GLSLVersion 130) {
vs_preprocess = ;
@@ -254,16 +253,12 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
vs_output = varying;
fs_preprocess = #extension GL_EXT_texture_array : enable;
fs_input = varying;
- fs_output_var_decl = ;
- fs_output_var = gl_FragColor;
} else {
vs_preprocess = #version 130;
vs_input = in;
vs_output = out;
fs_preprocess = #version 130;
fs_input = in;
- fs_output_var_decl = out vec4 out_color;;
- fs_output_var = out_color;
shader-func = texture;
}
@@ -291,15 +286,13 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
#extension GL_ARB_texture_cube_map_array: enable\n
uniform %s texSampler;\n
%s vec4 texCoords;\n
-%s\n
void main()\n
{\n
- vec4 color = %s(texSampler, %s);\n
- %s = color;\n
- gl_FragDepth = color.x;\n
+ gl_FragColor = %s(texSampler, %s);\n
+ gl_FragDepth = gl_FragColor.x;\n
}\n,
-fs_preprocess, shader-type, fs_input, fs_output_decl,
-shader-func, shader-texcoords, fs_output);
+fs_preprocess, shader-type, fs_input,
+shader-func, shader-texcoords);
_mesa_meta_compile_and_link_program(ctx, vs_source, fs_source,
ralloc_asprintf(mem_ctx, %s blit,
--
1.8.3.1
___
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 v3 1/2] Import eglextchromium.h from Chromium.
On Tue, May 20, 2014 at 10:18:50AM -0700, Stéphane Marchesin wrote: On Tue, May 20, 2014 at 9:14 AM, Brian Paul bri...@vmware.com wrote: It seems unusual for a new extension to be defined in its own header file rather than the eglext.h file. Is there a particular reason for that? Are there other vendors putting their extensions in new header files like this? The reason we did that for Chrome is that it makes updating the khronos headers easier (no need to untangle private vs khronos extensions, just copy the new khronos headers over). Brian, Mesa is one vendor that already does that. Mesa places unregistered EGL_MESA extensions into eglmesaext.h for the same reason that Chromium places theirs into eglextchromium.h: to make it easier to update eglext.h from Khronos subversion. EGL_CHROMIUM_sync_control is not yet in the Khronos registry. So, to follow precedent, Mesa should place it in eglmesaext.h or import the eglextchromium.h. Unless someone has a strong preference, I will import eglextchromium.h. If someone later objects, then we can simply fold eglextchromium.h into eglmesaext.h. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/2] Import eglextchromium.h from Chromium.
On 05/20/2014 12:21 PM, Chad Versace wrote: On Tue, May 20, 2014 at 10:18:50AM -0700, Stéphane Marchesin wrote: On Tue, May 20, 2014 at 9:14 AM, Brian Paul bri...@vmware.com wrote: It seems unusual for a new extension to be defined in its own header file rather than the eglext.h file. Is there a particular reason for that? Are there other vendors putting their extensions in new header files like this? The reason we did that for Chrome is that it makes updating the khronos headers easier (no need to untangle private vs khronos extensions, just copy the new khronos headers over). Brian, Mesa is one vendor that already does that. Mesa places unregistered EGL_MESA extensions into eglmesaext.h for the same reason that Chromium places theirs into eglextchromium.h: to make it easier to update eglext.h from Khronos subversion. OK, I didn't even realize that. EGL_CHROMIUM_sync_control is not yet in the Khronos registry. So, to follow precedent, Mesa should place it in eglmesaext.h or import the eglextchromium.h. Unless someone has a strong preference, I will import eglextchromium.h. If someone later objects, then we can simply fold eglextchromium.h into eglmesaext.h Sounds fine. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/fs: Fix gen6 LRP opcode
On Fri, May 9, 2014 at 6:21 AM, Juha-Pekka Heikkila
juhapekka.heikk...@gmail.com wrote:
On ILK implicit accumulator write from MUL opcode seem to
behave sometime unexpected. This patch change implicit
accumulator write to explicit on emitting LRP for gen6.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77707
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77703
Signed-off-by: Juha-Pekka Heikkila juhapekka.heikk...@gmail.com
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index d2dc5fa..c09f0a7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -226,8 +226,10 @@ fs_visitor::emit_lrp(const fs_reg dst, const fs_reg x,
const fs_reg y,
fs_reg negative_a = a;
negative_a.negate = !a.negate;
+ struct brw_reg acc = retype(brw_acc_reg(), this-result.type);
+
emit(ADD(one_minus_a, negative_a, fs_reg(1.0f)));
- fs_inst *mul = emit(MUL(reg_null_f, y, a));
+ fs_inst *mul = emit(MUL(acc, y, a));
mul-writes_accumulator = true;
If we're changing the accumulator destination to be explicit, we
shouldn't make it implicit as well.
emit(MAC(dst, x, one_minus_a));
} else {
--
1.8.1.2
All in all, I'm fine with this patch as-is. If fixes a couple of
regressions, even though I have no idea why.
According to the G45 docs:
Performance Note: GENX hardware cannot support write followed by read on the
same accumulator register back to back. A thread stall (equivalent of having
a ‘switch’
instruction control) may occur before an instruction that uses an accumulator
register
as an (implicit or explicit) source and the previous instruction has the same
accumulator register as the (implicit or explicit) destination. This commonly
occurs in
signal processing algorithms. For example, a multi-tap FIR filter can be
implemented
by a sequence of mac instructions; a matrix computation in DCT transform also
consists of a sequence of mac instructions. A program with a non-compressed
instruction stream may choose to interleave the use of acc0 and acc1 to
achieve
better performance, if accumulators are used explicitly. This is not true if
the
accumulator is addressed implicitly based on the SecHalf compression control
field as
flags and masks are also affected by SecHalf.
A snapshot of the Bspec before they trashed the ILK docs says GEN4
hardware cannot..., so it doesn't seem like this even applies to
Ironlake, and it doesn't even claim to cause hangs. Unfortunately
that's the best explanation I can come up with at this point.
Running some code in the simulator that writes and reads the
accumulator at least doesn't show any complaints on Haswell. I don't
think any of us have an Ironlake simulator?
I really have no idea what's wrong. At the same time, we also have no
idea about the latency of operations writing the accumulator. There's
some text that suggests that it's lower latency that standard
registers, but we have no ability to measure this before Sandybridge.
While it's likely that using the accumulator+MAC is faster to perform
a LRP for one float, for multiple we wind up with code like
mac(8) g1131Fg20,1,0F g48,8,1F {
align1 WE_normal 1Q compacted };
mul(8) nullg2.50,1,0Fg3.10,1,0F{
align1 WE_normal 1Q AccWrEnable };
mac(8) g1141Fg2.10,1,0Fg58,8,1F {
align1 WE_normal 1Q compacted };
mul(8) nullg2.60,1,0Fg3.20,1,0F{
align1 WE_normal 1Q AccWrEnable };
mac(8) g1151Fg2.20,1,0Fg68,8,1F {
align1 WE_normal 1Q compacted };
mul(8) nullg2.70,1,0Fg3.30,1,0F{
align1 WE_normal 1Q AccWrEnable };
mac(8) g1161Fg2.30,1,0Fg78,8,1F {
align1 WE_normal 1Q compacted };
where we presumably stall the EU between successive calculations. It's
unclear to me whether this was an improvement over the old code, which
used one more instruction per component, but could hide instruction
latency more easily.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 78914] [llvmpipe] Front/Backfaces do not cover the same pixels when rasterized
https://bugs.freedesktop.org/show_bug.cgi?id=78914 --- Comment #7 from Roland Scheidegger srol...@vmware.com --- Hmm actually that theory wasn't right. Must be something else. -- 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] RFC: Fixing nv30 fbo attachments
Hello, I attempted doing this a while back, before I really understood what was going on. I got some advice that went totally over my head, and I dropped the issue. I think I'm much better-prepared to tackle the issue this time around. To recap, nv30 (and nv40) hw can't handle certain color/depth format combinations. Specifically, a 16-bit color format must be paired with a 16-bit depth format, and a 32-bit color format must be paired with a 32-bit depth format (well, Z24S8). This HW also can't handle different per-attachment sizes, and also the linearity of all the attachments must be the same. (Whether a surface is linear or not is _generally_ dictated by its w/h, but not always -- POT textures can sometimes end up allocated linearly by e.g. the ddx, or something else.) The different sizes are handled by not exposing ARB_fbo. However the rest of the cases remain. Now that I kinda understand how things are structured, I was thinking of doing the following: When rendering (i.e. draw_vbo co) and the fbo has changed (and has one of the problems above), I would instead put in a temporary texture as the depth attachment. Before actually drawing, I would blit from the real target texture into the temporary texture, and then when rendering is done, blit back from the temp texture back into the target. This deals with the target texture getting modified between draws with various blits/mapping/whatever. This means that you'll only get 16 bits of depth even if you ask for 24 with a 16-bit color format, but the alternative seems too complex/costly. So there are a few questions from this approach: 1. Where do I get the temporary texture from? (And more importantly -- when... what happens if allocation fails?) 2. Having to blit the depth texture back and forth on every draw seems _really_ wasteful... anything I can do about that? Thanks, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Drop the memcmp for finding duplicated CURBE uploads.
At this point, the extra copy of the data and memcmp are as expensive as
just re-uploading.
Note: now that we'll always upload, and brw_constant_buffer watches
BRW_NEW_BATCH anyway, we don't need to explicitly unref the old curbe_bo
at batch reset time.
No significant performance difference on glamor copywinwin10 (n=55),
despite that test having a 98% hit rate on the cache.
---
src/mesa/drivers/dri/i965/brw_context.c | 8
src/mesa/drivers/dri/i965/brw_context.h | 14 --
src/mesa/drivers/dri/i965/brw_curbe.c | 25 ++---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 5 -
4 files changed, 2 insertions(+), 50 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 39dd582..ee5c7b5 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -751,11 +751,6 @@ brwCreateContext(gl_api api,
brw-prim_restart.enable_cut_index = false;
brw-gs.enabled = false;
- if (brw-gen 6) {
- brw-curbe.last_buf = calloc(1, 4096);
- brw-curbe.next_buf = calloc(1, 4096);
- }
-
ctx-VertexProgram._MaintainTnlProgram = true;
ctx-FragmentProgram._MaintainTexEnvProgram = true;
@@ -819,9 +814,6 @@ intelDestroyContext(__DRIcontext * driContextPriv)
drm_intel_bo_unreference(brw-curbe.curbe_bo);
- free(brw-curbe.last_buf);
- free(brw-curbe.next_buf);
-
drm_intel_gem_context_destroy(brw-hw_ctx);
if (ctx-swrast_context) {
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index b84b2a2..0c942b1 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1230,20 +1230,6 @@ struct brw_context
drm_intel_bo *curbe_bo;
/** Offset within curbe_bo of space for current curbe entry */
GLuint curbe_offset;
-
- /**
- * Copy of the last set of CURBEs uploaded. Frequently we'll end up
- * in brw_curbe.c with the same set of constant data to be uploaded,
- * so we'd rather not upload new constants in that case (it can cause
- * a pipeline bubble since only up to 4 can be pipelined at a time).
- */
- GLfloat *last_buf;
- /**
- * Allocation for where to calculate the next set of CURBEs.
- * It's a hot enough path that malloc/free of that data matters.
- */
- GLfloat *next_buf;
- GLuint last_bufsz;
} curbe;
/**
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c
b/src/mesa/drivers/dri/i965/brw_curbe.c
index b776bdc..0db3b94 100644
--- a/src/mesa/drivers/dri/i965/brw_curbe.c
+++ b/src/mesa/drivers/dri/i965/brw_curbe.c
@@ -188,11 +188,11 @@ brw_upload_constant_buffer(struct brw_context *brw)
gl_clip_plane *clip_planes;
if (sz == 0) {
- brw-curbe.last_bufsz = 0;
goto emit;
}
- buf = brw-curbe.next_buf;
+ buf = intel_upload_space(brw, bufsz, 64,
+brw-curbe.curbe_bo, brw-curbe.curbe_offset);
/* fragment shader constants */
if (brw-curbe.wm_size) {
@@ -246,27 +246,6 @@ brw_upload_constant_buffer(struct brw_context *brw)
for (i = 0; i sz*16; i+=4)
fprintf(stderr, curbe %d.%d: %f %f %f %f\n, i/8, i4,
buf[i+0], buf[i+1], buf[i+2], buf[i+3]);
-
- fprintf(stderr, last_buf %p buf %p sz %d/%d cmp %d\n,
- brw-curbe.last_buf, buf,
- bufsz, brw-curbe.last_bufsz,
- brw-curbe.last_buf ? memcmp(buf, brw-curbe.last_buf, bufsz) :
-1);
- }
-
- if (brw-curbe.curbe_bo != NULL
- bufsz == brw-curbe.last_bufsz
- memcmp(buf, brw-curbe.last_buf, bufsz) == 0) {
- /* constants have not changed */
- } else {
- /* Update the record of what our last set of constants was. We
- * don't just flip the pointers because we don't fill in the
- * data in the padding between the entries.
- */
- memcpy(brw-curbe.last_buf, buf, bufsz);
- brw-curbe.last_bufsz = bufsz;
-
- intel_upload_data(brw, buf, bufsz, 64,
-brw-curbe.curbe_bo, brw-curbe.curbe_offset);
}
/* Because this provokes an action (ie copy the constants into the
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index cba81bc..71dc268 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -224,11 +224,6 @@ brw_finish_batch(struct brw_context *brw)
if (brw-batch.ring == RENDER_RING)
brw_perf_monitor_finish_batch(brw);
- if (brw-curbe.curbe_bo) {
- drm_intel_bo_unreference(brw-curbe.curbe_bo);
- brw-curbe.curbe_bo = NULL;
- }
-
/* Mark that the current program cache BO has been used by the GPU.
* It will be reallocated if we need to put new programs in for the
* next batch.
--
2.0.0.rc2
[Mesa-dev] [PATCH 1/2] i965: Reuse intel_upload.c for gen4/5 constant buffers.
No performance difference on glamor with copywinwin10 (n=40) on my gm45.
---
src/mesa/drivers/dri/i965/brw_context.h | 6 --
src/mesa/drivers/dri/i965/brw_curbe.c | 31 +++
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 1 -
3 files changed, 7 insertions(+), 31 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 283c576..b84b2a2 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1223,11 +1223,13 @@ struct brw_context
GLuint vs_size;
GLuint total_size;
+ /**
+ * Pointer to the (intel_upload.c-generated) BO containing the uniforms
+ * for upload to the CURBE.
+ */
drm_intel_bo *curbe_bo;
/** Offset within curbe_bo of space for current curbe entry */
GLuint curbe_offset;
- /** Offset within curbe_bo of space for next curbe entry */
- GLuint curbe_next_offset;
/**
* Copy of the last set of CURBEs uploaded. Frequently we'll end up
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c
b/src/mesa/drivers/dri/i965/brw_curbe.c
index e5ca2ce..b776bdc 100644
--- a/src/mesa/drivers/dri/i965/brw_curbe.c
+++ b/src/mesa/drivers/dri/i965/brw_curbe.c
@@ -39,6 +39,7 @@
#include program/prog_print.h
#include program/prog_statevars.h
#include intel_batchbuffer.h
+#include intel_buffer_objects.h
#include brw_context.h
#include brw_defines.h
#include brw_state.h
@@ -264,34 +265,8 @@ brw_upload_constant_buffer(struct brw_context *brw)
memcpy(brw-curbe.last_buf, buf, bufsz);
brw-curbe.last_bufsz = bufsz;
- if (brw-curbe.curbe_bo != NULL
- brw-curbe.curbe_next_offset + bufsz brw-curbe.curbe_bo-size)
- {
-drm_intel_gem_bo_unmap_gtt(brw-curbe.curbe_bo);
-drm_intel_bo_unreference(brw-curbe.curbe_bo);
-brw-curbe.curbe_bo = NULL;
- }
-
- if (brw-curbe.curbe_bo == NULL) {
-/* Allocate a single page for CURBE entries for this batchbuffer.
- * They're generally around 64b.
- */
-brw-curbe.curbe_bo = drm_intel_bo_alloc(brw-bufmgr, CURBE,
- 4096, 1 6);
-brw-curbe.curbe_next_offset = 0;
-drm_intel_gem_bo_map_gtt(brw-curbe.curbe_bo);
-assert(bufsz 4096);
- }
-
- brw-curbe.curbe_offset = brw-curbe.curbe_next_offset;
- brw-curbe.curbe_next_offset += bufsz;
- brw-curbe.curbe_next_offset = ALIGN(brw-curbe.curbe_next_offset, 64);
-
- /* Copy data to the buffer:
- */
- memcpy(brw-curbe.curbe_bo-virtual + brw-curbe.curbe_offset,
-buf,
-bufsz);
+ intel_upload_data(brw, buf, bufsz, 64,
+brw-curbe.curbe_bo, brw-curbe.curbe_offset);
}
/* Because this provokes an action (ie copy the constants into the
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 818ac61..cba81bc 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -225,7 +225,6 @@ brw_finish_batch(struct brw_context *brw)
brw_perf_monitor_finish_batch(brw);
if (brw-curbe.curbe_bo) {
- drm_intel_gem_bo_unmap_gtt(brw-curbe.curbe_bo);
drm_intel_bo_unreference(brw-curbe.curbe_bo);
brw-curbe.curbe_bo = NULL;
}
--
2.0.0.rc2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/23] configure: add HAVE_GALLIUM_STATIC_TARGETS
On 20/05/14 16:21, Marek Olšák wrote: Well, I have never studied the build system, so I don't know exactly what this series does and how it affects the size of the drivers. Could you please summarize what binaries are created, how big they are, and compare the shared vs static approach vs the current way? And what is the role of the pipe loader? Seems like I jumped into too many presumptions in the introductory email :\ Pipe-driver - gallium/drivers/$hw and its respective winsys built into a standalone loadable module. Installed as gallium-pipe/pipe_(r600|radeonsi|nouveau).so Pipe-loader - aux module (linked into the final library) that loads the appropriate pipe-driver. Static(megadriver) - identical to what you did with megaradeon. All the drivers selected at configure are linked into the same blob. Hardlink for each target for compatibility reasons. Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB Total: 10MiB Shared(pipe-loader) - create individual pipe-drivers and standalone state-tracker libraries (think of them as bla_dri + libGL). The pipe-driver is used by all ST. Note: the interface is not stable, unlike the dri modules. Hardlink for each target for compatibility reasons. Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB Total: 9.8MiB Current approach - at final link time, most state-trackers pull the gallium/drivers/$hw, via the above mentioned DRM_DESCRIPTOR, to create a independent HW specific library. Resulting in some duplication. dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB Total: 20.2MiB Note: currently egl-static and opencl are hardcoded to static and shared respectively. Both of which are will be converted with the next series. Summary: Static - savings scale with number of hardware (gallium/drivers). Shared - savings scale with number of state-trackers (gallium/state-tracker). -Emil Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 1/2] meta: Refactor _mesa_meta_setup_blit_shader() to avoid duplicate shader code
On Tue, May 20, 2014 at 10:31:04AM -0700, Anuj Phogat wrote:
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Reviewed-by: Matt Turner matts...@gmail.com
---
src/mesa/drivers/common/meta.c | 101
-
1 file changed, 48 insertions(+), 53 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 3ef3f79..fab9106 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -242,10 +242,30 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
GLenum target,
struct blit_shader_table *table)
{
- const char *vs_source;
- char *fs_source;
+ char *vs_source, *fs_source;
void *const mem_ctx = ralloc_context(NULL);
struct blit_shader *shader = choose_blit_shader(target, table);
+ const char *vs_input, *vs_output, *fs_input, *vs_preprocess,
*fs_preprocess;
+ const char *fs_output_var, *fs_output_var_decl;
+
+ if (ctx-Const.GLSLVersion 130) {
+ vs_preprocess = ;
+ vs_input = attribute;
+ vs_output = varying;
+ fs_preprocess = #extension GL_EXT_texture_array : enable;
+ fs_input = varying;
+ fs_output_var_decl = ;
+ fs_output_var = gl_FragColor;
+ } else {
+ vs_preprocess = #version 130;
+ vs_input = in;
+ vs_output = out;
+ fs_preprocess = #version 130;
+ fs_input = in;
+ fs_output_var_decl = out vec4 out_color;;
+ fs_output_var = out_color;
+ shader-func = texture;
+ }
assert(shader != NULL);
@@ -254,57 +274,32 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
return;
}
- if (ctx-Const.GLSLVersion 130) {
- vs_source =
- attribute vec2 position;\n
- attribute vec4 textureCoords;\n
- varying vec4 texCoords;\n
- void main()\n
- {\n
-texCoords = textureCoords;\n
-gl_Position = vec4(position, 0.0, 1.0);\n
- }\n;
-
- fs_source = ralloc_asprintf(mem_ctx,
- #extension GL_EXT_texture_array :
enable\n
- #extension GL_ARB_texture_cube_map_array:
enable\n
- uniform %s texSampler;\n
- varying vec4 texCoords;\n
- void main()\n
- {\n
- gl_FragColor = %s(texSampler, %s);\n
- gl_FragDepth = gl_FragColor.x;\n
- }\n,
- shader-type,
- shader-func, shader-texcoords);
- }
- else {
- vs_source = ralloc_asprintf(mem_ctx,
- #version 130\n
- in vec2 position;\n
- in vec4 textureCoords;\n
- out vec4 texCoords;\n
- void main()\n
- {\n
- texCoords = textureCoords;\n
- gl_Position = vec4(position, 0.0,
1.0);\n
- }\n);
- fs_source = ralloc_asprintf(mem_ctx,
- #version 130\n
- #extension GL_ARB_texture_cube_map_array:
enable\n
- uniform %s texSampler;\n
- in vec4 texCoords;\n
- out vec4 out_color;\n
- \n
- void main()\n
- {\n
- out_color = texture(texSampler, %s);\n
- gl_FragDepth = out_color.x;\n
- }\n,
- shader-type,
- shader-texcoords);
- }
-
+ vs_source = ralloc_asprintf(mem_ctx,
+%s\n
+%s vec2 position;\n
+%s vec4 textureCoords;\n
+%s vec4 texCoords;\n
+void main()\n
+{\n
+ texCoords = textureCoords;\n
+ gl_Position = vec4(position, 0.0, 1.0);\n
+}\n,
+vs_preprocess, vs_input, vs_input, vs_output);
+
+ fs_source = ralloc_asprintf(mem_ctx,
+%s\n
+#extension GL_ARB_texture_cube_map_array: enable\n
+uniform %s texSampler;\n
+%s vec4 texCoords;\n
+%s\n
+void main()\n
+{\n
+ vec4 color = %s(texSampler, %s);\n
+
Re: [Mesa-dev] RFC: Fixing nv30 fbo attachments
On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, I attempted doing this a while back, before I really understood what was going on. I got some advice that went totally over my head, and I dropped the issue. I think I'm much better-prepared to tackle the issue this time around. To recap, nv30 (and nv40) hw can't handle certain color/depth format combinations. Specifically, a 16-bit color format must be paired with a 16-bit depth format, and a 32-bit color format must be paired with a 32-bit depth format (well, Z24S8). This HW also can't handle different per-attachment sizes, and also the linearity of all the attachments must be the same. (Whether a surface is linear or not is _generally_ dictated by its w/h, but not always -- POT textures can sometimes end up allocated linearly by e.g. the ddx, or something else.) The different sizes are handled by not exposing ARB_fbo. However the rest of the cases remain. Now that I kinda understand how things are structured, I was thinking of doing the following: When rendering (i.e. draw_vbo co) and the fbo has changed (and has one of the problems above), I would instead put in a temporary texture as the depth attachment. Before actually drawing, I would blit from the real target texture into the temporary texture, and then when rendering is done, blit back from the temp texture back into the target. This deals with the target texture getting modified between draws with various blits/mapping/whatever. This means that you'll only get 16 bits of depth even if you ask for 24 with a 16-bit color format, but the alternative seems too complex/costly. So there are a few questions from this approach: 1. Where do I get the temporary texture from? (And more importantly -- when... what happens if allocation fails?) 2. Having to blit the depth texture back and forth on every draw seems _really_ wasteful... anything I can do about that? You can do that in set_framebuffer_state. When binding, blit to a depth buffer which matches the colorbuffer format. When unbinding, blit back. You can also drop support for 16-bit formats. What about rendering to R16F, RG16F, and RGBA16F? Does R16F have to be coupled with a 16-bit depth buffer too? Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Fixing nv30 fbo attachments
On Tue, May 20, 2014 at 4:51 PM, Marek Olšák mar...@gmail.com wrote: On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, I attempted doing this a while back, before I really understood what was going on. I got some advice that went totally over my head, and I dropped the issue. I think I'm much better-prepared to tackle the issue this time around. To recap, nv30 (and nv40) hw can't handle certain color/depth format combinations. Specifically, a 16-bit color format must be paired with a 16-bit depth format, and a 32-bit color format must be paired with a 32-bit depth format (well, Z24S8). This HW also can't handle different per-attachment sizes, and also the linearity of all the attachments must be the same. (Whether a surface is linear or not is _generally_ dictated by its w/h, but not always -- POT textures can sometimes end up allocated linearly by e.g. the ddx, or something else.) The different sizes are handled by not exposing ARB_fbo. However the rest of the cases remain. Now that I kinda understand how things are structured, I was thinking of doing the following: When rendering (i.e. draw_vbo co) and the fbo has changed (and has one of the problems above), I would instead put in a temporary texture as the depth attachment. Before actually drawing, I would blit from the real target texture into the temporary texture, and then when rendering is done, blit back from the temp texture back into the target. This deals with the target texture getting modified between draws with various blits/mapping/whatever. This means that you'll only get 16 bits of depth even if you ask for 24 with a 16-bit color format, but the alternative seems too complex/costly. So there are a few questions from this approach: 1. Where do I get the temporary texture from? (And more importantly -- when... what happens if allocation fails?) 2. Having to blit the depth texture back and forth on every draw seems _really_ wasteful... anything I can do about that? You can do that in set_framebuffer_state. When binding, blit to a depth buffer which matches the colorbuffer format. When unbinding, blit back. set_framebuffer_state doesn't allow an error to be returned. Should I just print a warning and move on? I guess I'm still not 100% on all the terminology -- what do you mean exactly by bind/unbind? Do you mean the transfer_map/unmap stuff? So basically I would blit once on set_framebuffer_state, and then blit back and forth on resource map/unmap, and only ever render to the temporary buffer without worrying about blitting wihle rendering? You can also drop support for 16-bit formats. I assumed that these were required by some GL version... I also presume that it's faster to use these. BTW, when I say 16-bit, I mean like B5G6R5 or B5G5R5X1, not R16*. What about rendering to R16F, RG16F, and RGBA16F? Does R16F have to be coupled with a 16-bit depth buffer too? Gd question. I assume they want a 32-bit depth buffer. Although I believe those are actually disabled for now (aka forever, unless someone cares enough to turn them on), even though it does look like there's HW support for R16G16B16A16_FLOAT and R32 versions. Or perhaps they're disabled because they can't be used in conjunction with depth? Not familiar enough with the hw restrictions, sorry. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 1/2] meta: Refactor _mesa_meta_setup_blit_shader() to avoid duplicate shader code
On Tue, May 20, 2014 at 1:47 PM, Pohjolainen, Topi
topi.pohjolai...@intel.com wrote:
On Tue, May 20, 2014 at 10:31:04AM -0700, Anuj Phogat wrote:
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Reviewed-by: Matt Turner matts...@gmail.com
---
src/mesa/drivers/common/meta.c | 101
-
1 file changed, 48 insertions(+), 53 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 3ef3f79..fab9106 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -242,10 +242,30 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
GLenum target,
struct blit_shader_table *table)
{
- const char *vs_source;
- char *fs_source;
+ char *vs_source, *fs_source;
void *const mem_ctx = ralloc_context(NULL);
struct blit_shader *shader = choose_blit_shader(target, table);
+ const char *vs_input, *vs_output, *fs_input, *vs_preprocess,
*fs_preprocess;
+ const char *fs_output_var, *fs_output_var_decl;
+
+ if (ctx-Const.GLSLVersion 130) {
+ vs_preprocess = ;
+ vs_input = attribute;
+ vs_output = varying;
+ fs_preprocess = #extension GL_EXT_texture_array : enable;
+ fs_input = varying;
+ fs_output_var_decl = ;
+ fs_output_var = gl_FragColor;
+ } else {
+ vs_preprocess = #version 130;
+ vs_input = in;
+ vs_output = out;
+ fs_preprocess = #version 130;
+ fs_input = in;
+ fs_output_var_decl = out vec4 out_color;;
+ fs_output_var = out_color;
+ shader-func = texture;
+ }
assert(shader != NULL);
@@ -254,57 +274,32 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
return;
}
- if (ctx-Const.GLSLVersion 130) {
- vs_source =
- attribute vec2 position;\n
- attribute vec4 textureCoords;\n
- varying vec4 texCoords;\n
- void main()\n
- {\n
-texCoords = textureCoords;\n
-gl_Position = vec4(position, 0.0, 1.0);\n
- }\n;
-
- fs_source = ralloc_asprintf(mem_ctx,
- #extension GL_EXT_texture_array :
enable\n
- #extension
GL_ARB_texture_cube_map_array: enable\n
- uniform %s texSampler;\n
- varying vec4 texCoords;\n
- void main()\n
- {\n
- gl_FragColor = %s(texSampler, %s);\n
- gl_FragDepth = gl_FragColor.x;\n
- }\n,
- shader-type,
- shader-func, shader-texcoords);
- }
- else {
- vs_source = ralloc_asprintf(mem_ctx,
- #version 130\n
- in vec2 position;\n
- in vec4 textureCoords;\n
- out vec4 texCoords;\n
- void main()\n
- {\n
- texCoords = textureCoords;\n
- gl_Position = vec4(position, 0.0,
1.0);\n
- }\n);
- fs_source = ralloc_asprintf(mem_ctx,
- #version 130\n
- #extension
GL_ARB_texture_cube_map_array: enable\n
- uniform %s texSampler;\n
- in vec4 texCoords;\n
- out vec4 out_color;\n
- \n
- void main()\n
- {\n
- out_color = texture(texSampler,
%s);\n
- gl_FragDepth = out_color.x;\n
- }\n,
- shader-type,
- shader-texcoords);
- }
-
+ vs_source = ralloc_asprintf(mem_ctx,
+%s\n
+%s vec2 position;\n
+%s vec4 textureCoords;\n
+%s vec4 texCoords;\n
+void main()\n
+{\n
+ texCoords = textureCoords;\n
+ gl_Position = vec4(position, 0.0, 1.0);\n
+}\n,
+vs_preprocess, vs_input, vs_input, vs_output);
+
+ fs_source = ralloc_asprintf(mem_ctx,
+%s\n
+#extension GL_ARB_texture_cube_map_array: enable\n
+uniform %s texSampler;\n
+%s vec4 texCoords;\n
+%s\n
+void main()\n
+
Re: [Mesa-dev] [PATCH] i965/fs: Fix gen6 LRP opcode
On Tue, May 20, 2014 at 12:10 PM, Matt Turner matts...@gmail.com wrote: On Fri, May 9, 2014 at 6:21 AM, Juha-Pekka Heikkila juhapekka.heikk...@gmail.com wrote: On ILK implicit accumulator write from MUL opcode seem to behave sometime unexpected. This patch change implicit accumulator write to explicit on emitting LRP for gen6. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77707 Oh, I forgot that in this bug Ken says that disabling constant propagation fixes the problem. I haven't investigated this, and I don't think it's terribly useful to spend much more time debugging this. To be safe, I think we should revert these patches from the 10.2 branch, since we don't have a good understanding of why they work or why they don't. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 2/2] meta: Use gl_FragColor to output color values to all the draw buffers
On 05/20/2014 10:49 AM, Pohjolainen, Topi wrote:
On Tue, May 20, 2014 at 10:31:05AM -0700, Anuj Phogat wrote:
_mesa_meta_setup_blit_shader() currently generates a fragment shader
which, irrespective of the number of draw buffers, writes the color
to only one 'out' variable. Current shader rely on an undefined
behavior and possibly works by chance.
From OpenGL 4.0 spec, page 256:
If a fragment shader writes to gl_FragColor, DrawBuffers specifies a
set of draw buffers into which the single fragment color defined by
gl_FragColor is written. If a fragment shader writes to gl_FragData,
or a user-defined varying out variable, DrawBuffers specifies a set
of draw buffers into which each of the multiple output colors defined
by these variables are separately written. If a fragment shader writes
to none of gl_FragColor, gl_FragData, nor any user defined varying out
variables, the values of the fragment colors following shader execution
are undefined, and may differ for each fragment color.
OpenGL 4.4 spec, page 463, added an additional line in this section:
If some, but not all user-defined output variables are written, the
values of fragment colors corresponding to unwritten variables are
similarly undefined.
V2: Write color output to gl_FragColor instead of writing to multiple
'out' variables. This'll avoid recompiling the shader every time
draw buffers count is updated.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Reviewed-by: Matt Turner matts...@gmail.com (V1)
Fixes gles3 cts tests:
framebuffer_blit_functionality_color_and_depth_blit.test
framebuffer_blit_functionality_nearest_filter_color_blit.test
framebuffer_blit_functionality_linear_filter_color_blit.test
framebuffer_blit_functionality_color_and_stencil_blit.test
---
src/mesa/drivers/common/meta.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index fab9106..337be1b 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -246,7 +246,6 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
void *const mem_ctx = ralloc_context(NULL);
struct blit_shader *shader = choose_blit_shader(target, table);
const char *vs_input, *vs_output, *fs_input, *vs_preprocess,
*fs_preprocess;
- const char *fs_output_var, *fs_output_var_decl;
if (ctx-Const.GLSLVersion 130) {
vs_preprocess = ;
@@ -254,16 +253,12 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
vs_output = varying;
fs_preprocess = #extension GL_EXT_texture_array : enable;
fs_input = varying;
- fs_output_var_decl = ;
- fs_output_var = gl_FragColor;
} else {
vs_preprocess = #version 130;
vs_input = in;
vs_output = out;
fs_preprocess = #version 130;
fs_input = in;
- fs_output_var_decl = out vec4 out_color;;
- fs_output_var = out_color;
shader-func = texture;
}
@@ -291,15 +286,13 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
#extension GL_ARB_texture_cube_map_array: enable\n
uniform %s texSampler;\n
%s vec4 texCoords;\n
-%s\n
void main()\n
{\n
- vec4 color = %s(texSampler, %s);\n
- %s = color;\n
- gl_FragDepth = color.x;\n
+ gl_FragColor = %s(texSampler, %s);\n
+ gl_FragDepth = gl_FragColor.x;\n
}\n,
-fs_preprocess, shader-type, fs_input, fs_output_decl,
-shader-func, shader-texcoords, fs_output);
+fs_preprocess, shader-type, fs_input,
+shader-func, shader-texcoords);
Assuming you fix this line (as Topi pointed out), both patches are:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Thanks for fixing this, Anuj.
_mesa_meta_compile_and_link_program(ctx, vs_source, fs_source,
ralloc_asprintf(mem_ctx, %s blit,
Topi and I spent a while analyzing why we saw failures with this code on
Broadwell, but not on earlier platforms.
Using gl_FragColor causes OutputsWritten to include FRAG_RESULT_COLOR,
while using out vec4 out_color causes it to include only
FRAG_RESULT_DATA0 (and not 1/2/3 for the other targets).
If a program binds color buffer 1, but not color buffer 0, this means
that brw_color_buffer_write_enabled() will return FALSE. Buffer 0 is
NULL, and buffer 1 supposedly isn't written by the program.
On most platforms, this happens to work out due to several subtle
interactions:
1. Since the shader also happens to write gl_FragDepth, the following
code in gen7_wm_state.c will still enable pixel shader dispatch:
if (brw_color_buffer_write_enabled(brw) ||
Re: [Mesa-dev] [PATCH] i965: Ask the VBO module to actually use VBOs.
On 05/20/2014 11:00 AM, Eric Anholt wrote: Note that this covers the Begin/End rendering path, but not user vertex arrays (so we can't drop copy_array_to_vbo_array() code). Improves performance of isosurf GLVERTEX|TRIANGLES by 16.7506% +/- 4.98934% (n=20). No difference on openarena (n=10), which was why this was reverted back in cbde2765804a4fc62bcf092230a01376aedbf2cd. --- src/mesa/drivers/dri/i965/brw_context.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index 17ae685..39dd582 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -781,6 +781,9 @@ brwCreateContext(gl_api api, brw_init_performance_monitors(brw); } + vbo_use_buffer_objects(ctx); + vbo_always_unmap_buffers(ctx); + return true; } Hah! You finally found the benchmark. I've had this patch sitting around for ages, and never observed any difference. Nice. Reviewed-by: Kenneth Graunke kenn...@whitecape.org signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Listen to BRW_NEW_FRAGMENT_PROGRAM for 3DSTATE_PS_BLEND.
brw_color_buffer_write_enabled depends on brw-fragment_program, which
means we have to listen to BRW_NEW_FRAGMENT_PROGRAM.
On most generations, this was only called from a function that already
subscribed. However, on Broadwell, we failed to listen to the necessary
event in the atom that emits 3DSTATE_PS_BLEND.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/brw_wm_state.c | 1 +
src/mesa/drivers/dri/i965/gen8_blend_state.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
Not observed to actually fix anything, but hey, why not?
diff --git a/src/mesa/drivers/dri/i965/brw_wm_state.c
b/src/mesa/drivers/dri/i965/brw_wm_state.c
index fbd605c..98b5185 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_state.c
@@ -45,6 +45,7 @@ bool
brw_color_buffer_write_enabled(struct brw_context *brw)
{
struct gl_context *ctx = brw-ctx;
+ /* BRW_NEW_FRAGMENT_PROGRAM */
const struct gl_fragment_program *fp = brw-fragment_program;
int i;
diff --git a/src/mesa/drivers/dri/i965/gen8_blend_state.c
b/src/mesa/drivers/dri/i965/gen8_blend_state.c
index a02b765..9c5eedb 100644
--- a/src/mesa/drivers/dri/i965/gen8_blend_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_blend_state.c
@@ -215,7 +215,7 @@ gen8_upload_ps_blend(struct brw_context *brw)
/* _NEW_BUFFERS */
struct gl_renderbuffer *rb = ctx-DrawBuffer-_ColorDrawBuffers[0];
- /* _NEW_BUFFERS | _NEW_COLOR */
+ /* BRW_NEW_FRAGMENT_PROGRAM | _NEW_BUFFERS | _NEW_COLOR */
if (brw_color_buffer_write_enabled(brw))
dw1 |= GEN8_PS_BLEND_HAS_WRITEABLE_RT;
@@ -290,7 +290,7 @@ gen8_upload_ps_blend(struct brw_context *brw)
const struct brw_tracked_state gen8_ps_blend = {
.dirty = {
.mesa = _NEW_BUFFERS | _NEW_COLOR | _NEW_MULTISAMPLE,
- .brw = BRW_NEW_CONTEXT,
+ .brw = BRW_NEW_CONTEXT | BRW_NEW_FRAGMENT_PROGRAM,
.cache = 0,
},
.emit = gen8_upload_ps_blend
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Use WE_all for FB write header setup on Broadwell.
I forgot to disable writemasking on the OR and MOV which set the render
target index and source 0 alpha present to render target bit.
Using get_element_ud is equivalent and avoids a line-wrap.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
index 294ce46..c4f9d85 100644
--- a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
@@ -76,16 +76,17 @@ gen8_fs_generator::generate_fb_write(fs_inst *ir)
if (ir-target 0 key-replicate_alpha) {
/* Set Source0 Alpha Present to RenderTarget bit in the header. */
- OR(vec1(retype(brw_message_reg(ir-base_mrf), BRW_REGISTER_TYPE_UD)),
-vec1(retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD)),
-brw_imm_ud(1 11));
+ gen8_instruction *inst =
+OR(get_element_ud(brw_message_reg(ir-base_mrf), 0),
+ vec1(retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD)),
+ brw_imm_ud(1 11));
+ gen8_set_mask_control(inst, BRW_MASK_DISABLE);
}
if (ir-target 0) {
/* Set the render target index for choosing BLEND_STATE. */
- MOV(retype(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE, ir-base_mrf, 2),
-BRW_REGISTER_TYPE_UD),
- brw_imm_ud(ir-target));
+ MOV_RAW(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE, ir-base_mrf, 2),
+ brw_imm_ud(ir-target));
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 2/2] meta: Use gl_FragColor to output color values to all the draw buffers
On Tue, May 20, 2014 at 2:36 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On 05/20/2014 10:49 AM, Pohjolainen, Topi wrote:
On Tue, May 20, 2014 at 10:31:05AM -0700, Anuj Phogat wrote:
_mesa_meta_setup_blit_shader() currently generates a fragment shader
which, irrespective of the number of draw buffers, writes the color
to only one 'out' variable. Current shader rely on an undefined
behavior and possibly works by chance.
From OpenGL 4.0 spec, page 256:
If a fragment shader writes to gl_FragColor, DrawBuffers specifies a
set of draw buffers into which the single fragment color defined by
gl_FragColor is written. If a fragment shader writes to gl_FragData,
or a user-defined varying out variable, DrawBuffers specifies a set
of draw buffers into which each of the multiple output colors defined
by these variables are separately written. If a fragment shader writes
to none of gl_FragColor, gl_FragData, nor any user defined varying out
variables, the values of the fragment colors following shader execution
are undefined, and may differ for each fragment color.
OpenGL 4.4 spec, page 463, added an additional line in this section:
If some, but not all user-defined output variables are written, the
values of fragment colors corresponding to unwritten variables are
similarly undefined.
V2: Write color output to gl_FragColor instead of writing to multiple
'out' variables. This'll avoid recompiling the shader every time
draw buffers count is updated.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Reviewed-by: Matt Turner matts...@gmail.com (V1)
Fixes gles3 cts tests:
framebuffer_blit_functionality_color_and_depth_blit.test
framebuffer_blit_functionality_nearest_filter_color_blit.test
framebuffer_blit_functionality_linear_filter_color_blit.test
framebuffer_blit_functionality_color_and_stencil_blit.test
---
src/mesa/drivers/common/meta.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index fab9106..337be1b 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -246,7 +246,6 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
void *const mem_ctx = ralloc_context(NULL);
struct blit_shader *shader = choose_blit_shader(target, table);
const char *vs_input, *vs_output, *fs_input, *vs_preprocess,
*fs_preprocess;
- const char *fs_output_var, *fs_output_var_decl;
if (ctx-Const.GLSLVersion 130) {
vs_preprocess = ;
@@ -254,16 +253,12 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
vs_output = varying;
fs_preprocess = #extension GL_EXT_texture_array : enable;
fs_input = varying;
- fs_output_var_decl = ;
- fs_output_var = gl_FragColor;
} else {
vs_preprocess = #version 130;
vs_input = in;
vs_output = out;
fs_preprocess = #version 130;
fs_input = in;
- fs_output_var_decl = out vec4 out_color;;
- fs_output_var = out_color;
shader-func = texture;
}
@@ -291,15 +286,13 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
#extension GL_ARB_texture_cube_map_array: enable\n
uniform %s texSampler;\n
%s vec4 texCoords;\n
-%s\n
void main()\n
{\n
- vec4 color = %s(texSampler, %s);\n
- %s = color;\n
- gl_FragDepth = color.x;\n
+ gl_FragColor = %s(texSampler, %s);\n
+ gl_FragDepth = gl_FragColor.x;\n
}\n,
-fs_preprocess, shader-type, fs_input, fs_output_decl,
-shader-func, shader-texcoords, fs_output);
+fs_preprocess, shader-type, fs_input,
+shader-func, shader-texcoords);
Assuming you fix this line (as Topi pointed out), both patches are:
Fixed.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Thanks for fixing this, Anuj.
_mesa_meta_compile_and_link_program(ctx, vs_source, fs_source,
ralloc_asprintf(mem_ctx, %s blit,
Topi and I spent a while analyzing why we saw failures with this code on
Broadwell, but not on earlier platforms.
Using gl_FragColor causes OutputsWritten to include FRAG_RESULT_COLOR,
while using out vec4 out_color causes it to include only
FRAG_RESULT_DATA0 (and not 1/2/3 for the other targets).
If a program binds color buffer 1, but not color buffer 0, this means
that brw_color_buffer_write_enabled() will return FALSE. Buffer 0 is
NULL, and buffer 1 supposedly isn't written by the program.
On most platforms, this happens to work out due to several subtle
interactions:
1. Since the shader also happens to write gl_FragDepth, the following
code in gen7_wm_state.c
Re: [Mesa-dev] [PATCH 03/10] mesa: add new enum MAX_UNIFORM_LOCATIONS
On 05/19/2014 10:20 PM, Tapani wrote:
On 05/19/2014 08:26 PM, Ian Romanick wrote:
On 04/09/2014 02:56 AM, Tapani Pälli wrote:
Patch adds new implementation dependent value required by the
GL_ARB_explicit_uniform_location extension. Default value for user
assignable locations is calculated as sum of MaxUniformComponents
for each stage.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/context.c | 10 +-
src/mesa/main/get.c | 1 +
src/mesa/main/get_hash_params.py | 1 +
src/mesa/main/mtypes.h | 5 +
src/mesa/main/tests/enum_strings.cpp | 1 +
5 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 860ae86..8b77df1 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -610,8 +610,16 @@ _mesa_init_constants(struct gl_context *ctx)
ctx-Const.MaxUniformBlockSize = 16384;
ctx-Const.UniformBufferOffsetAlignment = 1;
- for (i = 0; i MESA_SHADER_STAGES; i++)
+ /* GL_ARB_explicit_uniform_location, initial value calculated
+* as sum of MaxUniformComponents for each stage.
+*/
+ ctx-Const.MaxUserAssignableUniformLocations = 0;
+
+ for (i = 0; i MESA_SHADER_STAGES; i++) {
init_program_limits(ctx, i, ctx-Const.Program[i]);
+ ctx-Const.MaxUserAssignableUniformLocations +=
+ ctx-Const.Program[i].MaxUniformComponents;
+ }
This is just going to set ctx-Const.MaxUserAssignableUniformLocations
to 4 * 4 * MAX_UNIFORMS, and that's probably not what we want. Maybe
just set 4 * MAX_UNIFORMS with a comment saying it's, MAX_UNIFORMS for
each possible shader stage.
There should be much more locations than number of uniforms though (?)
MAX_UNIFORMS refers to count of available vec4 uniforms, each of these
should have 4 locations available. Also, value from the above formula
nicely matches with binary drivers so IMO it shouldn't be 'too much'.
It occured to me later that 4 * 4 * MAX_UNIFORMS is actually more
correct... because you could have MAX_UNIFORMS float uniforms per stage,
and you'd like to be able to give each of them a location. :) So I
guess just explicitly set it to 4 * 4 * MAX_UNIFORMS outside the loop
instead of calculating the value in the loop.
ctx-Const.MaxProgramMatrices = MAX_PROGRAM_MATRICES;
ctx-Const.MaxProgramMatrixStackDepth =
MAX_PROGRAM_MATRIX_STACK_DEPTH;
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 6d95790..8b50441 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -395,6 +395,7 @@ EXTRA_EXT(ARB_viewport_array);
EXTRA_EXT(ARB_compute_shader);
EXTRA_EXT(ARB_gpu_shader5);
EXTRA_EXT2(ARB_transform_feedback3, ARB_gpu_shader5);
+EXTRA_EXT(ARB_explicit_uniform_location);
static const int
extra_ARB_color_buffer_float_or_glcore[] = {
diff --git a/src/mesa/main/get_hash_params.py
b/src/mesa/main/get_hash_params.py
index 06d0bba..5709d42 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -474,6 +474,7 @@ descriptor=[
[ MAX_LIST_NESTING, CONST(MAX_LIST_NESTING), NO_EXTRA ],
[ MAX_NAME_STACK_DEPTH, CONST(MAX_NAME_STACK_DEPTH), NO_EXTRA ],
[ MAX_PIXEL_MAP_TABLE, CONST(MAX_PIXEL_MAP_TABLE), NO_EXTRA ],
+ [ MAX_UNIFORM_LOCATIONS,
CONTEXT_INT(Const.MaxUserAssignableUniformLocations), NO_EXTRA ],
Ditto on Petri's comment.
[ NAME_STACK_DEPTH, CONTEXT_INT(Select.NameStackDepth),
NO_EXTRA ],
[ PACK_LSB_FIRST, CONTEXT_BOOL(Pack.LsbFirst), NO_EXTRA ],
[ PACK_SWAP_BYTES, CONTEXT_BOOL(Pack.SwapBytes), NO_EXTRA ],
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 7ac6bbe..fefbe06 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3311,6 +3311,11 @@ struct gl_constants
GLuint UniformBufferOffsetAlignment;
/** @} */
+ /**
+* GL_ARB_explicit_uniform_location
+*/
+ GLuint MaxUserAssignableUniformLocations;
+
/** GL_ARB_geometry_shader4 */
GLuint MaxGeometryOutputVertices;
GLuint MaxGeometryTotalOutputComponents;
diff --git a/src/mesa/main/tests/enum_strings.cpp
b/src/mesa/main/tests/enum_strings.cpp
index 3795700..298ff6a 100644
--- a/src/mesa/main/tests/enum_strings.cpp
+++ b/src/mesa/main/tests/enum_strings.cpp
@@ -787,6 +787,7 @@ const struct enum_info everything[] = {
{ 0x8256, GL_RESET_NOTIFICATION_STRATEGY_ARB },
{ 0x8257, GL_PROGRAM_BINARY_RETRIEVABLE_HINT },
{ 0x8261, GL_NO_RESET_NOTIFICATION_ARB },
+ { 0x826E, GL_MAX_UNIFORM_LOCATIONS },
{ 0x82DF, GL_TEXTURE_IMMUTABLE_LEVELS },
{ 0x8362, GL_UNSIGNED_BYTE_2_3_3_REV },
{ 0x8363, GL_UNSIGNED_SHORT_5_6_5 },
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] Enable GL_ARB_explicit_uniform_location in the drivers.
On 05/19/2014 10:13 PM, Tapani wrote: On 05/19/2014 08:21 PM, Ian Romanick wrote: Either this patch should: - Delete the extension enable flag - Change the table in extensions.c to use dummy_true or The next patch needs to not say all drivers that support GLSL. I think we should just enable it everywhere. OK, I was following the way how GL_ARB_explicit_attrib_location was enabled. That one is still only for all drivers that support GLSL and you really need GLSL to be able to use attributes or uniforms. I can enable it everywhere via dummy_true. I misread this patch a bit. I think it's okay as long as you also enable the extension in the classic i915 driver. I missed that you were enabling it in Gallium drivers. Oops. On 04/09/2014 02:56 AM, Tapani Pälli wrote: Signed-off-by: Tapani Pälli tapani.pa...@intel.com --- src/mesa/drivers/dri/i965/intel_extensions.c | 1 + src/mesa/state_tracker/st_extensions.c | 1 + 2 files changed, 2 insertions(+) diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c b/src/mesa/drivers/dri/i965/intel_extensions.c index 15fcd30..f8abf98 100644 --- a/src/mesa/drivers/dri/i965/intel_extensions.c +++ b/src/mesa/drivers/dri/i965/intel_extensions.c @@ -170,6 +170,7 @@ intelInitExtensions(struct gl_context *ctx) ctx-Extensions.ARB_draw_instanced = true; ctx-Extensions.ARB_ES2_compatibility = true; ctx-Extensions.ARB_explicit_attrib_location = true; + ctx-Extensions.ARB_explicit_uniform_location = true; ctx-Extensions.ARB_fragment_coord_conventions = true; ctx-Extensions.ARB_fragment_program = true; ctx-Extensions.ARB_fragment_program_shadow = true; diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index 3e1e45d..5b11e7b 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -534,6 +534,7 @@ void st_init_extensions(struct st_context *st) ctx-Extensions.ARB_ES2_compatibility = GL_TRUE; ctx-Extensions.ARB_draw_elements_base_vertex = GL_TRUE; ctx-Extensions.ARB_explicit_attrib_location = GL_TRUE; + ctx-Extensions.ARB_explicit_uniform_location = GL_TRUE; ctx-Extensions.ARB_fragment_coord_conventions = GL_TRUE; ctx-Extensions.ARB_fragment_program = GL_TRUE; ctx-Extensions.ARB_fragment_shader = GL_TRUE; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Ask the VBO module to actually use VBOs.
On Tue, May 20, 2014 at 11:00 AM, Eric Anholt e...@anholt.net wrote: Note that this covers the Begin/End rendering path, but not user vertex arrays (so we can't drop copy_array_to_vbo_array() code). Improves performance of isosurf GLVERTEX|TRIANGLES by 16.7506% +/- 4.98934% (n=20). No difference on openarena (n=10), which was why this was reverted back in cbde2765804a4fc62bcf092230a01376aedbf2cd. --- src/mesa/drivers/dri/i965/brw_context.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index 17ae685..39dd582 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -781,6 +781,9 @@ brwCreateContext(gl_api api, brw_init_performance_monitors(brw); } + vbo_use_buffer_objects(ctx); + vbo_always_unmap_buffers(ctx); + Just for my own understanding: This is opting-in to using a VBO to back immediate-mode data? How is immediate-mode data sent to the GPU before this? In case it's not obvious from the answer to the previous question, why is putting the data in a VBO such an improvement? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Fixing nv30 fbo attachments
On Tue, May 20, 2014 at 11:04 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Tue, May 20, 2014 at 4:51 PM, Marek Olšák mar...@gmail.com wrote: On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, I attempted doing this a while back, before I really understood what was going on. I got some advice that went totally over my head, and I dropped the issue. I think I'm much better-prepared to tackle the issue this time around. To recap, nv30 (and nv40) hw can't handle certain color/depth format combinations. Specifically, a 16-bit color format must be paired with a 16-bit depth format, and a 32-bit color format must be paired with a 32-bit depth format (well, Z24S8). This HW also can't handle different per-attachment sizes, and also the linearity of all the attachments must be the same. (Whether a surface is linear or not is _generally_ dictated by its w/h, but not always -- POT textures can sometimes end up allocated linearly by e.g. the ddx, or something else.) The different sizes are handled by not exposing ARB_fbo. However the rest of the cases remain. Now that I kinda understand how things are structured, I was thinking of doing the following: When rendering (i.e. draw_vbo co) and the fbo has changed (and has one of the problems above), I would instead put in a temporary texture as the depth attachment. Before actually drawing, I would blit from the real target texture into the temporary texture, and then when rendering is done, blit back from the temp texture back into the target. This deals with the target texture getting modified between draws with various blits/mapping/whatever. This means that you'll only get 16 bits of depth even if you ask for 24 with a 16-bit color format, but the alternative seems too complex/costly. So there are a few questions from this approach: 1. Where do I get the temporary texture from? (And more importantly -- when... what happens if allocation fails?) 2. Having to blit the depth texture back and forth on every draw seems _really_ wasteful... anything I can do about that? You can do that in set_framebuffer_state. When binding, blit to a depth buffer which matches the colorbuffer format. When unbinding, blit back. set_framebuffer_state doesn't allow an error to be returned. Should I just print a warning and move on? Yes, because you have no other choice. I guess I'm still not 100% on all the terminology -- what do you mean exactly by bind/unbind? Do you mean the transfer_map/unmap stuff? So basically I would blit once on set_framebuffer_state, and then blit back and forth on resource map/unmap, and only ever render to the temporary buffer without worrying about blitting wihle rendering? bind is when a buffer is set, unbind is when the buffer is unset. set_framebuffer_state unbinds the current framebuffer and binds a new one. transfer_map/unmap must use the resource which contains the latest data, there is no doubt about that. If there are no transfers, you only have to do the blits between 32-bit and 16-bit in set_framebuffer_state, because that's the only place where the framebuffer is changed. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Listen to BRW_NEW_FRAGMENT_PROGRAM for 3DSTATE_PS_BLEND.
Both are Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/10] glsl: parser changes for GL_ARB_explicit_uniform_location
On 05/19/2014 10:08 PM, Tapani wrote:
On 05/19/2014 08:18 PM, Ian Romanick wrote:
On 04/09/2014 02:56 AM, Tapani Pälli wrote:
Patch adds a preprocessor define for the extension and stores explicit
location data for uniforms during AST-HIR conversion. It also sets
layout token to be available when having the extension in place.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/ast_to_hir.cpp | 37
+
src/glsl/glcpp/glcpp-parse.y | 3 +++
src/glsl/glsl_lexer.ll| 1 +
src/glsl/glsl_parser_extras.h | 14 ++
4 files changed, 55 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 8d55ee3..7431ad7 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2170,6 +2170,43 @@ validate_explicit_location(const struct
ast_type_qualifier *qual,
{
bool fail = false;
+ /* Checks for GL_ARB_explicit_uniform_location. */
+ if (qual-flags.q.uniform) {
+
Extra blank line.
oops
+ if (!state-check_explicit_uniform_location_allowed(loc, var))
+ return;
+
+ const struct gl_context *const ctx = state-ctx;
+ unsigned max_loc = qual-location +
var-type-component_slots() - 1;
I think that over counts for this purpose, and we can blame confusing
nomenclature. component_slots for a mat4 is 4, so a mat4 uniform counts
4*4 against the GL_MAX_VERTEX_UNIFORM_COMPONENTS limit. However, it
only has one location (as returned by glGetUniformLocation), so it
only counts 1 against the GL_MAX_UNIFORM_LOCATIONS limit.
I see, I was considering structs and arrays when writing this part and
forgot about matrix. I assume matrix is the only special case here
though? Everything else gets correct location count value via
component_slots().
Currently, it should only bee matrices and structures containing matrices
that need different treatment. I think dvec3 and dvec4 (when we add support
for doubles) will also take multiple slots.
+
+ /* ARB_explicit_uniform_location specification states:
+ *
+ * The explicitly defined locations and the generated
locations
+ * must be in the range of 0 to MAX_UNIFORM_LOCATIONS
minus one.
+ *
+ * Valid locations for default-block uniform variable
locations
+ * are in the range of 0 to the implementation-defined
maximum
+ * number of uniform locations.
+ */
+ if (qual-location 0) {
+ _mesa_glsl_error(loc, state,
+ explicit location 0 for uniform %s,
var-name);
+ return;
+ }
+
+ if (max_loc = ctx-Const.MaxUserAssignableUniformLocations) {
+ _mesa_glsl_error(loc, state, location qualifier for
uniform %s
+ = MAX_UNIFORM_LOCATIONS (%u),
+ var-name,
+
ctx-Const.MaxUserAssignableUniformLocations);
+ return;
+ }
+
+ var-data.explicit_location = true;
+ var-data.location = qual-location;
+ return;
+ }
+
/* Between GL_ARB_explicit_attrib_location an
* GL_ARB_separate_shader_objects, the inputs and outputs of any
shader
* stage can be assigned explicit locations. The checking here
associates
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index f28d853..6d42138 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -2087,6 +2087,9 @@
_glcpp_parser_handle_version_declaration(glcpp_parser_t *parser,
intmax_t versio
if (extensions-ARB_explicit_attrib_location)
add_builtin_define(parser,
GL_ARB_explicit_attrib_location, 1);
+ if (extensions-ARB_explicit_uniform_location)
+ add_builtin_define(parser,
GL_ARB_explicit_uniform_location, 1);
+
if (extensions-ARB_shader_texture_lod)
add_builtin_define(parser,
GL_ARB_shader_texture_lod, 1);
diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
index 7602351..83f0b6d 100644
--- a/src/glsl/glsl_lexer.ll
+++ b/src/glsl/glsl_lexer.ll
@@ -393,6 +393,7 @@ layout{
|| yyextra-AMD_conservative_depth_enable
|| yyextra-ARB_conservative_depth_enable
|| yyextra-ARB_explicit_attrib_location_enable
+ || yyextra-ARB_explicit_uniform_location_enable
|| yyextra-has_separate_shader_objects()
|| yyextra-ARB_uniform_buffer_object_enable
|| yyextra-ARB_fragment_coord_conventions_enable
diff --git a/src/glsl/glsl_parser_extras.h
b/src/glsl/glsl_parser_extras.h
index c53c583..20879a0 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -152,6 +152,20 @@ struct _mesa_glsl_parse_state {
return true;
}
+ bool check_explicit_uniform_location_allowed(YYLTYPE *locp,
+
[Mesa-dev] Mesa 10.1.4
Mesa 10.1.4 has been released. Mesa 10.1.4 is a bug fix release which fixes bugs fixed since the 10.1.3 release, (see below for a list of changes). The tag in the git repository for Mesa 10.1.4 is 'mesa-10.1.4'. Mesa 10.1.4 is available for download at ftp://freedesktop.org/pub/mesa/10.1.4/ md5sums: e934365d77f384bfaec844999440bef8 MesaLib-10.1.4.tar.gz 6fddee101f49b7409cd29994c34ddee7 MesaLib-10.1.4.tar.bz2 ba5f48e7d5e373922c804c2651fec6c1 MesaLib-10.1.4.zip I have verified building from the .tar.bz2 file by doing: tar xjf MesaLib-10.1.4.tar.bz2 cd Mesa-10.1.4 ./configure --enable-gallium-llvm make -j6 make install I have also verified that I pushed the tag. -Carl -- carl.d.wo...@intel.com Changes from 10.1.3 to 10.1.4: Brian Paul (1): mesa: fix double-freeing of dispatch tables inside glBegin/End. Carl Worth (4): docs: Add MD5 sums for 10.1.3 cherry-ignore: Roland and Michel agreed to drop these patches. VERSION: Update to 10.1.4 docs: Add release notes for the 10.1.4 release. Emil Velikov (1): configure: error out if building GBM without dri Eric Anholt (1): i965/vs: Use samplers for UBOs in the VS like we do for non-UBO pulls. Ilia Mirkin (3): nv50/ir: make sure to reverse cond codes on all the OP_SET variants nv50: fix setting of texture ms info to be per-stage nv50/ir: fix integer mul lowering for u32 x u32 - high u32 Michel Dänzer (1): radeonsi: Fix anisotropic filtering state setup Tom Stellard (2): configure.ac: Add LLVM_VERSION_PATCH to DEFINES radeonsi: Enable geometry shaders with LLVM 3.4.1 pgpji6s81glYi.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/23] configure: add HAVE_GALLIUM_STATIC_TARGETS
Thanks, that makes sense. I think the static approach is better, but I don't have a strong opinion about that. Did you also consider merging the API libraries? For DRI, we need to export __driDriverExtensions. For VDPAU, we need to export vdp_imp_device_create_x11. Etc. However, having a single blob for multiple APIs should work, right? Marek On Tue, May 20, 2014 at 10:04 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 20/05/14 16:21, Marek Olšák wrote: Well, I have never studied the build system, so I don't know exactly what this series does and how it affects the size of the drivers. Could you please summarize what binaries are created, how big they are, and compare the shared vs static approach vs the current way? And what is the role of the pipe loader? Seems like I jumped into too many presumptions in the introductory email :\ Pipe-driver - gallium/drivers/$hw and its respective winsys built into a standalone loadable module. Installed as gallium-pipe/pipe_(r600|radeonsi|nouveau).so Pipe-loader - aux module (linked into the final library) that loads the appropriate pipe-driver. Static(megadriver) - identical to what you did with megaradeon. All the drivers selected at configure are linked into the same blob. Hardlink for each target for compatibility reasons. Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB Total: 10MiB Shared(pipe-loader) - create individual pipe-drivers and standalone state-tracker libraries (think of them as bla_dri + libGL). The pipe-driver is used by all ST. Note: the interface is not stable, unlike the dri modules. Hardlink for each target for compatibility reasons. Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB Total: 9.8MiB Current approach - at final link time, most state-trackers pull the gallium/drivers/$hw, via the above mentioned DRM_DESCRIPTOR, to create a independent HW specific library. Resulting in some duplication. dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB Total: 20.2MiB Note: currently egl-static and opencl are hardcoded to static and shared respectively. Both of which are will be converted with the next series. Summary: Static - savings scale with number of hardware (gallium/drivers). Shared - savings scale with number of state-trackers (gallium/state-tracker). -Emil Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/12] Cherry-pick nv50/nvc0 patches from gallium-nine
I went through the gallium-nine tree and picked out nouveau patches that are general bug-fixes. The first bunch I'd like to also get into 10.2. I've reviewed all of them and they make sense to me, but sending them out for public review as well in case there are any objections. Unless I hear objections, I'd like to push this by Friday. Christoph Bumiller (11): nv50,nvc0: always pull out bufctx on context destruction nv50: setup scissors on clear_render_target/depth_stencil nv50,nvc0: set constbufs dirty on pipe context switch nv50/ir/tgsi: TGSI_OPCODE_POW replicates its result nv50/ir/opt: fix constant folding with saturate modifier nv50/ir: fix lowering of predicated instructions (without defs) nv50/ir/tgsi: optimize KIL nv50,nvc0: handle guard band defines nv50,nvc0: allow 15,16,30 bpp display formats nvc0: use PRIxPTR for sizeof() nvc0: assert that we have vertex elements state Joakim Sindholt (1): nv50: count wrapped textures towards the tex_obj count .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp| 11 ++- .../nouveau/codegen/nv50_ir_lowering_nv50.cpp| 5 - .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 4 +++- src/gallium/drivers/nouveau/nv50/nv50_context.c | 7 ++- src/gallium/drivers/nouveau/nv50/nv50_formats.c | 8 src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 2 ++ src/gallium/drivers/nouveau/nv50/nv50_screen.c | 10 -- .../drivers/nouveau/nv50/nv50_state_validate.c | 4 src/gallium/drivers/nouveau/nv50/nv50_surface.c | 20 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 9 + src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 -- .../drivers/nouveau/nvc0/nvc0_state_validate.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 1 + 14 files changed, 71 insertions(+), 23 deletions(-) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/12] nv50/ir/tgsi: TGSI_OPCODE_POW replicates its result
From: Christoph Bumiller christoph.bumil...@speed.at Reviewed-by: Ilia Mirkin imir...@alum.mit.edu Cc: 10.2 mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index 3e44bf9..e24be51 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp @@ -2199,7 +2199,6 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) case TGSI_OPCODE_IMUL_HI: case TGSI_OPCODE_UMUL_HI: case TGSI_OPCODE_OR: - case TGSI_OPCODE_POW: case TGSI_OPCODE_SHL: case TGSI_OPCODE_ISHR: case TGSI_OPCODE_USHR: @@ -2254,6 +2253,11 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) FOR_EACH_DST_ENABLED_CHANNEL(0, c, tgsi) mkOp1(OP_MOV, TYPE_U32, dst0[c], fetchSrc(0, c)); break; + case TGSI_OPCODE_POW: + val0 = mkOp2v(op, TYPE_F32, getScratch(), fetchSrc(0, 0), fetchSrc(1, 0)); + FOR_EACH_DST_ENABLED_CHANNEL(0, c, tgsi) + mkOp1(OP_MOV, TYPE_F32, dst0[c], val0); + break; case TGSI_OPCODE_EX2: case TGSI_OPCODE_LG2: val0 = mkOp1(op, TYPE_F32, getScratch(), fetchSrc(0, 0))-getDef(0); -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/12] nv50: setup scissors on clear_render_target/depth_stencil
From: Christoph Bumiller e0425...@student.tuwien.ac.at [imirkin: add logic to also clear the regular scissors] Reviewed-by: Ilia Mirkin imir...@alum.mit.edu Cc: 10.2 mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/nouveau/nv50/nv50_surface.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c b/src/gallium/drivers/nouveau/nv50/nv50_surface.c index 1f37527..6e68fb8 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c @@ -288,6 +288,14 @@ nv50_clear_render_target(struct pipe_context *pipe, PUSH_REFN(push, bo, mt-base.domain | NOUVEAU_BO_WR); + BEGIN_NV04(push, NV50_3D(SCREEN_SCISSOR_HORIZ), 2); + PUSH_DATA (push, ( width 16) | dstx); + PUSH_DATA (push, (height 16) | dsty); + BEGIN_NV04(push, NV50_3D(SCISSOR_HORIZ(0)), 2); + PUSH_DATA (push, 8192 16); + PUSH_DATA (push, 8192 16); + nv50-scissors_dirty |= 1; + BEGIN_NV04(push, NV50_3D(RT_CONTROL), 1); PUSH_DATA (push, 1); BEGIN_NV04(push, NV50_3D(RT_ADDRESS_HIGH(0)), 5); @@ -325,7 +333,7 @@ nv50_clear_render_target(struct pipe_context *pipe, (z NV50_3D_CLEAR_BUFFERS_LAYER__SHIFT)); } - nv50-dirty |= NV50_NEW_FRAMEBUFFER; + nv50-dirty |= NV50_NEW_FRAMEBUFFER | NV50_NEW_SCISSOR; } static void @@ -364,6 +372,14 @@ nv50_clear_depth_stencil(struct pipe_context *pipe, PUSH_REFN(push, bo, mt-base.domain | NOUVEAU_BO_WR); + BEGIN_NV04(push, NV50_3D(SCREEN_SCISSOR_HORIZ), 2); + PUSH_DATA (push, ( width 16) | dstx); + PUSH_DATA (push, (height 16) | dsty); + BEGIN_NV04(push, NV50_3D(SCISSOR_HORIZ(0)), 2); + PUSH_DATA (push, 8192 16); + PUSH_DATA (push, 8192 16); + nv50-scissors_dirty |= 1; + BEGIN_NV04(push, NV50_3D(ZETA_ADDRESS_HIGH), 5); PUSH_DATAh(push, bo-offset + sf-offset); PUSH_DATA (push, bo-offset + sf-offset); @@ -390,7 +406,7 @@ nv50_clear_depth_stencil(struct pipe_context *pipe, (z NV50_3D_CLEAR_BUFFERS_LAYER__SHIFT)); } - nv50-dirty |= NV50_NEW_FRAMEBUFFER; + nv50-dirty |= NV50_NEW_FRAMEBUFFER | NV50_NEW_SCISSOR; } void -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/12] nv50/ir: fix lowering of predicated instructions (without defs)
From: Christoph Bumiller e0425...@student.tuwien.ac.at Note that predicated instructions with defs are still not supported because transformation to SSA doesn't handle them yet. Reviewed-by: Ilia Mirkin imir...@alum.mit.edu Cc: 10.2 mesa-sta...@lists.freedesktop.org --- src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp index 0fb7666..ed06def 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp @@ -1279,8 +1279,11 @@ NV50LoweringPreSSA::checkPredicate(Instruction *insn) Value *pred = insn-getPredicate(); Value *cdst; - if (!pred || pred-reg.file == FILE_FLAGS) + // FILE_PREDICATE will simply be changed to FLAGS on conversion to SSA + if (!pred || + pred-reg.file == FILE_FLAGS || pred-reg.file == FILE_PREDICATE) return; + cdst = bld.getSSA(1, FILE_FLAGS); bld.mkCmp(OP_SET, CC_NEU, insn-dType, cdst, insn-dType, bld.loadImm(NULL, 0), pred); -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/12] nv50/ir/opt: fix constant folding with saturate modifier
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index e6f8f69..1a2c2e6 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -561,7 +561,7 @@ ConstantFolding::expr(Instruction *i,
if (i-src(0).getImmediate(src0))
expr(i, src0, *i-getSrc(1)-asImm());
} else {
- i-op = OP_MOV;
+ i-op = i-saturate ? OP_SAT : OP_MOV; /* SAT handled by unary() */
}
}
@@ -612,6 +612,7 @@ ConstantFolding::unary(Instruction *i, const ImmediateValue
imm)
switch (i-op) {
case OP_NEG: res.data.f32 = -imm.reg.data.f32; break;
case OP_ABS: res.data.f32 = fabsf(imm.reg.data.f32); break;
+ case OP_SAT: res.data.f32 = CLAMP(imm.reg.data.f32, 0.0f, 1.0f); break;
case OP_RCP: res.data.f32 = 1.0f / imm.reg.data.f32; break;
case OP_RSQ: res.data.f32 = 1.0f / sqrtf(imm.reg.data.f32); break;
case OP_LG2: res.data.f32 = log2f(imm.reg.data.f32); break;
@@ -922,6 +923,7 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue imm0,
int s)
case OP_ABS:
case OP_NEG:
+ case OP_SAT:
case OP_LG2:
case OP_RCP:
case OP_SQRT:
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/12] nv50/ir/tgsi: optimize KIL
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index e24be51..a0f1fe1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -2457,7 +2457,12 @@ Converter::handleInstruction(const struct
tgsi_full_instruction *insn)
break;
case TGSI_OPCODE_KILL_IF:
val0 = new_LValue(func, FILE_PREDICATE);
+ mask = 0;
for (c = 0; c 4; ++c) {
+ const int s = tgsi.getSrc(0).getSwizzle(c);
+ if (mask (1 s))
+continue;
+ mask |= 1 s;
mkCmp(OP_SET, CC_LT, TYPE_F32, val0, TYPE_F32, fetchSrc(0, c), zero);
mkOp(OP_DISCARD, TYPE_NONE, NULL)-setPredicate(CC_P, val0);
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/12] nv50, nvc0: always pull out bufctx on context destruction
From: Christoph Bumiller christoph.bumil...@speed.at
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nv50/nv50_context.c | 7 ++-
src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 9 +
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.c
b/src/gallium/drivers/nouveau/nv50/nv50_context.c
index 52e14bf..f844592 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_context.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_context.c
@@ -122,12 +122,9 @@ nv50_destroy(struct pipe_context *pipe)
{
struct nv50_context *nv50 = nv50_context(pipe);
- if (nv50_context_screen(nv50)-cur_ctx == nv50) {
- nv50-base.pushbuf-kick_notify = NULL;
+ if (nv50_context_screen(nv50)-cur_ctx == nv50)
nv50_context_screen(nv50)-cur_ctx = NULL;
- nouveau_pushbuf_bufctx(nv50-base.pushbuf, NULL);
- }
- /* need to flush before destroying the bufctx */
+ nouveau_pushbuf_bufctx(nv50-base.pushbuf, NULL);
nouveau_pushbuf_kick(nv50-base.pushbuf, nv50-base.pushbuf-channel);
nv50_context_unreference_resources(nv50);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index 83c8c34..e5040c4 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -123,11 +123,12 @@ nvc0_destroy(struct pipe_context *pipe)
{
struct nvc0_context *nvc0 = nvc0_context(pipe);
- if (nvc0-screen-cur_ctx == nvc0) {
- nvc0-base.pushbuf-kick_notify = NULL;
+ if (nvc0-screen-cur_ctx == nvc0)
nvc0-screen-cur_ctx = NULL;
- nouveau_pushbuf_bufctx(nvc0-base.pushbuf, NULL);
- }
+ /* Unset bufctx, we don't want to revalidate any resources after the flush.
+* Other contexts will always set their bufctx again on action calls.
+*/
+ nouveau_pushbuf_bufctx(nvc0-base.pushbuf, NULL);
nouveau_pushbuf_kick(nvc0-base.pushbuf, nvc0-base.pushbuf-channel);
nvc0_context_unreference_resources(nvc0);
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/12] nv50, nvc0: set constbufs dirty on pipe context switch
From: Christoph Bumiller christoph.bumil...@speed.at
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nv50/nv50_state_validate.c | 4
src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
index 18451c7..1dcb961 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
@@ -400,6 +400,10 @@ nv50_switch_pipe_context(struct nv50_context *ctx_to)
ctx_to-viewports_dirty = ~0;
ctx_to-scissors_dirty = ~0;
+ ctx_to-constbuf_dirty[0] =
+ ctx_to-constbuf_dirty[1] =
+ ctx_to-constbuf_dirty[2] = (1 NV50_MAX_PIPE_CONSTBUFS) - 1;
+
if (!ctx_to-vertex)
ctx_to-dirty = ~(NV50_NEW_VERTEX | NV50_NEW_ARRAYS);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
index 40016fc..dcec910 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
@@ -531,6 +531,7 @@ nvc0_switch_pipe_context(struct nvc0_context *ctx_to)
for (s = 0; s 5; ++s) {
ctx_to-samplers_dirty[s] = ~0;
ctx_to-textures_dirty[s] = ~0;
+ ctx_to-constbuf_dirty[s] = (1 NVC0_MAX_PIPE_CONSTBUFS) - 1;
}
if (!ctx_to-vertex)
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/12] nv50, nvc0: allow 15, 16, 30 bpp display formats
From: Christoph Bumiller christoph.bumil...@speed.at Reviewed-by: Ilia Mirkin imir...@alum.mit.edu --- src/gallium/drivers/nouveau/nv50/nv50_formats.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c b/src/gallium/drivers/nouveau/nv50/nv50_formats.c index 3af34c1..ff33654 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_formats.c @@ -194,9 +194,9 @@ const struct nv50_format nv50_format_table[PIPE_FORMAT_COUNT] = SXB(S8X24_UINT, C0, S8_Z24, T), SXB(X32_S8X24_UINT, C1, Z32_S8_X24, T), - F3B(B5G6R5_UNORM, B5G6R5_UNORM, C2, C1, C0, xx, UNORM, 5_6_5, T), - C4B(B5G5R5A1_UNORM, BGR5_A1_UNORM, C2, C1, C0, C3, UNORM, 5_5_5_1, TB), - F3B(B5G5R5X1_UNORM, BGR5_X1_UNORM, C2, C1, C0, xx, UNORM, 5_5_5_1, TB), + F3B(B5G6R5_UNORM, B5G6R5_UNORM, C2, C1, C0, xx, UNORM, 5_6_5, TD), + C4B(B5G5R5A1_UNORM, BGR5_A1_UNORM, C2, C1, C0, C3, UNORM, 5_5_5_1, TD), + F3B(B5G5R5X1_UNORM, BGR5_X1_UNORM, C2, C1, C0, xx, UNORM, 5_5_5_1, TD), C4B(B4G4R4A4_UNORM, NONE, C2, C1, C0, C3, UNORM, 4_4_4_4, T), F3B(B4G4R4X4_UNORM, NONE, C2, C1, C0, xx, UNORM, 4_4_4_4, T), F3B(R9G9B9E5_FLOAT, NONE, C0, C1, C2, xx, FLOAT, 9_9_9_E5, T), @@ -204,7 +204,7 @@ const struct nv50_format nv50_format_table[PIPE_FORMAT_COUNT] = C4A(R10G10B10A2_UNORM, RGB10_A2_UNORM, C0, C1, C2, C3, UNORM, 10_10_10_2, IBV, 0), C4A(B10G10R10A2_UNORM, BGR10_A2_UNORM, C2, C1, C0, C3, UNORM, 10_10_10_2, - TBV, 1), + TDV, 1), C4A(R10G10B10A2_SNORM, NONE, C0, C1, C2, C3, SNORM, 10_10_10_2, TV, 0), C4A(B10G10R10A2_SNORM, NONE, C2, C1, C0, C3, SNORM, 10_10_10_2, TV, 1), C4A(R10G10B10A2_UINT, RGB10_A2_UINT, C0, C1, C2, C3, UINT, 10_10_10_2, TRV, 0), -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/12] nv50,nvc0: handle guard band defines
From: Christoph Bumiller christoph.bumil...@speed.at [imirkin: moved default case out of switch] Reviewed-by: Ilia Mirkin imir...@alum.mit.edu --- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 10 -- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 -- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 68d30ea..36a4ad1 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c @@ -286,10 +286,16 @@ nv50_screen_get_paramf(struct pipe_screen *pscreen, enum pipe_capf param) return 16.0f; case PIPE_CAPF_MAX_TEXTURE_LOD_BIAS: return 4.0f; - default: - NOUVEAU_ERR(unknown PIPE_CAP %d\n, param); + case PIPE_CAPF_GUARD_BAND_LEFT: + case PIPE_CAPF_GUARD_BAND_TOP: return 0.0f; + case PIPE_CAPF_GUARD_BAND_RIGHT: + case PIPE_CAPF_GUARD_BAND_BOTTOM: + return 0.0f; /* that or infinity */ } + + NOUVEAU_ERR(unknown PIPE_CAPF %d\n, param); + return 0.0f; } static void diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index cccfe2b..9f89f31 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -294,10 +294,16 @@ nvc0_screen_get_paramf(struct pipe_screen *pscreen, enum pipe_capf param) return 16.0f; case PIPE_CAPF_MAX_TEXTURE_LOD_BIAS: return 15.0f; - default: - NOUVEAU_ERR(unknown PIPE_CAP %d\n, param); + case PIPE_CAPF_GUARD_BAND_LEFT: + case PIPE_CAPF_GUARD_BAND_TOP: return 0.0f; + case PIPE_CAPF_GUARD_BAND_RIGHT: + case PIPE_CAPF_GUARD_BAND_BOTTOM: + return 0.0f; /* that or infinity */ } + + NOUVEAU_ERR(unknown PIPE_CAPF %d\n, param); + return 0.0f; } static int -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/12] nvc0: use PRIxPTR for sizeof()
From: Christoph Bumiller christoph.bumil...@speed.at
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index 1d59fc4..8724cc5 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
@@ -512,7 +512,7 @@ nvc0_program_dump(struct nvc0_program *prog)
if (prog-type != PIPE_SHADER_COMPUTE) {
for (pos = 0; pos sizeof(prog-hdr) / sizeof(prog-hdr[0]); ++pos)
- debug_printf(HDR[%02lx] = 0x%08x\n,
+ debug_printf(HDR[%02PRIxPTR] = 0x%08x\n,
pos * sizeof(prog-hdr[0]), prog-hdr[pos]);
}
debug_printf(shader binary code (0x%x bytes):, prog-code_size);
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/12] nvc0: assert that we have vertex elements state
From: Christoph Bumiller christoph.bumil...@speed.at
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
index c58d6da..83d406d 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
@@ -423,6 +423,7 @@ nvc0_vertex_arrays_validate(struct nvc0_context *nvc0)
nouveau_bufctx_reset(nvc0-bufctx_3d, NVC0_BIND_VTX);
+ assert(vertex);
if (unlikely(vertex-need_conversion) ||
unlikely(nvc0-vertprog-vp.edgeflag PIPE_MAX_ATTRIBS)) {
vbo_mode = 3;
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/12] nv50: count wrapped textures towards the tex_obj count
From: Joakim Sindholt opensou...@zhasha.com But don't count their size towards the allocated memory, since that belongs to whoever created it. Reviewed-by: Ilia Mirkin imir...@alum.mit.edu --- src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c index 513d8f9..4c55179 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c @@ -404,6 +404,8 @@ nv50_miptree_from_handle(struct pipe_screen *pscreen, mt-level[0].offset = 0; mt-level[0].tile_mode = mt-base.bo-config.nv50.tile_mode; + NOUVEAU_DRV_STAT(nouveau_screen(pscreen), tex_obj_current_count, 1); + /* no need to adjust bo reference count */ return mt-base.base; } -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/8] gallium: create TGSI_PROPERTY to disable viewport and clipping
Hi,
Could somebody from VMWare please review this patch? It's for st/nine
(open d3d9 state tracker).
Thanks,
Marek
On Sat, May 17, 2014 at 1:20 AM, Automated rebase
david.heidelber...@ixit.cz wrote:
From: Christoph Bumiller e0425...@student.tuwien.ac.at
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 16
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 4
src/gallium/docs/source/tgsi.rst | 9 +
src/gallium/include/pipe/p_shader_tokens.h | 3 ++-
5 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 5b6e47f..c3e7118 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -120,7 +120,8 @@ const char *tgsi_property_names[TGSI_PROPERTY_COUNT] =
FS_COORD_PIXEL_CENTER,
FS_COLOR0_WRITES_ALL_CBUFS,
FS_DEPTH_LAYOUT,
- VS_PROHIBIT_UCPS
+ VS_PROHIBIT_UCPS,
+ VS_POSITION_WINDOW_SPACE
};
const char *tgsi_type_names[5] =
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 2bf93ee..bd0a3f7 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -173,6 +173,7 @@ struct ureg_program
unsigned char property_fs_coord_pixel_center; /* =
TGSI_FS_COORD_PIXEL_CENTER_* */
unsigned char property_fs_color0_writes_all_cbufs; /* =
TGSI_FS_COLOR0_WRITES_ALL_CBUFS * */
unsigned char property_fs_depth_layout; /* TGSI_FS_DEPTH_LAYOUT */
+ boolean property_vs_window_space_position; /*
TGSI_VS_WINDOW_SPACE_POSITION */
unsigned nr_addrs;
unsigned nr_preds;
@@ -331,6 +332,13 @@ ureg_property_fs_depth_layout(struct ureg_program *ureg,
ureg-property_fs_depth_layout = fs_depth_layout;
}
+void
+ureg_property_vs_window_space_position(struct ureg_program *ureg,
+ boolean vs_window_space_position)
+{
+ ureg-property_vs_window_space_position = vs_window_space_position;
+}
+
struct ureg_src
ureg_DECL_fs_input_cyl_centroid(struct ureg_program *ureg,
unsigned semantic_name,
@@ -1508,6 +1516,14 @@ static void emit_decls( struct ureg_program *ureg )
ureg-property_fs_depth_layout);
}
+ if (ureg-property_vs_window_space_position) {
+ assert(ureg-processor == TGSI_PROCESSOR_VERTEX);
+
+ emit_property(ureg,
+TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION,
+ureg-property_vs_window_space_position);
+ }
+
if (ureg-processor == TGSI_PROCESSOR_VERTEX) {
for (i = 0; i UREG_MAX_INPUT; i++) {
if (ureg-vs_inputs[i/32] (1 (i%32))) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index a0a50b7..28edea6 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -184,6 +184,10 @@ void
ureg_property_fs_depth_layout(struct ureg_program *ureg,
unsigned fs_depth_layout);
+void
+ureg_property_vs_window_space_position(struct ureg_program *ureg,
+ boolean vs_window_space_position);
+
/***
* Build shader declarations:
diff --git a/src/gallium/docs/source/tgsi.rst
b/src/gallium/docs/source/tgsi.rst
index 9500b9d..2ca3c3b 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -2848,6 +2848,15 @@ input primitive. Each invocation will have a different
TGSI_SEMANTIC_INVOCATIONID system value set. If not specified, assumed to
be 1.
+VS_WINDOW_SPACE_POSITION
+
+If this property is set on the vertex shader, the TGSI_SEMANTIC_POSITION
output
+is assumed to contain window space coordinates.
+Division of X,Y,Z by W and the viewport transformation are disabled, and 1/W
is
+directly taken from the 4-th component of the shader output.
+Naturally, clipping is not performed on window coordinates either.
+The effect of this property is undefined if a geometry or tessellation shader
+are in use.
Texture Sampling and Texture Formats
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index d095bd3..9261b79 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -237,7 +237,8 @@ union tgsi_immediate_data
#define TGSI_PROPERTY_FS_DEPTH_LAYOUT6
#define TGSI_PROPERTY_VS_PROHIBIT_UCPS 7
#define TGSI_PROPERTY_GS_INVOCATIONS 8
-#define TGSI_PROPERTY_COUNT 9
+#define TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION 9
+#define TGSI_PROPERTY_COUNT 10
struct tgsi_property {
unsigned Type
Re: [Mesa-dev] [PATCH 15/23] configure: add HAVE_GALLIUM_STATIC_TARGETS
On 21/05/14 00:32, Marek Olšák wrote: Thanks, that makes sense. I think the static approach is better, but I don't have a strong opinion about that. Did you also consider merging the API libraries? For DRI, we need to export __driDriverExtensions. For VDPAU, we need to export vdp_imp_device_create_x11. Etc. + $hw_winsys_screen_create for vdpau-gl interop. Thanks for the reminder of the exported symbol hunt. I will still need to case people in order to get the final patches reviewed :\ However, having a single blob for multiple APIs should work, right? In theory - it should work, in practise - never tried. Not at all keen on the idea though: - No benefit wrt the space saved (compared to shared/pipe-loader). - Pulling more lib deps into the dri modules. Currently we're linking against libgcc_s and libstdc++ which is causing enough issues as some people ship their own version of the libraries. Adding X11/xcb lib deps will make things even worse. AFAICS the proprietary drivers fix this by static linking although every reference I have seen says that it's a bad idea, with little to no justification. Note: I'm not saying that shipping the above libraries is a bad idea when distributing binaries, but it's _slightly_ annoying for users. -Emil Marek On Tue, May 20, 2014 at 10:04 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 20/05/14 16:21, Marek Olšák wrote: Well, I have never studied the build system, so I don't know exactly what this series does and how it affects the size of the drivers. Could you please summarize what binaries are created, how big they are, and compare the shared vs static approach vs the current way? And what is the role of the pipe loader? Seems like I jumped into too many presumptions in the introductory email :\ Pipe-driver - gallium/drivers/$hw and its respective winsys built into a standalone loadable module. Installed as gallium-pipe/pipe_(r600|radeonsi|nouveau).so Pipe-loader - aux module (linked into the final library) that loads the appropriate pipe-driver. Static(megadriver) - identical to what you did with megaradeon. All the drivers selected at configure are linked into the same blob. Hardlink for each target for compatibility reasons. Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB Total: 10MiB Shared(pipe-loader) - create individual pipe-drivers and standalone state-tracker libraries (think of them as bla_dri + libGL). The pipe-driver is used by all ST. Note: the interface is not stable, unlike the dri modules. Hardlink for each target for compatibility reasons. Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB Total: 9.8MiB Current approach - at final link time, most state-trackers pull the gallium/drivers/$hw, via the above mentioned DRM_DESCRIPTOR, to create a independent HW specific library. Resulting in some duplication. dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB Total: 20.2MiB Note: currently egl-static and opencl are hardcoded to static and shared respectively. Both of which are will be converted with the next series. Summary: Static - savings scale with number of hardware (gallium/drivers). Shared - savings scale with number of state-trackers (gallium/state-tracker). -Emil Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] targets/opencl: Fix (static) linking with LLVM (v2)
On 19/05/14 16:02, Kai Wasserbäch wrote:
Without this, I get linking failures (static linking).
The static linking is sort of required for me, because otherwise Steam and
applications using the Steam runtime regularily fail because my LLVM was
compiled and linked against a newer libgcc_s, libstdc++, etc. and uses
features from those newer versions. And instead of Steam just not
starting, my X starts crashing, whenever libGL fails to load a (32 bit)
driver.
Since I hate crashes of X and I don't think Valve/Steam will behave like
a proper distribution soon (rebuilds versus current Debian Testing, since
they base their Steam OS off that), I need a radeonsi which carries its
own LLVM within and doesn't care about what the runtime sets. This means
linking Mesa statically.
v1 → v2: Move logic to configure.ac
Signed-off-by: Kai Wasserbäch k...@dev.carbon-project.org
---
Dear Emil,
I hope this is the right place for adding the two additional modules.
If you accept this patch, please push it for me, I don't have commit access.
Hi Kai,
Not a llvm person here, although the patch looks good.
Acked-by: Emil Velikov emil.l.veli...@gmail.com
I'm going to commit it by the end of this week unless someone comes
forward/beats me to it.
-Emil
Cheers,
Kai
configure.ac | 7 +++
1 file changed, 7 insertions(+)
diff --git a/configure.ac b/configure.ac
index 4e4d761..b4920ba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1658,6 +1658,13 @@ if test x$enable_gallium_llvm = xyes; then
if $LLVM_CONFIG --components | grep -qw 'option'; then
LLVM_COMPONENTS=${LLVM_COMPONENTS} option
fi
+# Current OpenCL/Clover and LLVM 3.5 require ObjCARCOpts and
ProfileData
+if $LLVM_CONFIG --components | grep -qw 'objcarcopts'; then
+LLVM_COMPONENTS=${LLVM_COMPONENTS} objcarcopts
+fi
+if $LLVM_CONFIG --components | grep -qw 'profiledata'; then
+LLVM_COMPONENTS=${LLVM_COMPONENTS} profiledata
+fi
fi
DEFINES=${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT
-DLLVM_VERSION_PATCH=$LLVM_VERSION_PATCH
MESA_LLVM=1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] targets/xa: limit the amount of exported symbols
On 14/05/14 20:16, Thomas Hellstrom wrote:
Hi, I'm on vacation, so I have no way of testing this until next week.
Hi Thomas,
With the next week upon us can you spare a few minutes to check that I've not
butchered the API ?
Perhaps you'll have the chance to poke Brian to see patches 3/4 and 4/4 :)
Thanks
Emil
/Thomas
On 05/14/2014 02:04 PM, Emil Velikov wrote:
ping for the series
If there is no objections I would like to push these over the weekend.
Cheers,
Emil
On 09/05/14 18:10, Emil Velikov wrote:
ping
Thomas, Rob,
Can you please take a look if the patch makes sense ? I have double checked
that only the required functions are exported although I may have missed
something. IMHO you both know XA API a lot better than me :)
Thanks
Emil
On 02/05/14 22:02, Emil Velikov wrote:
In the presence of LLVM the final library exports every symbol from
the llvm namespace. Resolve this by using a version script (w/o the
version/name tag).
Considering that there are only ~35 symbols, explicitly list them
to minimize the chances of rogue symbols sneaking in.
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/targets/xa/Makefile.am | 1 +
src/gallium/targets/xa/xa.sym | 38
++
2 files changed, 39 insertions(+)
create mode 100644 src/gallium/targets/xa/xa.sym
diff --git a/src/gallium/targets/xa/Makefile.am
b/src/gallium/targets/xa/Makefile.am
index 2619e57..17cd6c4 100644
--- a/src/gallium/targets/xa/Makefile.am
+++ b/src/gallium/targets/xa/Makefile.am
@@ -63,6 +63,7 @@ endif
libxatracker_la_LDFLAGS = \
-no-undefined \
-version-number $(XA_MAJOR):$(XA_MINOR):$(XA_TINY) \
+ -Wl,--version-script=$(top_srcdir)/src/gallium/targets/xa/xa.sym \
$(GC_SECTIONS) \
$(LD_NO_UNDEFINED)
diff --git a/src/gallium/targets/xa/xa.sym b/src/gallium/targets/xa/xa.sym
new file mode 100644
index 000..9c7f422
--- /dev/null
+++ b/src/gallium/targets/xa/xa.sym
@@ -0,0 +1,38 @@
+{
+ global:
+ xa_composite_allocation;
+ xa_composite_check_accelerated;
+ xa_composite_done;
+ xa_composite_prepare;
+ xa_composite_rect;
+ xa_context_create;
+ xa_context_default;
+ xa_context_destroy;
+ xa_context_flush;
+ xa_copy;
+ xa_copy_done;
+ xa_copy_prepare;
+ xa_fence_get;
+ xa_fence_wait;
+ xa_fence_destroy;
+ xa_format_check_supported;
+ xa_solid;
+ xa_solid_done;
+ xa_solid_prepare;
+ xa_surface_create;
+ xa_surface_dma;
+ xa_surface_format;
+ xa_surface_from_handle;
+ xa_surface_handle;
+ xa_surface_map;
+ xa_surface_redefine;
+ xa_surface_ref;
+ xa_surface_unmap;
+ xa_surface_unref;
+ xa_tracker_create;
+ xa_tracker_destroy;
+ xa_tracker_version;
+ xa_yuv_planar_blit;
+ local:
+ *;
+};
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] targets/osmesa: limit the amount of exported symbols
Just realised that I had forgotten about mangled gl. So this patch will need
an extra line in the global symbols list.
mgl*;
I would still appreciate if someone familiar with OSMesa's api can take a look
Cheers,
Emil
On 09/05/14 18:13, Emil Velikov wrote:
ping,
Brian, you seem to be the only person that came near osmesa over the last few
years. Can you take a look at the patch below?
Cheers
Emil
On 02/05/14 22:02, Emil Velikov wrote:
Explicitly list all the OSMesa* symbols and wildcast the gl*
ones.
Cc: Brian Paul bri...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/targets/osmesa/Makefile.am | 1 +
src/gallium/targets/osmesa/osmesa.sym | 18 ++
2 files changed, 19 insertions(+)
create mode 100644 src/gallium/targets/osmesa/osmesa.sym
diff --git a/src/gallium/targets/osmesa/Makefile.am
b/src/gallium/targets/osmesa/Makefile.am
index 067f980..0ec8a26 100644
--- a/src/gallium/targets/osmesa/Makefile.am
+++ b/src/gallium/targets/osmesa/Makefile.am
@@ -45,6 +45,7 @@ lib@OSMESA_LIB@_la_LDFLAGS = \
-module \
-no-undefined \
-version-number @OSMESA_VERSION@ \
+
-Wl,--version-script=$(top_srcdir)/src/gallium/targets/osmesa/osmesa.sym \
$(GC_SECTIONS) \
$(LD_NO_UNDEFINED)
diff --git a/src/gallium/targets/osmesa/osmesa.sym
b/src/gallium/targets/osmesa/osmesa.sym
new file mode 100644
index 000..b8230e0
--- /dev/null
+++ b/src/gallium/targets/osmesa/osmesa.sym
@@ -0,0 +1,18 @@
+{
+global:
+OSMesaColorClamp;
+OSMesaCreateContext;
+OSMesaCreateContextExt;
+OSMesaDestroyContext;
+OSMesaGetColorBuffer;
+OSMesaGetCurrentContext;
+OSMesaGetDepthBuffer;
+OSMesaGetIntegerv;
+OSMesaGetProcAddress;
+OSMesaMakeCurrent;
+OSMesaPixelStore;
+OSMesaPostprocess;
+gl*;
+local:
+*;
+};
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] targets/libgl-xlib: hide all the exported symbol mayhem
Similar to 3/4 I will the mangled gl symbols to the global list.
mgl*;
Other than that, an acked-by would be appreciated :)
-Emil
On 09/05/14 18:15, Emil Velikov wrote:
Ping
Btw the TODO list here was for my personal reference, I'll change/nuke it
before pushing.
Cheers,
Emil
On 02/05/14 22:02, Emil Velikov wrote:
TODO:
- properly cleanup all the _glapi* symbols
- XMesa*
-- no sign of the header even being distributed
-- mesa-demos uses it to the point that the relevant code is not compiled
-- the classic driver (x11) exibits the same issues
Brian,
Do you know of any users of the XMesa* functions outside of mesa-demos ?
AFAICS we should be safe with dropping PUBLIC although I may have missed
something. As a follow up someone can cleanup all the mesa-demos code :)
Cc: Brian Paul bri...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/targets/libgl-xlib/Makefile.am| 1 +
src/gallium/targets/libgl-xlib/libgl-xlib.sym | 6 ++
2 files changed, 7 insertions(+)
create mode 100644 src/gallium/targets/libgl-xlib/libgl-xlib.sym
diff --git a/src/gallium/targets/libgl-xlib/Makefile.am
b/src/gallium/targets/libgl-xlib/Makefile.am
index 4ee364e..3718243 100644
--- a/src/gallium/targets/libgl-xlib/Makefile.am
+++ b/src/gallium/targets/libgl-xlib/Makefile.am
@@ -47,6 +47,7 @@ libGL_la_SOURCES = xlib.c
libGL_la_LDFLAGS = \
-no-undefined \
-version-number $(GL_MAJOR):$(GL_MINOR):$(GL_TINY) \
+
-Wl,--version-script=$(top_srcdir)/src/gallium/targets/libgl-xlib/libgl-xlib.sym
\
$(GC_SECTIONS) \
$(LD_NO_UNDEFINED)
diff --git a/src/gallium/targets/libgl-xlib/libgl-xlib.sym
b/src/gallium/targets/libgl-xlib/libgl-xlib.sym
new file mode 100644
index 000..d6cd23d
--- /dev/null
+++ b/src/gallium/targets/libgl-xlib/libgl-xlib.sym
@@ -0,0 +1,6 @@
+{
+global:
+gl*;
+local:
+*;
+};
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Fixing nv30 fbo attachments
On Tue, May 20, 2014 at 6:20 PM, Marek Olšák mar...@gmail.com wrote: On Tue, May 20, 2014 at 11:04 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Tue, May 20, 2014 at 4:51 PM, Marek Olšák mar...@gmail.com wrote: On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, I attempted doing this a while back, before I really understood what was going on. I got some advice that went totally over my head, and I dropped the issue. I think I'm much better-prepared to tackle the issue this time around. To recap, nv30 (and nv40) hw can't handle certain color/depth format combinations. Specifically, a 16-bit color format must be paired with a 16-bit depth format, and a 32-bit color format must be paired with a 32-bit depth format (well, Z24S8). This HW also can't handle different per-attachment sizes, and also the linearity of all the attachments must be the same. (Whether a surface is linear or not is _generally_ dictated by its w/h, but not always -- POT textures can sometimes end up allocated linearly by e.g. the ddx, or something else.) The different sizes are handled by not exposing ARB_fbo. However the rest of the cases remain. Now that I kinda understand how things are structured, I was thinking of doing the following: When rendering (i.e. draw_vbo co) and the fbo has changed (and has one of the problems above), I would instead put in a temporary texture as the depth attachment. Before actually drawing, I would blit from the real target texture into the temporary texture, and then when rendering is done, blit back from the temp texture back into the target. This deals with the target texture getting modified between draws with various blits/mapping/whatever. This means that you'll only get 16 bits of depth even if you ask for 24 with a 16-bit color format, but the alternative seems too complex/costly. So there are a few questions from this approach: 1. Where do I get the temporary texture from? (And more importantly -- when... what happens if allocation fails?) 2. Having to blit the depth texture back and forth on every draw seems _really_ wasteful... anything I can do about that? You can do that in set_framebuffer_state. When binding, blit to a depth buffer which matches the colorbuffer format. When unbinding, blit back. set_framebuffer_state doesn't allow an error to be returned. Should I just print a warning and move on? Yes, because you have no other choice. I guess I'm still not 100% on all the terminology -- what do you mean exactly by bind/unbind? Do you mean the transfer_map/unmap stuff? So basically I would blit once on set_framebuffer_state, and then blit back and forth on resource map/unmap, and only ever render to the temporary buffer without worrying about blitting wihle rendering? bind is when a buffer is set, unbind is when the buffer is unset. set_framebuffer_state unbinds the current framebuffer and binds a new one. transfer_map/unmap must use the resource which contains the latest data, there is no doubt about that. If there are no transfers, you only have to do the blits between 32-bit and 16-bit in set_framebuffer_state, because that's the only place where the framebuffer is changed. OK, I see. That makes sense, I think. So I just have to be careful with the transfers to make sure to blit things back first (or maybe I don't even have to do that, haven't checked the transfer api), similar for blit. And I'll need to turn off ARB_buffer_storage. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] haiku: Add missing u_memory.h for FREE()
---
.../targets/haiku-softpipe/GalliumContext.cpp |1 +
.../targets/haiku-softpipe/GalliumFramebuffer.cpp |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
index 52cd764..d6b5f85 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
@@ -26,6 +26,7 @@ extern C {
#include state_tracker/st_gl_api.h
#include state_tracker/st_manager.h
#include state_tracker/sw_winsys.h
+#include util/u_memory.h
#include hgl_sw_winsys.h
#include target-helpers/inline_sw_helper.h
diff --git a/src/gallium/targets/haiku-softpipe/GalliumFramebuffer.cpp
b/src/gallium/targets/haiku-softpipe/GalliumFramebuffer.cpp
index dd726ef..f367d9d 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumFramebuffer.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumFramebuffer.cpp
@@ -16,6 +16,7 @@ extern C {
#include main/renderbuffer.h
#include pipe/p_format.h
#include state_tracker/st_manager.h
+#include util/u_memory.h
}
#include GalliumContext.h
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Fixing nv30 fbo attachments
ARB_buffer_storage doesn't have anything to do with framebuffers. Marek On Wed, May 21, 2014 at 2:27 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Tue, May 20, 2014 at 6:20 PM, Marek Olšák mar...@gmail.com wrote: On Tue, May 20, 2014 at 11:04 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Tue, May 20, 2014 at 4:51 PM, Marek Olšák mar...@gmail.com wrote: On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, I attempted doing this a while back, before I really understood what was going on. I got some advice that went totally over my head, and I dropped the issue. I think I'm much better-prepared to tackle the issue this time around. To recap, nv30 (and nv40) hw can't handle certain color/depth format combinations. Specifically, a 16-bit color format must be paired with a 16-bit depth format, and a 32-bit color format must be paired with a 32-bit depth format (well, Z24S8). This HW also can't handle different per-attachment sizes, and also the linearity of all the attachments must be the same. (Whether a surface is linear or not is _generally_ dictated by its w/h, but not always -- POT textures can sometimes end up allocated linearly by e.g. the ddx, or something else.) The different sizes are handled by not exposing ARB_fbo. However the rest of the cases remain. Now that I kinda understand how things are structured, I was thinking of doing the following: When rendering (i.e. draw_vbo co) and the fbo has changed (and has one of the problems above), I would instead put in a temporary texture as the depth attachment. Before actually drawing, I would blit from the real target texture into the temporary texture, and then when rendering is done, blit back from the temp texture back into the target. This deals with the target texture getting modified between draws with various blits/mapping/whatever. This means that you'll only get 16 bits of depth even if you ask for 24 with a 16-bit color format, but the alternative seems too complex/costly. So there are a few questions from this approach: 1. Where do I get the temporary texture from? (And more importantly -- when... what happens if allocation fails?) 2. Having to blit the depth texture back and forth on every draw seems _really_ wasteful... anything I can do about that? You can do that in set_framebuffer_state. When binding, blit to a depth buffer which matches the colorbuffer format. When unbinding, blit back. set_framebuffer_state doesn't allow an error to be returned. Should I just print a warning and move on? Yes, because you have no other choice. I guess I'm still not 100% on all the terminology -- what do you mean exactly by bind/unbind? Do you mean the transfer_map/unmap stuff? So basically I would blit once on set_framebuffer_state, and then blit back and forth on resource map/unmap, and only ever render to the temporary buffer without worrying about blitting wihle rendering? bind is when a buffer is set, unbind is when the buffer is unset. set_framebuffer_state unbinds the current framebuffer and binds a new one. transfer_map/unmap must use the resource which contains the latest data, there is no doubt about that. If there are no transfers, you only have to do the blits between 32-bit and 16-bit in set_framebuffer_state, because that's the only place where the framebuffer is changed. OK, I see. That makes sense, I think. So I just have to be careful with the transfers to make sure to blit things back first (or maybe I don't even have to do that, haven't checked the transfer api), similar for blit. And I'll need to turn off ARB_buffer_storage. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Fixing nv30 fbo attachments
Can you not render to a texture buffer? That might not be supported by nv30 actually. On Tue, May 20, 2014 at 8:49 PM, Marek Olšák mar...@gmail.com wrote: ARB_buffer_storage doesn't have anything to do with framebuffers. Marek On Wed, May 21, 2014 at 2:27 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Tue, May 20, 2014 at 6:20 PM, Marek Olšák mar...@gmail.com wrote: On Tue, May 20, 2014 at 11:04 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Tue, May 20, 2014 at 4:51 PM, Marek Olšák mar...@gmail.com wrote: On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, I attempted doing this a while back, before I really understood what was going on. I got some advice that went totally over my head, and I dropped the issue. I think I'm much better-prepared to tackle the issue this time around. To recap, nv30 (and nv40) hw can't handle certain color/depth format combinations. Specifically, a 16-bit color format must be paired with a 16-bit depth format, and a 32-bit color format must be paired with a 32-bit depth format (well, Z24S8). This HW also can't handle different per-attachment sizes, and also the linearity of all the attachments must be the same. (Whether a surface is linear or not is _generally_ dictated by its w/h, but not always -- POT textures can sometimes end up allocated linearly by e.g. the ddx, or something else.) The different sizes are handled by not exposing ARB_fbo. However the rest of the cases remain. Now that I kinda understand how things are structured, I was thinking of doing the following: When rendering (i.e. draw_vbo co) and the fbo has changed (and has one of the problems above), I would instead put in a temporary texture as the depth attachment. Before actually drawing, I would blit from the real target texture into the temporary texture, and then when rendering is done, blit back from the temp texture back into the target. This deals with the target texture getting modified between draws with various blits/mapping/whatever. This means that you'll only get 16 bits of depth even if you ask for 24 with a 16-bit color format, but the alternative seems too complex/costly. So there are a few questions from this approach: 1. Where do I get the temporary texture from? (And more importantly -- when... what happens if allocation fails?) 2. Having to blit the depth texture back and forth on every draw seems _really_ wasteful... anything I can do about that? You can do that in set_framebuffer_state. When binding, blit to a depth buffer which matches the colorbuffer format. When unbinding, blit back. set_framebuffer_state doesn't allow an error to be returned. Should I just print a warning and move on? Yes, because you have no other choice. I guess I'm still not 100% on all the terminology -- what do you mean exactly by bind/unbind? Do you mean the transfer_map/unmap stuff? So basically I would blit once on set_framebuffer_state, and then blit back and forth on resource map/unmap, and only ever render to the temporary buffer without worrying about blitting wihle rendering? bind is when a buffer is set, unbind is when the buffer is unset. set_framebuffer_state unbinds the current framebuffer and binds a new one. transfer_map/unmap must use the resource which contains the latest data, there is no doubt about that. If there are no transfers, you only have to do the blits between 32-bit and 16-bit in set_framebuffer_state, because that's the only place where the framebuffer is changed. OK, I see. That makes sense, I think. So I just have to be careful with the transfers to make sure to blit things back first (or maybe I don't even have to do that, haven't checked the transfer api), similar for blit. And I'll need to turn off ARB_buffer_storage. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/8] gallium: create TGSI_PROPERTY to disable viewport and clipping
It's not relevant to anything we have. The last I looked st/nine wasn't even an
umd. Everything that's needed for a d3d9 (and d3d10) umd's has already been
added to gallium, we don't have any patches against core gallium that we've
been keeping from the community. All we could do is review the patch for
code-quality, but so does everyone else.
z
- Original Message -
Hi,
Could somebody from VMWare please review this patch? It's for st/nine
(open d3d9 state tracker).
Thanks,
Marek
On Sat, May 17, 2014 at 1:20 AM, Automated rebase
david.heidelber...@ixit.cz wrote:
From: Christoph Bumiller e0425...@student.tuwien.ac.at
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 16
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 4
src/gallium/docs/source/tgsi.rst | 9 +
src/gallium/include/pipe/p_shader_tokens.h | 3 ++-
5 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 5b6e47f..c3e7118 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -120,7 +120,8 @@ const char *tgsi_property_names[TGSI_PROPERTY_COUNT] =
FS_COORD_PIXEL_CENTER,
FS_COLOR0_WRITES_ALL_CBUFS,
FS_DEPTH_LAYOUT,
- VS_PROHIBIT_UCPS
+ VS_PROHIBIT_UCPS,
+ VS_POSITION_WINDOW_SPACE
};
const char *tgsi_type_names[5] =
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 2bf93ee..bd0a3f7 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -173,6 +173,7 @@ struct ureg_program
unsigned char property_fs_coord_pixel_center; /* =
TGSI_FS_COORD_PIXEL_CENTER_* */
unsigned char property_fs_color0_writes_all_cbufs; /* =
TGSI_FS_COLOR0_WRITES_ALL_CBUFS * */
unsigned char property_fs_depth_layout; /* TGSI_FS_DEPTH_LAYOUT */
+ boolean property_vs_window_space_position; /*
TGSI_VS_WINDOW_SPACE_POSITION */
unsigned nr_addrs;
unsigned nr_preds;
@@ -331,6 +332,13 @@ ureg_property_fs_depth_layout(struct ureg_program
*ureg,
ureg-property_fs_depth_layout = fs_depth_layout;
}
+void
+ureg_property_vs_window_space_position(struct ureg_program *ureg,
+ boolean vs_window_space_position)
+{
+ ureg-property_vs_window_space_position = vs_window_space_position;
+}
+
struct ureg_src
ureg_DECL_fs_input_cyl_centroid(struct ureg_program *ureg,
unsigned semantic_name,
@@ -1508,6 +1516,14 @@ static void emit_decls( struct ureg_program *ureg )
ureg-property_fs_depth_layout);
}
+ if (ureg-property_vs_window_space_position) {
+ assert(ureg-processor == TGSI_PROCESSOR_VERTEX);
+
+ emit_property(ureg,
+TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION,
+ureg-property_vs_window_space_position);
+ }
+
if (ureg-processor == TGSI_PROCESSOR_VERTEX) {
for (i = 0; i UREG_MAX_INPUT; i++) {
if (ureg-vs_inputs[i/32] (1 (i%32))) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
index a0a50b7..28edea6 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h
@@ -184,6 +184,10 @@ void
ureg_property_fs_depth_layout(struct ureg_program *ureg,
unsigned fs_depth_layout);
+void
+ureg_property_vs_window_space_position(struct ureg_program *ureg,
+ boolean vs_window_space_position);
+
/***
* Build shader declarations:
diff --git a/src/gallium/docs/source/tgsi.rst
b/src/gallium/docs/source/tgsi.rst
index 9500b9d..2ca3c3b 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -2848,6 +2848,15 @@ input primitive. Each invocation will have a
different
TGSI_SEMANTIC_INVOCATIONID system value set. If not specified, assumed to
be 1.
+VS_WINDOW_SPACE_POSITION
+
+If this property is set on the vertex shader, the TGSI_SEMANTIC_POSITION
output
+is assumed to contain window space coordinates.
+Division of X,Y,Z by W and the viewport transformation are disabled, and
1/W is
+directly taken from the 4-th component of the shader output.
+Naturally, clipping is not performed on window coordinates either.
+The effect of this property is undefined if a geometry or tessellation
shader
+are in use.
Texture Sampling and Texture Formats
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index
[Mesa-dev] [PATCH 0/2] loader: allow alternative methods for PCI identification.
loader_get_pci_id_for_fd() and loader_get_device_name_for_fd() now attempt all available strategies to identify the hardware, instead of conditionally compiling in a single test. The existing libudev and DRM approaches have been retained, and another simple alternative of looking up the answer in the /sys filesystem (available on Linux) is added. v2: Break the patch into two independent commits. Disable the sysfs test by default (unless overridden at configure time). Gary Wong (2): loader: allow attempting more than one method of PCI identification. loader: add optional /sys filesystem method for PCI identification. configure.ac| 51 src/loader/loader.c | 173 +++- 2 files changed, 195 insertions(+), 29 deletions(-) -- 1.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] loader: allow attempting more than one method of PCI identification.
loader_get_pci_id_for_fd() and loader_get_device_name_for_fd() now attempt
all available strategies to identify the hardware, instead of conditionally
compiling in a single test. The existing libudev and DRM approaches have
been retained, attempting first libudev (if available) and then DRM (if
necessary).
Signed-off-by: Gary Wong g...@gnu.org
---
src/loader/loader.c | 64 ++---
1 file changed, 46 insertions(+), 18 deletions(-)
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 666d015..d8246e8 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -113,8 +113,8 @@ udev_dlopen_handle(void)
udev_handle = dlopen(libudev.so.0, RTLD_LOCAL | RTLD_LAZY);
if (!udev_handle) {
-log_(_LOADER_FATAL, Couldn't dlopen libudev.so.1 or libudev.so.0,
- driver detection may be broken.\n);
+log_(_LOADER_WARNING, Couldn't dlopen libudev.so.1 or
+ libudev.so.0, driver detection may be broken.\n);
}
}
}
@@ -122,16 +122,19 @@ udev_dlopen_handle(void)
return udev_handle;
}
+static int dlcheck_failed;
+
static void *
-asserted_dlsym(void *dlopen_handle, const char *name)
+checked_dlsym(void *dlopen_handle, const char *name)
{
void *result = dlsym(dlopen_handle, name);
- assert(result);
+ if (!result)
+ dlcheck_failed = 1;
return result;
}
#define UDEV_SYMBOL(ret, name, args) \
- ret (*name) args = asserted_dlsym(udev_dlopen_handle(), #name);
+ ret (*name) args = checked_dlsym(udev_dlopen_handle(), #name);
static inline struct udev_device *
@@ -142,6 +145,9 @@ udev_device_new_from_fd(struct udev *udev, int fd)
UDEV_SYMBOL(struct udev_device *, udev_device_new_from_devnum,
(struct udev *udev, char type, dev_t devnum));
+ if (dlcheck_failed)
+ return NULL;
+
if (fstat(fd, buf) 0) {
log_(_LOADER_WARNING, MESA-LOADER: failed to stat fd %d\n, fd);
return NULL;
@@ -157,8 +163,8 @@ udev_device_new_from_fd(struct udev *udev, int fd)
return device;
}
-int
-loader_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
+static int
+libudev_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
{
struct udev *udev = NULL;
struct udev_device *device = NULL, *parent;
@@ -174,6 +180,9 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int
*chip_id)
*chip_id = -1;
+ if (dlcheck_failed)
+ return 0;
+
udev = udev_new();
device = udev_device_new_from_fd(udev, fd);
if (!device)
@@ -201,16 +210,16 @@ out:
return (*chip_id = 0);
}
+#endif
-#elif !defined(__NOT_HAVE_DRM_H)
-
+#if !defined(__NOT_HAVE_DRM_H)
/* for i915 */
#include i915_drm.h
/* for radeon */
#include radeon_drm.h
-int
-loader_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
+static int
+drm_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
{
drmVersionPtr version;
@@ -272,23 +281,29 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int
*chip_id)
return (*chip_id = 0);
}
+#endif
-#else
int
loader_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
{
+#if HAVE_LIBUDEV
+ if (libudev_get_pci_id_for_fd(fd, vendor_id, chip_id))
+ return 1;
+#endif
+#if !defined(__NOT_HAVE_DRM_H)
+ if (drm_get_pci_id_for_fd(fd, vendor_id, chip_id))
+ return 1;
+#endif
return 0;
}
-#endif
-
-char *
-loader_get_device_name_for_fd(int fd)
+#ifdef HAVE_LIBUDEV
+static char *
+libudev_get_device_name_for_fd(int fd)
{
char *device_name = NULL;
-#ifdef HAVE_LIBUDEV
struct udev *udev;
struct udev_device *device;
const char *const_device_name;
@@ -312,9 +327,22 @@ loader_get_device_name_for_fd(int fd)
out:
udev_device_unref(device);
udev_unref(udev);
-#endif
return device_name;
}
+#endif
+
+
+char *
+loader_get_device_name_for_fd(int fd)
+{
+ char *result;
+
+#if HAVE_LIBUDEV
+ if ((result = libudev_get_device_name_for_fd(fd)))
+ return result;
+#endif
+ return NULL;
+}
char *
loader_get_driver_for_fd(int fd, unsigned driver_types)
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] loader: add optional /sys filesystem method for PCI identification.
Introduce a simple PCI identification method of looking up the answer
the /sys filesystem (available on Linux). Attempted after libudev, but
before DRM.
Disabled by default (available only when the --enable-sysfs configure
option is specified).
Signed-off-by: Gary Wong g...@gnu.org
---
configure.ac| 51 ++--
src/loader/loader.c | 113
2 files changed, 151 insertions(+), 13 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4e4d761..6b708dc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -818,13 +818,31 @@ fi
case $host_os in
linux*)
-need_libudev=yes ;;
+need_pci_id=yes ;;
*)
-need_libudev=no ;;
+need_pci_id=no ;;
esac
-PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED],
- have_libudev=yes, have_libudev=no)
+AC_ARG_ENABLE([libudev],
+[AS_HELP_STRING([--disable-libudev],
+[disable libudev PCI identification @:@default=enabled on supported
platforms@:@])],
+[attempt_libudev=$enableval],
+[attempt_libudev=yes]
+)
+
+if test x$attempt_libudev = xyes; then
+PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED],
+ have_libudev=yes, have_libudev=no)
+else
+have_libudev=no
+fi
+
+AC_ARG_ENABLE([sysfs],
+[AS_HELP_STRING([--enable-sysfs],
+[enable /sys PCI identification @:@default=disabled@:@])],
+[have_sysfs=$enableval],
+[have_sysfs=no]
+)
if test x$enable_dri = xyes; then
if test $enable_static = yes; then
@@ -910,8 +928,15 @@ xyesno)
;;
esac
+have_pci_id=no
if test $have_libudev = yes; then
DEFINES=$DEFINES -DHAVE_LIBUDEV
+have_pci_id=yes
+fi
+
+if test $have_sysfs = yes; then
+DEFINES=$DEFINES -DHAVE_SYSFS
+have_pci_id=yes
fi
# This is outside the case (above) so that it is invoked even for non-GLX
@@ -1013,8 +1038,8 @@ if test x$enable_dri = xyes; then
DEFINES=$DEFINES -DHAVE_DRI3
fi
-if test x$have_libudev != xyes; then
-AC_MSG_ERROR([libudev-dev required for building DRI])
+if test x$have_pci_id != xyes; then
+AC_MSG_ERROR([libudev-dev or sysfs required for building DRI])
fi
case $host_cpu in
@@ -1183,8 +1208,8 @@ if test x$enable_gbm = xauto; then
esac
fi
if test x$enable_gbm = xyes; then
-if test x$need_libudev$have_libudev = xyesno; then
-AC_MSG_ERROR([gbm requires udev = $LIBUDEV_REQUIRED])
+if test x$need_pci_id$have_pci_id = xyesno; then
+AC_MSG_ERROR([gbm requires udev = $LIBUDEV_REQUIRED or sysfs])
fi
if test x$enable_dri = xyes; then
@@ -1202,7 +1227,7 @@ if test x$enable_gbm = xyes; then
fi
fi
AM_CONDITIONAL(HAVE_GBM, test x$enable_gbm = xyes)
-if test x$need_libudev = xyes; then
+if test x$need_pci_id$have_libudev = xyesyes; then
GBM_PC_REQ_PRIV=libudev = $LIBUDEV_REQUIRED
else
GBM_PC_REQ_PRIV=
@@ -1491,9 +1516,9 @@ for plat in $egl_platforms; do
;;
esac
-case $plat$need_libudev$have_libudev in
+case $plat$need_pci_id$have_pci_id in
waylandyesno|drmyesno)
-AC_MSG_ERROR([cannot build $plat platform without udev =
$LIBUDEV_REQUIRED]) ;;
+AC_MSG_ERROR([cannot build $plat platform without udev =
$LIBUDEV_REQUIRED or sysfs]) ;;
esac
done
@@ -1766,8 +1791,8 @@ gallium_require_llvm() {
gallium_require_drm_loader() {
if test x$enable_gallium_loader = xyes; then
-if test x$need_libudev$have_libudev = xyesno; then
-AC_MSG_ERROR([Gallium drm loader requires libudev =
$LIBUDEV_REQUIRED])
+if test x$need_pci_id$have_pci_id = xyesno; then
+AC_MSG_ERROR([Gallium drm loader requires libudev =
$LIBUDEV_REQUIRED or sysfs])
fi
if test x$have_libdrm != xyes; then
AC_MSG_ERROR([Gallium drm loader requires libdrm =
$LIBDRM_REQUIRED])
diff --git a/src/loader/loader.c b/src/loader/loader.c
index d8246e8..33e77b3 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -71,6 +71,10 @@
#include assert.h
#include dlfcn.h
#endif
+#ifdef HAVE_SYSFS
+#include sys/stat.h
+#include sys/types.h
+#endif
#include loader.h
#ifndef __NOT_HAVE_DRM_H
@@ -212,6 +216,66 @@ out:
}
#endif
+#if defined(HAVE_SYSFS)
+static int
+dev_node_from_fd(int fd, unsigned int *maj, unsigned int *min)
+{
+ struct stat buf;
+
+ if (fstat(fd, buf) 0) {
+ log_(_LOADER_WARNING, MESA-LOADER: failed to stat fd %d\n, fd);
+ return -1;
+ }
+
+ if (!S_ISCHR(buf.st_mode)) {
+ log_(_LOADER_WARNING, MESA-LOADER: fd %d not a character device\n, fd);
+ return -1;
+ }
+
+ *maj = major(buf.st_rdev);
+ *min = minor(buf.st_rdev);
+
+ return 0;
+}
+
+static int
+sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
+{
+ unsigned int maj, min;
+ FILE *f;
+ char buf[ 0x40 ];
+
+ if
[Mesa-dev] [Bug 78771] egl not works on 10.0.x and 10.1.x with black screen
https://bugs.freedesktop.org/show_bug.cgi?id=78771 --- Comment #11 from qwang13 quanxian.w...@intel.com --- Thanks U. Artie Eoff's checking. Currently we found the root cause is miss installing latest libgbm package. -- 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 05/12] gallivm: Use LLVM global context.
Hi, On Monday, May 19, 2014 15:59:30 Michel Dänzer wrote: On 19.05.2014 15:03, Mathias Fröhlich wrote: I tried to get my local llvm install again to a point where I can see backtrace information, but still failed to get valgrind/massif to print these nice backtraces. All of the llvm addresses are not resolved so far. You may want to try some or all of these parameters for LLVM's configure: '--enable-optimized' '--with-optimize-option=-fno-omit-frame-pointer -O2 [...]' '--enable-assertions' '--enable-debug-runtime' '--enable-debug-symbols' 'CC=gcc' 'CXX=g++' Thanks, I was searching for a while, but disabling the linker script unexporting all unnecessary symbols does the trick for massif. For my test install I use a static llvm to rule out errors by finding the wrong shared llvm so's. So hiding these symbols also hides them from valgrind/massif. Greetings Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
