Re: [Mesa-dev] [PATCH] egl/gallium: implemlent EGL_KHR_create_context v3
On 07/24/2014 07:16 PM, Matt Turner wrote:
On Fri, Jun 27, 2014 at 1:59 AM, Knut Andre Tidemann
wrote:
v2: fix style and wrong major version comparison.
v3: fix version check in context creation.
---
src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
src/gallium/state_trackers/egl/common/egl_g3d_api.c | 12
2 files changed, 13 insertions(+)
diff --git a/src/gallium/state_trackers/egl/common/egl_g3d.c
b/src/gallium/state_trackers/egl/common/egl_g3d.c
index d3f5e92..22b5e4a 100644
--- a/src/gallium/state_trackers/egl/common/egl_g3d.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d.c
@@ -584,6 +584,7 @@ egl_g3d_initialize(_EGLDriver *drv, _EGLDisplay *dpy)
dpy->Extensions.KHR_fence_sync = EGL_TRUE;
dpy->Extensions.KHR_surfaceless_context = EGL_TRUE;
+ dpy->Extensions.KHR_create_context = EGL_TRUE;
if (dpy->Platform == _EGL_PLATFORM_DRM) {
dpy->Extensions.MESA_drm_display = EGL_TRUE;
diff --git a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
index b19d899..5e900cc 100644
--- a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
@@ -72,6 +72,11 @@ egl_g3d_choose_st(_EGLDriver *drv, _EGLContext *ctx,
break;
case EGL_OPENGL_API:
api = ST_API_OPENGL;
+ if (((ctx->ClientMajorVersion >= 4) ||
+(ctx->ClientMajorVersion == 3 && ctx->ClientMinorVersion >= 2)) &&
+ctx->Profile == EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR) {
+ *profile = ST_PROFILE_OPENGL_CORE;
+ }
What if you only specify the core profile bit without specifying a version?
I don't know that you're required to specify a version to get a core
profile. The default major/minor versions are 1/0 and the default
profile mask is core, so it seems like that should give you a core
context by default. Maybe we're missing a test for this.
The core and compatibility profiles were only introduced in 3.2, and the
spec says the PROFILE_MASK is ignored for earlier versions.
break;
default:
_eglLog(_EGL_WARNING, "unknown client API 0x%04x", ctx->ClientAPI);
@@ -166,6 +171,12 @@ egl_g3d_create_context(_EGLDriver *drv, _EGLDisplay *dpy,
_EGLConfig *conf,
if (gconf)
stattribs.visual = gconf->stvis;
+ if (gctx->base.Flags & EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR)
+ stattribs.flags = ST_CONTEXT_FLAG_DEBUG;
Need to handle EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR and
EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR here too?
The FORWARD_COMPATIBLE_BIT is handled by the main egl stack
(_eglInitContext in egl/main/eglcontext.c) which is called by the called
by the galluim code.
Handing of the ROBUST_ACCESS_BIT requires another extension
(EXT_create_context_robustness) which I don't think is implemented, at
least not in the gallium code. The bit is not set if this extension is
not available. This is also handled in the main egl stack.
--
Knut Tidemann
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: fix switch statement default case regressions
This patch fixes regressions caused by commit 48deb4d. Regressions
happened because 'run_default' var did not initialized when default
case was the last one.
Now all the switch tests in es3conform suite are passing.
Signed-off-by: Tapani Pälli
---
src/glsl/ast_to_hir.cpp | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index a15ee9c..7249a06 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4597,12 +4597,6 @@ ast_case_statement_list::hir(exec_list *instructions,
*/
if (!default_case.is_empty()) {
- /* Default case was the last one, no checks required. */
- if (after_default.is_empty()) {
- instructions->append_list(&default_case);
- return NULL;
- }
-
ir_rvalue *const true_val = new (state) ir_constant(true);
ir_dereference_variable *deref_run_default_var =
new(state) ir_dereference_variable(state->switch_state.run_default);
@@ -4614,6 +4608,12 @@ ast_case_statement_list::hir(exec_list *instructions,
new(state) ir_assignment(deref_run_default_var, true_val);
instructions->push_tail(init_var);
+ /* Default case was the last one, no checks required. */
+ if (after_default.is_empty()) {
+ instructions->append_list(&default_case);
+ return NULL;
+ }
+
foreach_in_list(ir_instruction, ir, &after_default) {
ir_assignment *assign = ir->as_assignment();
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Env var for forcing sw driver (Re: [PATCH 3/6] Add support for swrast to the DRM EGL platform)
On Fri, 25 Jul 2014 09:14:40 +0300 Pekka Paalanen wrote: > On Thu, 24 Jul 2014 17:16:39 +0100 > Emil Velikov wrote: > > > On 24/07/14 14:30, Pekka Paalanen wrote: > > > On Thu, 24 Jul 2014 13:34:42 +0100 > > > Emil Velikov wrote: > > > > > >> On 24/07/14 07:23, Pekka Paalanen wrote: > > >>> On Thu, 24 Jul 2014 01:43:35 +0100 > > >>> Emil Velikov wrote: > > >>> > > From: Giovanni Campagna > > > > Turn GBM into a swrast loader (providing putimage/getimage backed > > by a dumb KMS buffer). This allows to run KMS+DRM GL applications > > (such as weston or mutter-wayland) unmodified on cards that don't > > have any client side HW acceleration component but that can do > > modeset (examples include simpledrm and qxl) > > > > [Emil Velikov] > > - Fix make check. > > - Split dri_open_driver() from dri_load_driver(). > > - Don't try to bind the swrast extensions when using dri. > > - Handle swrast->CreateNewScreen() failure. > > - strdup the driver_name, as it's free'd at destruction. > > - s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE/ > > - Move gbm_dri_bo_map/unmap to gbm_driiint.h. > > - Correct swrast fallback logic. > > > > Signed-off-by: Emil Velikov > > --- > > src/egl/drivers/dri2/platform_drm.c | 153 +++ > > src/gbm/backends/dri/gbm_dri.c | 203 > > +++- > > src/gbm/backends/dri/gbm_driint.h | 57 +- > > src/gbm/gbm-symbols-check | 1 + > > src/gbm/main/gbm.h | 3 + > > 5 files changed, 369 insertions(+), 48 deletions(-) > > ... > > > >>> is GBM_ALWAYS_SOFTWARE a new env var? > > >>> Is it documented somewhere? > > >> None of the GBM env variables are. In a matter of fact there isn't even a > > >> single reference of gbm in the docs - env vars or otherwise. It's like > > >> gbm > > >> does not exist :'( > > >> > > >> Will need to get a new document out there similar to egl.html. > > >> Any objections if we do that as a follow up patch ? > > > > > > I would be happy to see any documentation at some point. :-) > > > > > >>> How does it interact with EGL_SOFTWARE? > > >>> Does GBM_ALWAYS_SOFTWARE affect GBM's ability to import dmabufs > > >>> somehow, or only the surfaces that will be passed to EGL? > > >>> (Importing dmabufs to be passed directly to KMS for scanout.) > > >>> > > >> Considering it's a variable that needs to be explicitly set, the > > >> behaviour > > >> depends on the current state of the software backend. > > >> > > >> AFAICS current swrast/kms_swrast does not allow/use dmabufs. > > > > > > Maybe that was a stupid question on my part, as I don't know > > > whether generic DRM API even has a way to import dmabufs at all. > > > Something like dumb buffer import... > > > > > AFAICS one needs to use a device driver capable of handling dmabufs, > > otherwise > > the core drm will return EINVAL/ENOSYS. > > > > I don't see any "software" implementation (dumb buffer) that can be used > > here. > > > > IMHO all the above should be mentioned somewhere/documented rather than > > expecting everything to magically work exactly as you expected it to. > > > > >>> I'm terribly confused with all the *SOFTWARE* variables, and it seems > > >>> I'm not alone as someone just recently filed a bunch of Weston bug > > >>> reports while trying to get software GL rendering with > > >>> LIBGL_ALWAYS_SOFTWARE on DRM/KMS. > > >>> > > >>> > > >> I have the sneaking suspicion that most people see LIBGL_ALWAYS_SOFTWARE > > >> as > > >> the magic variable that reads your mind and makes things work as you > > >> would > > >> imagine them. Would be great to move from that to read the documentation > > >> and > > >> amend propose improvements of it when needed. > > > > > > Right. What about EGL_SOFTWARE? Why not use that on GBM platform too? A > > > quick grep implies that X11 and Wayland platforms use it (but only with > > > egl_gallium.so?)? > > > > > A bit of history - when Chia-I was doing all the EGL work, he was > > considerable > > enough to make individual switches for people to toggle when needed. He also > > documented all of these :) > > > > > GBM_ALWAYS_SOFTWARE sounds like a platform-specific variable, but > > > should forcing software rendering be platform-specific? > > > > > GBM is not EGL I fear. Also EGL is not the only user of GBM. > > Sure, but GBM does no rendering at all, does it? It's strange, GBM needs > to load a driver but does not render, so forcing "software rendering" > sounds funny. But obviously you want to be able to tell GBM to load a > software "driver" instead of a hardware one. Certainly does not make > this any easier to understand. > > Well, the same can be said about EGL... > > So, this thing is about GBM the driver loader, not GBM the EGL > platform. Maybe that is where I got confused. (The subject does speak > e
Re: [Mesa-dev] [PATCH 3/6] Add support for swrast to the DRM EGL platform
On Thu, 24 Jul 2014 17:16:39 +0100 Emil Velikov wrote: > On 24/07/14 14:30, Pekka Paalanen wrote: > > On Thu, 24 Jul 2014 13:34:42 +0100 > > Emil Velikov wrote: > > > >> On 24/07/14 07:23, Pekka Paalanen wrote: > >>> On Thu, 24 Jul 2014 01:43:35 +0100 > >>> Emil Velikov wrote: > >>> > From: Giovanni Campagna > > Turn GBM into a swrast loader (providing putimage/getimage backed > by a dumb KMS buffer). This allows to run KMS+DRM GL applications > (such as weston or mutter-wayland) unmodified on cards that don't > have any client side HW acceleration component but that can do > modeset (examples include simpledrm and qxl) > > [Emil Velikov] > - Fix make check. > - Split dri_open_driver() from dri_load_driver(). > - Don't try to bind the swrast extensions when using dri. > - Handle swrast->CreateNewScreen() failure. > - strdup the driver_name, as it's free'd at destruction. > - s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE/ > - Move gbm_dri_bo_map/unmap to gbm_driiint.h. > - Correct swrast fallback logic. > > Signed-off-by: Emil Velikov > --- > src/egl/drivers/dri2/platform_drm.c | 153 +++ > src/gbm/backends/dri/gbm_dri.c | 203 > +++- > src/gbm/backends/dri/gbm_driint.h | 57 +- > src/gbm/gbm-symbols-check | 1 + > src/gbm/main/gbm.h | 3 + > 5 files changed, 369 insertions(+), 48 deletions(-) ... > >>> is GBM_ALWAYS_SOFTWARE a new env var? > >>> Is it documented somewhere? > >> None of the GBM env variables are. In a matter of fact there isn't even a > >> single reference of gbm in the docs - env vars or otherwise. It's like gbm > >> does not exist :'( > >> > >> Will need to get a new document out there similar to egl.html. > >> Any objections if we do that as a follow up patch ? > > > > I would be happy to see any documentation at some point. :-) > > > >>> How does it interact with EGL_SOFTWARE? > >>> Does GBM_ALWAYS_SOFTWARE affect GBM's ability to import dmabufs > >>> somehow, or only the surfaces that will be passed to EGL? > >>> (Importing dmabufs to be passed directly to KMS for scanout.) > >>> > >> Considering it's a variable that needs to be explicitly set, the behaviour > >> depends on the current state of the software backend. > >> > >> AFAICS current swrast/kms_swrast does not allow/use dmabufs. > > > > Maybe that was a stupid question on my part, as I don't know > > whether generic DRM API even has a way to import dmabufs at all. > > Something like dumb buffer import... > > > AFAICS one needs to use a device driver capable of handling dmabufs, otherwise > the core drm will return EINVAL/ENOSYS. > > I don't see any "software" implementation (dumb buffer) that can be used here. > > IMHO all the above should be mentioned somewhere/documented rather than > expecting everything to magically work exactly as you expected it to. > > >>> I'm terribly confused with all the *SOFTWARE* variables, and it seems > >>> I'm not alone as someone just recently filed a bunch of Weston bug > >>> reports while trying to get software GL rendering with > >>> LIBGL_ALWAYS_SOFTWARE on DRM/KMS. > >>> > >>> > >> I have the sneaking suspicion that most people see LIBGL_ALWAYS_SOFTWARE as > >> the magic variable that reads your mind and makes things work as you would > >> imagine them. Would be great to move from that to read the documentation > >> and > >> amend propose improvements of it when needed. > > > > Right. What about EGL_SOFTWARE? Why not use that on GBM platform too? A > > quick grep implies that X11 and Wayland platforms use it (but only with > > egl_gallium.so?)? > > > A bit of history - when Chia-I was doing all the EGL work, he was considerable > enough to make individual switches for people to toggle when needed. He also > documented all of these :) > > > GBM_ALWAYS_SOFTWARE sounds like a platform-specific variable, but > > should forcing software rendering be platform-specific? > > > GBM is not EGL I fear. Also EGL is not the only user of GBM. Sure, but GBM does no rendering at all, does it? It's strange, GBM needs to load a driver but does not render, so forcing "software rendering" sounds funny. But obviously you want to be able to tell GBM to load a software "driver" instead of a hardware one. Certainly does not make this any easier to understand. Well, the same can be said about EGL... So, this thing is about GBM the driver loader, not GBM the EGL platform. Maybe that is where I got confused. (The subject does speak explicitly about EGL platform.) > If we were to have zero users of libgbm outside of mesa(libegl) and then we > can happily go with EGL_SOFTWARE and be gone with it. Perhaps the most > reasonable compromise is to use the GBM env var and fallback to the EGL one. > How does that sound ? You raise a good point there. GBM is in
[Mesa-dev] [Bug 80615] Files in bellagio directory [omx tracker] don't respect installation folder
https://bugs.freedesktop.org/show_bug.cgi?id=80615
--- Comment #6 from Alexandre Demers ---
Christian, could you give us your input on this issue and proposed fix?
(In reply to comment #5)
> AFAICS the whole thing is quite inconsistent.
>
> (In reply to comment #3)
> > That's something I hadn't noticed. However, it still bugs me. Why would this
> > component deal with its installation path differently from the others. Let's
> > have a look at opencl, vdpau and egl :
> > --with-vdpau-libdir=DIR directory for the VDPAU libraries
> > [default=${libdir}/vdpau]
> Defined by libvdpau. Can be accessed/queried via pkg-config (moduledir)
>
> > --with-opencl-libdir=DIR
> > directory for auxiliary libraries used by the
> > OpenCL
> > implementation [default=${libdir}/opencl]
> Unused.
>
> > --with-egl-driver-dir=DIR
> > directory for EGL drivers
> > [[default=${libdir}/egl]]
> >
> Internal to mesa. Ideally we'll have this one nuked for the next release.
>
> > And then we have omx :
> > --with-omx-libdir=DIR directory for the OMX libraries
> >
> Defined by bellagio. Can be accessed/queried via pkg-config (pluginsdir)
>
> > It seems omx is one of a kind by not using something ${libdir}/bellagio. By
> > doing this small modification, a user wouldn't be surprise to have this only
> > component install not in the libdir he asked for, but he would still be able
> > to set a different path if needed.
> >
> It can be argued either way, yet imho we should be using pkg-config when
> possible. I don't mind either way, as long as Christian is happy with the
> solution.
--
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 v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On Friday, July 25, 2014 04:02:48 AM Emil Velikov wrote: > On 25/07/14 03:14, Matt Turner wrote: > > On Thu, Jul 24, 2014 at 5:17 PM, Emil Velikov > > wrote: > >> On 24/07/14 22:08, Dylan Baker wrote: > >>> On Thursday, July 24, 2014 09:32:38 PM Emil Velikov wrote: > On 22/07/14 19:43, Dylan Baker wrote: > > GBM_DRIVERS_PATH is not documented, and only used to set the location of > > gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and > > is documented. > > > > Generally this split leads to confusion as to why gbm doesn't work. > > > > This patch makes LIBGL_DRIVERS_PATH the main variable, but uses > > GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL. > > Dylan if we're going the LIBGL road, can we please use the GBM variable > first and then fallback to the LIBGL one ? This way things won't break > for > people using the former. Meanwhile I'm writing docs/gbm.html with some > rough description what gbm is and all the env vars used :-) > > >>> > >>> Is there a usecase for having a seperate GBM_DRIVERS_PATH? > >> Guess we'll know that when people come complaining that it broke their > >> setup. > >> It will be piglit's "OMG this broke my setup - revert revert. But this has > >> been on the ML for xx days", story all over again. > > > > Isn't this a vacuous problem? The drivers GBM opens are the same > > drivers specified by LIBGL_DRIVERS_PATH, and there's never been any > > difference or way to install "GBM drivers" elsewhere. I.e., no one > > ever has specified something different for GBM_DRIVERS_PATH and > > LIBGL_DRIVERS_PATH intentionally. > > > Still don't see what the problem is: you wanted LIBGL to control do world - > sure, go ahead. All I asked for is to not rub the middle finger in someone's > face just because they never came to personally tell you that's the way they > do things. Essentially I'm trying to find a compromise that works for everyone > yet you come with the "no one" and "ever" statements, which are a bit silly > IMHO, especially in the context of an open-source project. > > I'm quite "enjoying" this bike-shedding. People just refuse that others may > have with different work flow than theirs. Well... I'm off this topic enjoy > your "world domination" plan :P > > -Emil Emil, You seem really upset for some reason, and I don't understand why. Nobody has evil plans for "world domination" here. Dylan, Eric, Kristian, Jordan, Ben, and I have all concretely wasted time on a number of occasions due to GBM not respecting the standard, documented LIBGL_DRIVERS_PATH variable. When Dylan proposed his patch, we expressed our opinion that it would save us time debugging unnecessary problems. So far, I haven't heard that his patch would make things concretely worse for you personally. What I've heard is that you dislike the change in behavior, because /someone/ (other than you) may have /some/ use case which benefits from GBM having an additional separate driver search path. The other people in the discussion have asked for a single Mesa developer to say "This benefits me in a concrete way." Which to me, seems like a very reasonable request. But so far, no one has stepped forward to say that. Piglit is a little different. Although there are a wide variety of use cases, people are always able to quickly explain their workflow and why something is concretely useful to them. But, all the people affected aren't present in the discussion, because we're all too busy to read the Piglit list consistently. In contrast, people actually read mesa-dev - especially single patch threads with obvious subject lines. There are very few users of GBM, and I think virtually all of them are here. I think it's reasonable to assume people are paying attention, and the only reason we haven't heard objections from others is that they simply don't care. For what it's worth, I'm fine with your suggestion of reading GBM_DRIVERS_PATH first, then LIBGL_DRIVERS_PATH. It's the sensible way to do things - it adds the new useful behavior the 6 of us want, while preserving the existing behavior more closely. But it also doesn't affect me. I also agree with you that LIBGL_DRIVERS_PATH is not the best variable name. It made sense when the only loader (outside the X server) was in libGL. But, now we also have libEGL and libgbm. If we were adding it today, I would suggest DRI_DRIVERS_PATH. But it's been LIBGL_* for years, and is documented, and well known...so I don't think it's worth changing. Which does bring up another data point: there isn't a separate LIBEGL_DRIVERS_PATH variable for specifying the DRI driver path - it just uses LIBGL_DRIVERS_PATH like libGL/GLX. Nobody has asked for one either... --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] valgrind shows read after frees in GLSL compiler
On 07/25/2014 06:51 AM, Dave Airlie wrote: > Hi guys, > > Just fell over these in passing, run piglit > glsl-1.50-transform-feedback-type-and-size test > > Dave. > > 8< > ==8650== Invalid read of size 4 > ==8650==at 0x65F7FD6: brw::vec4_visitor::opt_cse_local(bblock_t*) > (brw_vec4_cse.cpp:227) > ==8650==by 0x65F8125: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:257) > ==8650==by 0x65F5DA4: brw::vec4_visitor::run() (brw_vec4.cpp:1708) > ==8650==by 0x65F6120: brw_vs_emit (brw_vec4.cpp:1784) > ==8650==by 0x6618ACF: do_vs_prog (brw_vs.c:293) > ==8650==by 0x661976D: brw_vs_precompile (brw_vs.c:542) > ==8650==by 0x65E9672: brw_shader_precompile(gl_context*, > gl_shader_program*) (brw_shader.cpp:79) > ==8650==by 0x65E9E94: brw_link_shader (brw_shader.cpp:275) > ==8650==by 0x63FDA68: _mesa_glsl_link_shader (ir_to_mesa.cpp:3079) > ==8650==by 0x629F6AC: link_program (shaderapi.c:915) > ==8650==by 0x62A07FB: _mesa_LinkProgram (shaderapi.c:1383) > ==8650==by 0x5AF91F1: shared_dispatch_stub_509 (glapi_mapi_tmp.h:17853) > ==8650== Address 0x78afb0c is 12 bytes after a block of size 96 alloc'd > ==8650==at 0x4A081D4: calloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==8650==by 0x64F8F9B: ralloc_size (ralloc.c:113) > ==8650==by 0x65BEA83: cfg_t::operator new(unsigned long, void*) > (in /home/airlied/devel/mesa/mesa/lib/i965_dri.so) > ==8650==by 0x65EAAB8: backend_visitor::calculate_cfg() > (brw_shader.cpp:774) > ==8650==by 0x66000BF: > brw::vec4_visitor::calculate_live_intervals() > (brw_vec4_live_variables.cpp:251) > ==8650==by 0x65F80E9: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:252) > ==8650==by 0x65F5DA4: brw::vec4_visitor::run() (brw_vec4.cpp:1708) > ==8650==by 0x65F6120: brw_vs_emit (brw_vec4.cpp:1784) > ==8650==by 0x6618ACF: do_vs_prog (brw_vs.c:293) > ==8650==by 0x661976D: brw_vs_precompile (brw_vs.c:542) > ==8650==by 0x65E9672: brw_shader_precompile(gl_context*, > gl_shader_program*) (brw_shader.cpp:79) > ==8650==by 0x65E9E94: brw_link_shader (brw_shader.cpp:275) > ==8650== > ==8650== Invalid read of size 4 > ==8650==at 0x65F8028: brw::vec4_visitor::opt_cse_local(bblock_t*) > (brw_vec4_cse.cpp:227) > ==8650==by 0x65F8125: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:257) > ==8650==by 0x65F5DA4: brw::vec4_visitor::run() (brw_vec4.cpp:1708) > ==8650==by 0x65F6120: brw_vs_emit (brw_vec4.cpp:1784) > ==8650==by 0x6618ACF: do_vs_prog (brw_vs.c:293) > ==8650==by 0x661976D: brw_vs_precompile (brw_vs.c:542) > ==8650==by 0x65E9672: brw_shader_precompile(gl_context*, > gl_shader_program*) (brw_shader.cpp:79) > ==8650==by 0x65E9E94: brw_link_shader (brw_shader.cpp:275) > ==8650==by 0x63FDA68: _mesa_glsl_link_shader (ir_to_mesa.cpp:3079) > ==8650==by 0x629F6AC: link_program (shaderapi.c:915) > ==8650==by 0x62A07FB: _mesa_LinkProgram (shaderapi.c:1383) > ==8650==by 0x5AF91F1: shared_dispatch_stub_509 (glapi_mapi_tmp.h:17853) > ==8650== Address 0x78afb0c is 12 bytes after a block of size 96 alloc'd > ==8650==at 0x4A081D4: calloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==8650==by 0x64F8F9B: ralloc_size (ralloc.c:113) > ==8650==by 0x65BEA83: cfg_t::operator new(unsigned long, void*) > (in /home/airlied/devel/mesa/mesa/lib/i965_dri.so) > ==8650==by 0x65EAAB8: backend_visitor::calculate_cfg() > (brw_shader.cpp:774) > ==8650==by 0x66000BF: > brw::vec4_visitor::calculate_live_intervals() > (brw_vec4_live_variables.cpp:251) > ==8650==by 0x65F80E9: brw::vec4_visitor::opt_cse() (brw_vec4_cse.cpp:252) > ==8650==by 0x65F5DA4: brw::vec4_visitor::run() (brw_vec4.cpp:1708) > ==8650==by 0x65F6120: brw_vs_emit (brw_vec4.cpp:1784) > ==8650==by 0x6618ACF: do_vs_prog (brw_vs.c:293) > ==8650==by 0x661976D: brw_vs_precompile (brw_vs.c:542) > ==8650==by 0x65E9672: brw_shader_precompile(gl_context*, > gl_shader_program*) (brw_shader.cpp:79) > ==8650==by 0x65E9E94: brw_link_shader (brw_shader.cpp:275) These last lines here look familiar or at least hit the same area of code as: https://bugs.freedesktop.org/show_bug.cgi?id=81379 (this bug got fixed though) > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] valgrind shows read after frees in GLSL compiler
Hi guys, Just fell over these in passing, run piglit glsl-1.50-transform-feedback-type-and-size test Dave. ==8650== Invalid read of size 8 ==8650==at 0x6440C9D: ast_interface_block::hir(exec_list*, _mesa_glsl_parse_state*) (ast_to_hir.cpp:5647) ==8650==by 0x64334CA: _mesa_ast_to_hir(exec_list*, _mesa_glsl_parse_state*) (ast_to_hir.cpp:100) ==8650==by 0x64A7D15: _mesa_glsl_compile_shader (glsl_parser_extras.cpp:1461) ==8650==by 0x629F35C: compile_shader (shaderapi.c:850) ==8650==by 0x629FD5F: _mesa_CompileShader (shaderapi.c:1138) ==8650==by 0x5AF8BAC: shared_dispatch_stub_482 (glapi_mapi_tmp.h:17664) ==8650==by 0x4C8A5AB: stub_glCompileShader (piglit-dispatch-gen.c:6375) ==8650==by 0x4CF9DC7: piglit_compile_shader_text (piglit-shader.c:132) ==8650==by 0x4CFA3E5: piglit_build_simple_program_unlinked_multiple_shaders_v (piglit-shader.c:363) ==8650==by 0x4CFA55F: piglit_build_simple_program_unlinked_multiple_shaders (piglit-shader.c:398) ==8650==by 0x4014D9: piglit_init (transform-feedback-type-and-size.c:165) ==8650==by 0x4D141B3: run_test (piglit_winsys_framework.c:70) ==8650== Address 0x70982a8 is 88 bytes inside a block of size 200 free'd ==8650==at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==8650==by 0x64F940F: unsafe_free (ralloc.c:255) ==8650==by 0x64F92F9: ralloc_free (ralloc.c:218) ==8650==by 0x6432E2A: exec_node::operator delete(void*) (list.h:79) ==8650==by 0x64B4195: ir_variable::~ir_variable() (ir.h:410) ==8650==by 0x643A4B7: get_variable_being_redeclared(ir_variable*, YYLTYPE, _mesa_glsl_parse_state*, bool) (ast_to_hir.cpp:2868) ==8650==by 0x6440C8E: ast_interface_block::hir(exec_list*, _mesa_glsl_parse_state*) (ast_to_hir.cpp:5646) ==8650==by 0x64334CA: _mesa_ast_to_hir(exec_list*, _mesa_glsl_parse_state*) (ast_to_hir.cpp:100) ==8650==by 0x64A7D15: _mesa_glsl_compile_shader (glsl_parser_extras.cpp:1461) ==8650==by 0x629F35C: compile_shader (shaderapi.c:850) ==8650==by 0x629FD5F: _mesa_CompileShader (shaderapi.c:1138) ==8650==by 0x5AF8BAC: shared_dispatch_stub_482 (glapi_mapi_tmp.h:17664) ==8650== ==8650== Invalid read of size 1 ==8650==at 0x64333E6: is_gl_identifier(char const*) (ir.h:2351) ==8650==by 0x6440CA8: ast_interface_block::hir(exec_list*, _mesa_glsl_parse_state*) (ast_to_hir.cpp:5647) ==8650==by 0x64334CA: _mesa_ast_to_hir(exec_list*, _mesa_glsl_parse_state*) (ast_to_hir.cpp:100) ==8650==by 0x64A7D15: _mesa_glsl_compile_shader (glsl_parser_extras.cpp:1461) ==8650==by 0x629F35C: compile_shader (shaderapi.c:850) ==8650==by 0x629FD5F: _mesa_CompileShader (shaderapi.c:1138) ==8650==by 0x5AF8BAC: shared_dispatch_stub_482 (glapi_mapi_tmp.h:17664) ==8650==by 0x4C8A5AB: stub_glCompileShader (piglit-dispatch-gen.c:6375) ==8650==by 0x4CF9DC7: piglit_compile_shader_text (piglit-shader.c:132) ==8650==by 0x4CFA3E5: piglit_build_simple_program_unlinked_multiple_shaders_v (piglit-shader.c:363) ==8650==by 0x4CFA55F: piglit_build_simple_program_unlinked_multiple_shaders (piglit-shader.c:398) ==8650==by 0x4014D9: piglit_init (transform-feedback-type-and-size.c:165) ==8650== Address 0x7098390 is 48 bytes inside a block of size 64 free'd ==8650==at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==8650==by 0x64F940F: unsafe_free (ralloc.c:255) ==8650==by 0x64F93D4: unsafe_free (ralloc.c:248) ==8650==by 0x64F92F9: ralloc_free (ralloc.c:218) ==8650==by 0x6432E2A: exec_node::operator delete(void*) (list.h:79) ==8650==by 0x64B4195: ir_variable::~ir_variable() (ir.h:410) ==8650==by 0x643A4B7: get_variable_being_redeclared(ir_variable*, YYLTYPE, _mesa_glsl_parse_state*, bool) (ast_to_hir.cpp:2868) ==8650==by 0x6440C8E: ast_interface_block::hir(exec_list*, _mesa_glsl_parse_state*) (ast_to_hir.cpp:5646) ==8650==by 0x64334CA: _mesa_ast_to_hir(exec_list*, _mesa_glsl_parse_state*) (ast_to_hir.cpp:100) ==8650==by 0x64A7D15: _mesa_glsl_compile_shader (glsl_parser_extras.cpp:1461) ==8650==by 0x629F35C: compile_shader (shaderapi.c:850) ==8650==by 0x629FD5F: _mesa_CompileShader (shaderapi.c:1138) ==8650== ==8650== Invalid read of size 1 ==8650==at 0x64333F5: is_gl_identifier(char const*) (ir.h:2351) ==8650==by 0x6440CA8: ast_interface_block::hir(exec_list*, _mesa_glsl_parse_state*) (ast_to_hir.cpp:5647) ==8650==by 0x64334CA: _mesa_ast_to_hir(exec_list*, _mesa_glsl_parse_state*) (ast_to_hir.cpp:100) ==8650==by 0x64A7D15: _mesa_glsl_compile_shader (glsl_parser_extras.cpp:1461) ==8650==by 0x629F35C: compile_shader (shaderapi.c:850) ==8650==by 0x629FD5F: _mesa_CompileShader (shaderapi.c:1138) ==8650==by 0x5AF8BAC: shared_dispatch_stub_482 (glapi_mapi_tmp.h:17664) ==8650==by 0x4C8A5AB: stub_glCompileShader (piglit-dispatch-gen.c:6375) ==8650==by 0x4CF9DC7: piglit_compile_shader_text (piglit-shader.c:132) ==8650==by 0x4CFA3E5: piglit_
Re: [Mesa-dev] [PATCH v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On Thu, Jul 24, 2014 at 8:02 PM, Emil Velikov wrote: > On 25/07/14 03:14, Matt Turner wrote: >> On Thu, Jul 24, 2014 at 5:17 PM, Emil Velikov >> wrote: >>> On 24/07/14 22:08, Dylan Baker wrote: On Thursday, July 24, 2014 09:32:38 PM Emil Velikov wrote: > On 22/07/14 19:43, Dylan Baker wrote: >> GBM_DRIVERS_PATH is not documented, and only used to set the location of >> gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and >> is documented. >> >> Generally this split leads to confusion as to why gbm doesn't work. >> >> This patch makes LIBGL_DRIVERS_PATH the main variable, but uses >> GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL. > > Dylan if we're going the LIBGL road, can we please use the GBM variable > first and then fallback to the LIBGL one ? This way things won't break for > people using the former. Meanwhile I'm writing docs/gbm.html with some > rough description what gbm is and all the env vars used :-) > Is there a usecase for having a seperate GBM_DRIVERS_PATH? >>> Guess we'll know that when people come complaining that it broke their >>> setup. >>> It will be piglit's "OMG this broke my setup - revert revert. But this has >>> been on the ML for xx days", story all over again. >> >> Isn't this a vacuous problem? The drivers GBM opens are the same >> drivers specified by LIBGL_DRIVERS_PATH, and there's never been any >> difference or way to install "GBM drivers" elsewhere. I.e., no one >> ever has specified something different for GBM_DRIVERS_PATH and >> LIBGL_DRIVERS_PATH intentionally. >> > Still don't see what the problem is: you wanted LIBGL to control do world - > sure, go ahead. All I asked for is to not rub the middle finger in someone's > face just because they never came to personally tell you that's the way they > do things. Essentially I'm trying to find a compromise that works for everyone > yet you come with the "no one" and "ever" statements, which are a bit silly > IMHO, especially in the context of an open-source project. > > I'm quite "enjoying" this bike-shedding. People just refuse that others may > have with different work flow than theirs. Well... I'm off this topic enjoy > your "world domination" plan :P Tell me how it would be possible to have different values for GBM_DRIVERS_PATH and LIBGL_DRIVERS_PATH, when they're loading the same drivers. If you can't do that, then you're just wasting bandwidth with these emails. I'm not just claiming that I've never heard of people doing this. I'm claiming that it's completely nonsensical to do it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On 25/07/14 03:14, Matt Turner wrote: > On Thu, Jul 24, 2014 at 5:17 PM, Emil Velikov > wrote: >> On 24/07/14 22:08, Dylan Baker wrote: >>> On Thursday, July 24, 2014 09:32:38 PM Emil Velikov wrote: On 22/07/14 19:43, Dylan Baker wrote: > GBM_DRIVERS_PATH is not documented, and only used to set the location of > gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and > is documented. > > Generally this split leads to confusion as to why gbm doesn't work. > > This patch makes LIBGL_DRIVERS_PATH the main variable, but uses > GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL. Dylan if we're going the LIBGL road, can we please use the GBM variable first and then fallback to the LIBGL one ? This way things won't break for people using the former. Meanwhile I'm writing docs/gbm.html with some rough description what gbm is and all the env vars used :-) >>> >>> Is there a usecase for having a seperate GBM_DRIVERS_PATH? >> Guess we'll know that when people come complaining that it broke their setup. >> It will be piglit's "OMG this broke my setup - revert revert. But this has >> been on the ML for xx days", story all over again. > > Isn't this a vacuous problem? The drivers GBM opens are the same > drivers specified by LIBGL_DRIVERS_PATH, and there's never been any > difference or way to install "GBM drivers" elsewhere. I.e., no one > ever has specified something different for GBM_DRIVERS_PATH and > LIBGL_DRIVERS_PATH intentionally. > Still don't see what the problem is: you wanted LIBGL to control do world - sure, go ahead. All I asked for is to not rub the middle finger in someone's face just because they never came to personally tell you that's the way they do things. Essentially I'm trying to find a compromise that works for everyone yet you come with the "no one" and "ever" statements, which are a bit silly IMHO, especially in the context of an open-source project. I'm quite "enjoying" this bike-shedding. People just refuse that others may have with different work flow than theirs. Well... I'm off this topic enjoy your "world domination" plan :P -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/20] i965: Use basic-block aware insertion/removal functions.
To avoid invalidating and recreating the control flow graph. Also stop
invalidating the CFG in places we didn't add or remove an instruction.
cfg calculations: 202951 -> 80307 (-60.43%)
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 45 +-
.../drivers/dri/i965/brw_fs_copy_propagation.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 8 ++--
.../dri/i965/brw_fs_dead_code_eliminate.cpp| 6 +--
.../drivers/dri/i965/brw_fs_register_coalesce.cpp | 7 ++--
.../dri/i965/brw_fs_saturate_propagation.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4.cpp | 10 ++---
.../drivers/dri/i965/brw_vec4_copy_propagation.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_cse.cpp | 8 ++--
9 files changed, 50 insertions(+), 40 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 59d46e8..30fc137 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -46,6 +46,7 @@ extern "C" {
#include "brw_wm.h"
}
#include "brw_fs.h"
+#include "brw_cfg.h"
#include "brw_dead_control_flow.h"
#include "main/uniforms.h"
#include "brw_fs_live_variables.h"
@@ -1695,7 +1696,7 @@ fs_visitor::split_virtual_grfs()
}
}
}
- invalidate_live_intervals();
+ invalidate_live_intervals(false);
}
/**
@@ -1733,7 +1734,7 @@ fs_visitor::compact_virtual_grfs()
if (remap_table[i] != -1) {
remap_table[i] = new_index;
virtual_grf_sizes[new_index] = virtual_grf_sizes[i];
- invalidate_live_intervals();
+ invalidate_live_intervals(false);
++new_index;
}
}
@@ -1902,7 +1903,9 @@ fs_visitor::assign_constant_locations()
void
fs_visitor::demote_pull_constants()
{
- foreach_in_list(fs_inst, inst, &instructions) {
+ calculate_cfg();
+
+ foreach_block_and_inst (block, fs_inst, inst, cfg) {
for (int i = 0; i < inst->sources; i++) {
if (inst->src[i].file != UNIFORM)
continue;
@@ -1925,14 +1928,14 @@ fs_visitor::demote_pull_constants()
surf_index,
*inst->src[i].reladdr,
pull_index);
-inst->insert_before(&list);
+inst->insert_before(block, &list);
inst->src[i].reladdr = NULL;
} else {
fs_reg offset = fs_reg((unsigned)(pull_index * 4) & ~15);
fs_inst *pull =
new(mem_ctx) fs_inst(FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD,
dst, surf_index, offset);
-inst->insert_before(pull);
+inst->insert_before(block, pull);
inst->src[i].set_smear(pull_index & 3);
}
@@ -1942,7 +1945,7 @@ fs_visitor::demote_pull_constants()
inst->src[i].reg_offset = 0;
}
}
- invalidate_live_intervals();
+ invalidate_live_intervals(false);
}
bool
@@ -2232,7 +2235,9 @@ fs_visitor::remove_duplicate_mrf_writes()
memset(last_mrf_move, 0, sizeof(last_mrf_move));
- foreach_in_list_safe(fs_inst, inst, &instructions) {
+ calculate_cfg();
+
+ foreach_block_and_inst_safe (block, fs_inst, inst, cfg) {
if (inst->is_control_flow()) {
memset(last_mrf_move, 0, sizeof(last_mrf_move));
}
@@ -2241,7 +2246,7 @@ fs_visitor::remove_duplicate_mrf_writes()
inst->dst.file == MRF) {
fs_inst *prev_inst = last_mrf_move[inst->dst.reg];
if (prev_inst && inst->equals(prev_inst)) {
- inst->remove();
+ inst->remove(block);
progress = true;
continue;
}
@@ -2280,7 +2285,7 @@ fs_visitor::remove_duplicate_mrf_writes()
}
if (progress)
- invalidate_live_intervals();
+ invalidate_live_intervals(false);
return progress;
}
@@ -2515,7 +2520,9 @@ fs_visitor::insert_gen4_send_dependency_workarounds()
void
fs_visitor::lower_uniform_pull_constant_loads()
{
- foreach_in_list(fs_inst, inst, &instructions) {
+ calculate_cfg();
+
+ foreach_block_and_inst (block, fs_inst, inst, cfg) {
if (inst->opcode != FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD)
continue;
@@ -2540,7 +2547,7 @@ fs_visitor::lower_uniform_pull_constant_loads()
setup->ir = inst->ir;
setup->annotation = inst->annotation;
- inst->insert_before(setup);
+ inst->insert_before(block, setup);
/* Similarly, this will only populate the first 4 channels of the
* result register (since we only use smear values from 0-3), but we
@@ -2549,7 +2556,7 @@ fs_visitor::lower_uniform_pull_constant_loads()
inst->opcode = FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD_GEN7;
inst->src[1] = payload;
- invalidate_live_intervals();
+ invalidate_live_intervals(false);
} else {
/* Befor
[Mesa-dev] [PATCH 17/20] i965: Preserve CFG when deleting dead control flow.
This pass deletes an IF/ELSE/ENDIF or IF/ENDIF sequence, or the ELSE in
an ELSE/ENDIF sequence.
In the typical case (where IF and ENDIF) aren't the only instructions in
their basic blocks, we can simply remove the instructions (implicitly
deleting the block containing only the ELSE), and attempt to merge
blocks B0 and B2 together.
B0: ...
(+f0) if(8)
B1: else(8)
B2: endif(8)
...
If the IF or ENDIF instructions are the only instructions in their
respective basic blocks (which are deleted by the removal of the
instructions), we'll want to instead merge the next blocks.
Both B0 and B2 are possibly removed by the removal of if & endif.
Same situation for if/endif. E.g., in the following example we'd remove
blocks B1 and B2, and then attempt to combine B0 and B3.
B0: ...
B1: (+f0) if(8)
B2: endif(8)
B3: ...
---
.../drivers/dri/i965/brw_dead_control_flow.cpp | 44 ++
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
b/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
index e6ace5c..56dc79e 100644
--- a/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
+++ b/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
@@ -42,7 +42,8 @@ dead_control_flow_eliminate(backend_visitor *v)
v->calculate_cfg();
- foreach_block (block, v->cfg) {
+ foreach_block_safe (block, v->cfg) {
+ bblock_t *if_block = NULL, *else_block = NULL, *endif_block = block;
bool found = false;
/* ENDIF instructions, by definition, can only be found at the start of
@@ -56,6 +57,7 @@ dead_control_flow_eliminate(backend_visitor *v)
backend_instruction *prev_inst = (backend_instruction *)
endif_inst->prev;
if (prev_inst->opcode == BRW_OPCODE_ELSE) {
else_inst = prev_inst;
+ else_block = (bblock_t *)endif_block->link.prev;
found = true;
prev_inst = (backend_instruction *) prev_inst->prev;
@@ -63,6 +65,8 @@ dead_control_flow_eliminate(backend_visitor *v)
if (prev_inst->opcode == BRW_OPCODE_IF) {
if_inst = prev_inst;
+ if_block = else_block != NULL ? (bblock_t *)else_block->link.prev
+ : (bblock_t *)endif_block->link.prev;
found = true;
} else {
/* Don't remove the ENDIF if we didn't find a dead IF. */
@@ -70,18 +74,42 @@ dead_control_flow_eliminate(backend_visitor *v)
}
if (found) {
- if (if_inst)
-if_inst->remove();
- if (else_inst)
-else_inst->remove();
- if (endif_inst)
-endif_inst->remove();
+ bblock_t *earlier_block = NULL, *later_block = NULL;
+
+ if (if_inst) {
+if (if_block->start_ip == if_block->end_ip) {
+ earlier_block = (bblock_t *)if_block->link.prev;
+} else {
+ earlier_block = if_block;
+}
+if_inst->remove(if_block);
+ }
+
+ if (else_inst) {
+else_block->if_block->else_block = NULL;
+else_inst->remove(else_block);
+ }
+
+ if (endif_inst) {
+if (endif_block->start_ip == endif_block->end_ip) {
+ later_block = (bblock_t *)endif_block->link.next;
+} else {
+ later_block = endif_block;
+}
+endif_inst->remove(endif_block);
+ }
+
+ assert((earlier_block == NULL) == (later_block == NULL));
+ if (earlier_block && earlier_block->can_combine_with(later_block)) {
+earlier_block->combine_with(later_block);
+ }
+
progress = true;
}
}
if (progress)
- v->invalidate_live_intervals();
+ v->invalidate_live_intervals(false);
return progress;
}
--
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/20] i965: Add invalidate_cfg parameter to invalidate_live_intervals().
Will let us avoid invalidating the CFG if the optimization pass has
removed instructions using the new basic block methods.
---
src/mesa/drivers/dri/i965/brw_fs.h| 2 +-
src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp | 5 +++--
src/mesa/drivers/dri/i965/brw_shader.h| 2 +-
src/mesa/drivers/dri/i965/brw_vec4.h | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp | 5 +++--
5 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 009a6d5..6fe23d2 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -329,7 +329,7 @@ public:
void move_uniform_array_access_to_pull_constants();
void assign_constant_locations();
void demote_pull_constants();
- void invalidate_live_intervals();
+ void invalidate_live_intervals(bool invalidate_cfg = true);
void calculate_live_intervals();
void calculate_register_pressure();
bool opt_algebraic();
diff --git a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
index 4b23405..88b4d39 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
@@ -289,12 +289,13 @@ fs_live_variables::~fs_live_variables()
}
void
-fs_visitor::invalidate_live_intervals()
+fs_visitor::invalidate_live_intervals(bool __invalidate_cfg)
{
ralloc_free(live_intervals);
live_intervals = NULL;
- invalidate_cfg();
+ if (__invalidate_cfg)
+ invalidate_cfg();
}
/**
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h
b/src/mesa/drivers/dri/i965/brw_shader.h
index d174d5c..cbb3b17 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.h
+++ b/src/mesa/drivers/dri/i965/brw_shader.h
@@ -184,7 +184,7 @@ public:
void assign_common_binding_table_offsets(uint32_t
next_binding_table_offset);
- virtual void invalidate_live_intervals() = 0;
+ virtual void invalidate_live_intervals(bool invalidate_cfg = true) = 0;
};
uint32_t brw_texture_offset(struct gl_context *ctx, ir_constant *offset);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 7be27a0..c8b80f1 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -379,7 +379,7 @@ public:
void split_uniform_registers();
void pack_uniform_registers();
void calculate_live_intervals();
- void invalidate_live_intervals();
+ void invalidate_live_intervals(bool invalidate_cfg = true);
void split_virtual_grfs();
bool dead_code_eliminate();
bool virtual_grf_interferes(int a, int b);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp
index 265b064..c8a0c90 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_live_variables.cpp
@@ -267,11 +267,12 @@ vec4_visitor::calculate_live_intervals()
}
void
-vec4_visitor::invalidate_live_intervals()
+vec4_visitor::invalidate_live_intervals(bool __invalidate_cfg)
{
live_intervals_valid = false;
- invalidate_cfg();
+ if (__invalidate_cfg)
+ invalidate_cfg();
}
bool
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 20/20] i965/fs: Preserve CFG in predicated break pass.
Operating on this code,
B0: ...
cmp.ne.f0(8)
(+f0) if(8)
B1: break(8)
B2: endif(8)
We can delete B2 without attempting to merge any blocks, since the
break/continue instruction necessarily ends the previous block.
After deleting the if instruction, we attempt to merge blocks B0 and B1.
---
.../dri/i965/brw_fs_peephole_predicated_break.cpp | 29 +++---
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
index 445d10e..ab197ee 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
@@ -64,27 +64,48 @@ fs_visitor::opt_peephole_predicated_break()
if (endif_inst->opcode != BRW_OPCODE_ENDIF)
continue;
+ bblock_t *jump_block = block;
+ bblock_t *if_block = (bblock_t *)jump_block->link.prev;
+ bblock_t *endif_block = (bblock_t *)jump_block->link.next;
+
/* For Sandybridge with IF with embedded comparison we need to emit an
* instruction to set the flag register.
*/
if (brw->gen == 6 && if_inst->conditional_mod) {
fs_inst *cmp_inst = CMP(reg_null_d, if_inst->src[0], if_inst->src[1],
if_inst->conditional_mod);
- if_inst->insert_before(cmp_inst);
+ if_inst->insert_before(if_block, cmp_inst);
jump_inst->predicate = BRW_PREDICATE_NORMAL;
} else {
jump_inst->predicate = if_inst->predicate;
jump_inst->predicate_inverse = if_inst->predicate_inverse;
}
- if_inst->remove();
- endif_inst->remove();
+ bblock_t *earlier_block = if_block;
+ if (if_block->start_ip == if_block->end_ip) {
+ earlier_block = (bblock_t *)if_block->link.prev;
+ }
+
+ if_inst->remove(if_block);
+ endif_inst->remove(endif_block);
+
+ if_block->children.make_empty();
+ endif_block->parents.make_empty();
+
+ if_block->add_successor(cfg->mem_ctx, jump_block);
+ jump_block->add_successor(cfg->mem_ctx, endif_block);
+
+ if (earlier_block->can_combine_with(jump_block)) {
+ earlier_block->combine_with(jump_block);
+
+ block = earlier_block;
+ }
progress = true;
}
if (progress)
- invalidate_live_intervals();
+ invalidate_live_intervals(false);
return progress;
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 18/20] i965/fs: Preserve CFG in the SEL peephole.
---
src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
b/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
index d64cd98..f609138 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
@@ -212,23 +212,26 @@ fs_visitor::opt_peephole_sel()
if (brw->gen == 6 && if_inst->conditional_mod) {
fs_inst *cmp_inst = CMP(reg_null_d, if_inst->src[0], if_inst->src[1],
if_inst->conditional_mod);
- if_inst->insert_before(cmp_inst);
+ if_inst->insert_before(block, cmp_inst);
}
+ bblock_t *then_block = (bblock_t *)block->link.next;
+ bblock_t *else_block = (bblock_t *)block->else_block->link.next;
+
for (int i = 0; i < movs; i++) {
if (mov_imm_inst[i])
-if_inst->insert_before(mov_imm_inst[i]);
- if_inst->insert_before(sel_inst[i]);
+if_inst->insert_before(block, mov_imm_inst[i]);
+ if_inst->insert_before(block, sel_inst[i]);
- then_mov[i]->remove();
- else_mov[i]->remove();
+ then_mov[i]->remove(then_block);
+ else_mov[i]->remove(else_block);
}
progress = true;
}
if (progress)
- invalidate_live_intervals();
+ invalidate_live_intervals(false);
return progress;
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 16/20] i965/cfg: Add functions to combine basic blocks.
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 59 +++
src/mesa/drivers/dri/i965/brw_cfg.h | 2 ++
2 files changed, 61 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index 3895469..a51d0d2 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
@@ -92,6 +92,65 @@ bblock_t::is_successor_of(const bblock_t *block) const
return false;
}
+static bool
+ends_block(const backend_instruction *inst)
+{
+ enum opcode op = inst->opcode;
+
+ return op == BRW_OPCODE_IF ||
+ op == BRW_OPCODE_ELSE ||
+ op == BRW_OPCODE_CONTINUE ||
+ op == BRW_OPCODE_BREAK ||
+ op == BRW_OPCODE_WHILE;
+}
+
+static bool
+starts_block(const backend_instruction *inst)
+{
+ enum opcode op = inst->opcode;
+
+ return op == BRW_OPCODE_DO ||
+ op == BRW_OPCODE_ENDIF;
+}
+
+bool
+bblock_t::can_combine_with(const bblock_t *that) const
+{
+ if ((const bblock_t *)this->link.next != that)
+ return false;
+
+ if (ends_block(this->end) ||
+ starts_block(that->start))
+ return false;
+
+ return true;
+}
+
+/* If I merge this into that, we'll revisit on foreach_block_safe.
+ *we won't on foreach_block.
+ *
+ * If I merge that into this, foreach_block_safe won't work
+ *foreach_block will.
+ *
+ */
+void
+bblock_t::combine_with(bblock_t *that)
+{
+ assert(this->can_combine_with(that));
+ foreach_list_typed (bblock_link, link, link, &this->children) {
+ assert(link->block == that);
+ }
+ foreach_list_typed (bblock_link, link, link, &that->parents) {
+ assert(link->block == this);
+ }
+
+ this->end_ip = that->end_ip;
+ this->end = that->end;
+ this->else_block = that->else_block;
+
+ this->cfg->remove_block(that);
+}
+
void
bblock_t::dump(backend_visitor *v)
{
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 9ffa7da..9f914cc 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -60,6 +60,8 @@ struct bblock_t {
void add_successor(void *mem_ctx, bblock_t *successor);
bool is_predecessor_of(const bblock_t *block) const;
bool is_successor_of(const bblock_t *block) const;
+ bool can_combine_with(const bblock_t *that) const;
+ void combine_with(bblock_t *that);
void dump(backend_visitor *v);
#endif
--
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/20] i965: Add a basic-block aware backend_instruction::remove method.
---
src/mesa/drivers/dri/i965/brw_cfg.h | 1 +
src/mesa/drivers/dri/i965/brw_shader.cpp | 32
src/mesa/drivers/dri/i965/brw_shader.h | 4
3 files changed, 37 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 35ee29a..e1ec43b 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -64,6 +64,7 @@ struct bblock_t {
#endif
struct exec_node link;
+ struct cfg_t *cfg;
struct backend_instruction *start;
struct backend_instruction *end;
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 0deb090..47535a9 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -740,6 +740,38 @@ backend_instruction::has_side_effects() const
}
void
+backend_instruction::remove(bblock_t *block)
+{
+ bool found = false; (void) found;
+ foreach_inst_in_block (backend_instruction, i, block) {
+ if (this == i) {
+ found = true;
+ }
+ }
+ assert(found || !"Instruction not in block");
+
+ for (bblock_t *block_iter = (bblock_t *)block->link.next;
+!block_iter->link.is_tail_sentinel();
+block_iter = (bblock_t *)block_iter->link.next) {
+ block_iter->start_ip--;
+ block_iter->end_ip--;
+ }
+
+ if (block->start_ip == block->end_ip) {
+ block->cfg->remove_block(block);
+ } else {
+ block->end_ip--;
+
+ if (block->start == this)
+ block->start = (backend_instruction *)this->next;
+ if (block->end == this)
+ block->end = (backend_instruction *)this->prev;
+ }
+
+ this->remove();
+}
+
+void
backend_visitor::dump_instructions()
{
dump_instructions(NULL);
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h
b/src/mesa/drivers/dri/i965/brw_shader.h
index 40689eb..4b80ea9 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.h
+++ b/src/mesa/drivers/dri/i965/brw_shader.h
@@ -78,6 +78,7 @@ struct backend_reg
};
struct cfg_t;
+struct bblock_t;
#ifdef __cplusplus
struct backend_instruction : public exec_node {
@@ -89,6 +90,9 @@ struct backend_instruction : public exec_node {
bool reads_accumulator_implicitly() const;
bool writes_accumulator_implicitly(struct brw_context *brw) const;
+ using exec_node::remove;
+ void remove(bblock_t *block);
+
/**
* True if the instruction has side effects other than writing to
* its destination registers. You are expected not to reorder or
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/20] i965/cfg: Point to bblock_t containing associated control flow
... rather than pointing directly to the associated instruction. This
will let us set the block containing the IF statement's else-pointer to
NULL, when we delete a useless ELSE instruction, as in the case
(+f0) if(8)
...
else(8)
endif(8)
Also, remove the pointer to the ENDIF, since it's unused, and it was
also potentially wrong, in the case of a basic block containing both an
ENDIF and an IF instruction:
endif(8)
cmp.ne.f0(8) ...
(+f0) if(8)
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 28 ---
src/mesa/drivers/dri/i965/brw_cfg.h | 10
src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp | 4 ++--
3 files changed, 15 insertions(+), 27 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index c39edad..3895469 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
@@ -51,17 +51,14 @@ link(void *mem_ctx, bblock_t *block)
}
bblock_t::bblock_t(cfg_t *cfg) :
- cfg(cfg), start_ip(0), end_ip(0), num(0)
+ cfg(cfg), start_ip(0), end_ip(0), num(0),
+ if_block(NULL), else_block(NULL)
{
start = NULL;
end = NULL;
parents.make_empty();
children.make_empty();
-
- if_inst = NULL;
- else_inst = NULL;
- endif_inst = NULL;
}
void
@@ -183,32 +180,25 @@ cfg_t::cfg_t(exec_list *instructions)
set_next_block(&cur, cur_endif, ip - 1);
}
- backend_instruction *else_inst = NULL;
if (cur_else) {
-else_inst = (backend_instruction *)cur_else->end;
-
cur_else->add_successor(mem_ctx, cur_endif);
} else {
cur_if->add_successor(mem_ctx, cur_endif);
}
assert(cur_if->end->opcode == BRW_OPCODE_IF);
- assert(!else_inst || else_inst->opcode == BRW_OPCODE_ELSE);
- assert(inst->opcode == BRW_OPCODE_ENDIF);
+ assert(!cur_else || cur_else->end->opcode == BRW_OPCODE_ELSE);
- cur_if->if_inst = cur_if->end;
- cur_if->else_inst = else_inst;
- cur_if->endif_inst = inst;
+ cur_if->if_block = cur_if;
+ cur_if->else_block = cur_else;
if (cur_else) {
-cur_else->if_inst = cur_if->end;
-cur_else->else_inst = else_inst;
-cur_else->endif_inst = inst;
+cur_else->if_block = cur_if;
+cur_else->else_block = cur_else;
}
- cur->if_inst = cur_if->end;
- cur->else_inst = else_inst;
- cur->endif_inst = inst;
+ cur->if_block = cur_if;
+ cur->else_block = cur_else;
/* Pop the stack so we're in the previous if/else/endif */
cur_if = pop_stack(&if_stack);
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index e1ec43b..9ffa7da 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -76,15 +76,13 @@ struct bblock_t {
struct exec_list children;
int num;
- /* If the current basic block ends in an IF, ELSE, or ENDIF instruction,
-* these pointers will hold the locations of the other associated control
-* flow instructions.
+ /* If the current basic block ends in an IF or ELSE instruction, these will
+* point to the basic blocks containing the other associated instruction.
*
* Otherwise they are NULL.
*/
- struct backend_instruction *if_inst;
- struct backend_instruction *else_inst;
- struct backend_instruction *endif_inst;
+ struct bblock_t *if_block;
+ struct bblock_t *else_block;
};
struct cfg_t {
diff --git a/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
b/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
index 5c79296..d64cd98 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
@@ -137,10 +137,10 @@ fs_visitor::opt_peephole_sel()
if (if_inst->opcode != BRW_OPCODE_IF)
continue;
- if (!block->else_inst)
+ if (!block->else_block)
continue;
- fs_inst *else_inst = (fs_inst *) block->else_inst;
+ fs_inst *else_inst = (fs_inst *) block->else_block->end;
assert(else_inst->opcode == BRW_OPCODE_ELSE);
fs_inst *else_mov[MAX_MOVS] = { NULL };
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/20] i965/fs: Preserve CFG in register allocation.
---
src/mesa/drivers/dri/i965/brw_fs.h| 4 ++--
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 20
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 6fe23d2..c01e224 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -397,8 +397,8 @@ public:
bool opt_saturate_propagation();
void emit_bool_to_cond_code(ir_rvalue *condition);
void emit_if_gen6(ir_if *ir);
- void emit_unspill(fs_inst *inst, fs_reg reg, uint32_t spill_offset,
- int count);
+ void emit_unspill(bblock_t *block, fs_inst *inst, fs_reg reg,
+ uint32_t spill_offset, int count);
void emit_fragment_program_code();
void setup_fp_regs();
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index 3f27364..a9fd53b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -26,6 +26,7 @@
*/
#include "brw_fs.h"
+#include "brw_cfg.h"
#include "glsl/glsl_types.h"
#include "glsl/ir_optimization.h"
@@ -529,8 +530,8 @@ fs_visitor::assign_regs(bool allow_spilling)
}
void
-fs_visitor::emit_unspill(fs_inst *inst, fs_reg dst, uint32_t spill_offset,
- int count)
+fs_visitor::emit_unspill(bblock_t *block, fs_inst *inst, fs_reg dst,
+ uint32_t spill_offset, int count)
{
for (int i = 0; i < count; i++) {
/* The gen7 descriptor-based offset is 12 bits of HWORD units. */
@@ -549,7 +550,7 @@ fs_visitor::emit_unspill(fs_inst *inst, fs_reg dst,
uint32_t spill_offset,
unspill_inst->base_mrf = 14;
unspill_inst->mlen = 1; /* header contains offset */
}
- inst->insert_before(unspill_inst);
+ inst->insert_before(block, unspill_inst);
dst.reg_offset++;
spill_offset += dispatch_width * sizeof(float);
@@ -664,12 +665,14 @@ fs_visitor::spill_reg(int spill_reg)
last_scratch += size * reg_size;
+ calculate_cfg();
+
/* Generate spill/unspill instructions for the objects being
* spilled. Right now, we spill or unspill the whole thing to a
* virtual grf of the same size. For most instructions, though, we
* could just spill/unspill the GRF being accessed.
*/
- foreach_in_list(fs_inst, inst, &instructions) {
+ foreach_block_and_inst (block, fs_inst, inst, cfg) {
for (unsigned int i = 0; i < inst->sources; i++) {
if (inst->src[i].file == GRF &&
inst->src[i].reg == spill_reg) {
@@ -681,7 +684,8 @@ fs_visitor::spill_reg(int spill_reg)
inst->src[i].reg = unspill_dst.reg;
inst->src[i].reg_offset = 0;
-emit_unspill(inst, unspill_dst, subset_spill_offset, regs_read);
+emit_unspill(block, inst, unspill_dst, subset_spill_offset,
+ regs_read);
}
}
@@ -700,7 +704,7 @@ fs_visitor::spill_reg(int spill_reg)
*/
if (inst->predicate || inst->force_uncompressed ||
inst->force_sechalf || inst->dst.subreg_offset) {
-emit_unspill(inst, spill_src, subset_spill_offset,
+emit_unspill(block, inst, spill_src, subset_spill_offset,
inst->regs_written);
}
@@ -714,10 +718,10 @@ fs_visitor::spill_reg(int spill_reg)
spill_inst->annotation = inst->annotation;
spill_inst->mlen = 1 + dispatch_width / 8; /* header, value */
spill_inst->base_mrf = spill_base_mrf;
- inst->insert_after(spill_inst);
+ inst->insert_after(block, spill_inst);
}
}
}
- invalidate_live_intervals();
+ invalidate_live_intervals(false);
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 19/20] i965/fs: Rename variable in predicated break pass.
---
.../drivers/dri/i965/brw_fs_peephole_predicated_break.cpp | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
index fe3812d..445d10e 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
@@ -51,15 +51,16 @@ fs_visitor::opt_peephole_predicated_break()
/* BREAK and CONTINUE instructions, by definition, can only be found at
* the ends of basic blocks.
*/
- fs_inst *inst = (fs_inst *) block->end;
- if (inst->opcode != BRW_OPCODE_BREAK && inst->opcode !=
BRW_OPCODE_CONTINUE)
+ fs_inst *jump_inst = (fs_inst *)block->end;
+ if (jump_inst->opcode != BRW_OPCODE_BREAK &&
+ jump_inst->opcode != BRW_OPCODE_CONTINUE)
continue;
- fs_inst *if_inst = (fs_inst *) inst->prev;
+ fs_inst *if_inst = (fs_inst *)jump_inst->prev;
if (if_inst->opcode != BRW_OPCODE_IF)
continue;
- fs_inst *endif_inst = (fs_inst *) inst->next;
+ fs_inst *endif_inst = (fs_inst *)jump_inst->next;
if (endif_inst->opcode != BRW_OPCODE_ENDIF)
continue;
@@ -70,10 +71,10 @@ fs_visitor::opt_peephole_predicated_break()
fs_inst *cmp_inst = CMP(reg_null_d, if_inst->src[0], if_inst->src[1],
if_inst->conditional_mod);
if_inst->insert_before(cmp_inst);
- inst->predicate = BRW_PREDICATE_NORMAL;
+ jump_inst->predicate = BRW_PREDICATE_NORMAL;
} else {
- inst->predicate = if_inst->predicate;
- inst->predicate_inverse = if_inst->predicate_inverse;
+ jump_inst->predicate = if_inst->predicate;
+ jump_inst->predicate_inverse = if_inst->predicate_inverse;
}
if_inst->remove();
--
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/20] i965: Pass a cfg pointer to generate_{code, assembly}.
---
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 4 +++-
src/mesa/drivers/dri/i965/brw_fs.cpp | 10 ++
src/mesa/drivers/dri/i965/brw_fs.h| 12 ++--
src/mesa/drivers/dri/i965/brw_fs_generator.cpp| 22 +-
src/mesa/drivers/dri/i965/brw_vec4.cpp| 6 --
src/mesa/drivers/dri/i965/brw_vec4.h | 8
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 12
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 10 +-
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 22 +-
src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp | 12
src/mesa/drivers/dri/i965/intel_asm_annotation.c | 2 +-
src/mesa/drivers/dri/i965/intel_asm_annotation.h | 2 +-
12 files changed, 56 insertions(+), 66 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
index c1676a9..8fa2e0e 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
@@ -24,6 +24,7 @@
#include "glsl/ralloc.h"
#include "brw_blorp_blit_eu.h"
#include "brw_blorp.h"
+#include "brw_cfg.h"
brw_blorp_eu_emitter::brw_blorp_eu_emitter(struct brw_context *brw,
bool debug_flag)
@@ -43,7 +44,8 @@ brw_blorp_eu_emitter::~brw_blorp_eu_emitter()
const unsigned *
brw_blorp_eu_emitter::get_program(unsigned *program_size)
{
- return generator.generate_assembly(NULL, &insts, program_size);
+ cfg_t cfg(&insts);
+ return generator.generate_assembly(NULL, &cfg, program_size);
}
/**
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 0d1185b..2fd700f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3170,6 +3170,8 @@ fs_visitor::run()
*/
assert(sanity_param_count == fp->Base.Parameters->NumParameters);
+ calculate_cfg();
+
return !failed;
}
@@ -3213,7 +3215,7 @@ brw_wm_fs_emit(struct brw_context *brw,
return NULL;
}
- exec_list *simd16_instructions = NULL;
+ cfg_t *simd16_cfg = NULL;
fs_visitor v2(brw, mem_ctx, key, prog_data, prog, fp, 16);
if (brw->gen >= 5 && likely(!(INTEL_DEBUG & DEBUG_NO16))) {
if (!v.simd16_unsupported) {
@@ -3223,7 +3225,7 @@ brw_wm_fs_emit(struct brw_context *brw,
perf_debug("SIMD16 shader failed to compile, falling back to "
"SIMD8 at a 10-20%% performance cost: %s", v2.fail_msg);
} else {
-simd16_instructions = &v2.instructions;
+simd16_cfg = v2.cfg;
}
} else {
perf_debug("SIMD16 shader unsupported, falling back to "
@@ -3234,12 +3236,12 @@ brw_wm_fs_emit(struct brw_context *brw,
const unsigned *assembly = NULL;
if (brw->gen >= 8) {
gen8_fs_generator g(brw, mem_ctx, key, prog_data, prog, fp,
v.do_dual_src);
- assembly = g.generate_assembly(&v.instructions, simd16_instructions,
+ assembly = g.generate_assembly(v.cfg, simd16_cfg,
final_assembly_size);
} else {
fs_generator g(brw, mem_ctx, key, prog_data, prog, fp, v.do_dual_src,
v.runtime_check_aads_emit, INTEL_DEBUG & DEBUG_WM);
- assembly = g.generate_assembly(&v.instructions, simd16_instructions,
+ assembly = g.generate_assembly(v.cfg, simd16_cfg,
final_assembly_size);
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 9ba3f38..009a6d5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -578,12 +578,12 @@ public:
bool debug_flag);
~fs_generator();
- const unsigned *generate_assembly(exec_list *simd8_instructions,
- exec_list *simd16_instructions,
+ const unsigned *generate_assembly(const cfg_t *simd8_cfg,
+ const cfg_t *simd16_cfg,
unsigned *assembly_size);
private:
- void generate_code(exec_list *instructions);
+ void generate_code(const cfg_t *cfg);
void fire_fb_write(fs_inst *inst,
GLuint base_reg,
struct brw_reg implied_header,
@@ -706,12 +706,12 @@ public:
bool dual_source_output);
~gen8_fs_generator();
- const unsigned *generate_assembly(exec_list *simd8_instructions,
- exec_list *simd16_instructions,
+ const unsigned *generate_assembly(const cfg_t *simd8_cfg,
+ const cfg_t *simd16_cfg,
unsigned *assembly_size);
private:
- void generate_code(exec_list *instructions);
+ void generate_code(const cfg_t *cfg);
void generate_fb_write(fs_inst *inst);
[Mesa-dev] [PATCH 11/20] i965: Add basic-block aware backend_instruction::insert_* methods.
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 80
src/mesa/drivers/dri/i965/brw_shader.h | 5 ++
2 files changed, 85 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 47535a9..ba93cbc 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -740,6 +740,86 @@ backend_instruction::has_side_effects() const
}
void
+backend_instruction::insert_after(bblock_t *block, backend_instruction *inst)
+{
+ bool found = false; (void) found;
+ foreach_inst_in_block (backend_instruction, i, block) {
+ if (this == i) {
+ found = true;
+ }
+ }
+ assert(found || !"Instruction not in block");
+
+ block->end_ip++;
+
+ for (bblock_t *block_iter = (bblock_t *)block->link.next;
+!block_iter->link.is_tail_sentinel();
+block_iter = (bblock_t *)block_iter->link.next) {
+ block_iter->start_ip++;
+ block_iter->end_ip++;
+ }
+
+ if (block->end == this)
+ block->end = inst;
+
+ this->insert_after(inst);
+}
+
+void
+backend_instruction::insert_before(bblock_t *block, backend_instruction *inst)
+{
+ bool found = false; (void) found;
+ foreach_inst_in_block (backend_instruction, i, block) {
+ if (this == i) {
+ found = true;
+ }
+ }
+ assert(found || !"Instruction not in block");
+
+ block->end_ip++;
+
+ for (bblock_t *block_iter = (bblock_t *)block->link.next;
+!block_iter->link.is_tail_sentinel();
+block_iter = (bblock_t *)block_iter->link.next) {
+ block_iter->start_ip++;
+ block_iter->end_ip++;
+ }
+
+ if (block->start == this)
+ block->start = inst;
+
+ this->insert_before(inst);
+}
+
+void
+backend_instruction::insert_before(bblock_t *block, exec_list *list)
+{
+ bool found = false; (void) found;
+ foreach_inst_in_block (backend_instruction, i, block) {
+ if (this == i) {
+ found = true;
+ }
+ }
+ assert(found || !"Instruction not in block");
+
+ unsigned num_inst = list->length();
+
+ block->end_ip += num_inst;
+
+ for (bblock_t *block_iter = (bblock_t *)block->link.next;
+!block_iter->link.is_tail_sentinel();
+block_iter = (bblock_t *)block_iter->link.next) {
+ block_iter->start_ip += num_inst;
+ block_iter->end_ip += num_inst;
+ }
+
+ if (block->start == this)
+ block->start = (backend_instruction *)list->get_head();
+
+ this->insert_before(list);
+}
+
+void
backend_instruction::remove(bblock_t *block)
{
bool found = false; (void) found;
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h
b/src/mesa/drivers/dri/i965/brw_shader.h
index 4b80ea9..d174d5c 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.h
+++ b/src/mesa/drivers/dri/i965/brw_shader.h
@@ -92,6 +92,11 @@ struct backend_instruction : public exec_node {
using exec_node::remove;
void remove(bblock_t *block);
+ using exec_node::insert_after;
+ void insert_after(bblock_t *block, backend_instruction *inst);
+ using exec_node::insert_before;
+ void insert_before(bblock_t *block, backend_instruction *inst);
+ void insert_before(bblock_t *block, exec_list *list);
/**
* True if the instruction has side effects other than writing to
--
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/20] i965/cfg: Add functions to test if a block is a successor/predecessor.
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 24
src/mesa/drivers/dri/i965/brw_cfg.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index d806b83..9cd8b9f 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
@@ -71,6 +71,30 @@ bblock_t::add_successor(void *mem_ctx, bblock_t *successor)
children.push_tail(::link(mem_ctx, successor));
}
+bool
+bblock_t::is_predecessor_of(const bblock_t *block) const
+{
+ foreach_list_typed_safe (bblock_link, parent, link, &block->parents) {
+ if (parent->block == this) {
+ return true;
+ }
+ }
+
+ return false;
+}
+
+bool
+bblock_t::is_successor_of(const bblock_t *block) const
+{
+ foreach_list_typed_safe (bblock_link, child, link, &block->children) {
+ if (child->block == this) {
+ return true;
+ }
+ }
+
+ return false;
+}
+
void
bblock_t::dump(backend_visitor *v)
{
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 29e31e7..a688870 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -58,6 +58,8 @@ struct bblock_t {
bblock_t();
void add_successor(void *mem_ctx, bblock_t *successor);
+ bool is_predecessor_of(const bblock_t *block) const;
+ bool is_successor_of(const bblock_t *block) const;
void dump(backend_visitor *v);
#endif
--
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/20] i965/cfg: Add a foreach_block_and_inst_safe macro.
---
src/mesa/drivers/dri/i965/brw_cfg.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 913a1ed..29e31e7 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -109,6 +109,10 @@ struct cfg_t {
foreach_block (__block, __cfg) \
foreach_inst_in_block (__type, __inst, __block)
+#define foreach_block_and_inst_safe(__block, __type, __inst, __cfg) \
+ foreach_block_safe (__block, __cfg) \
+ foreach_inst_in_block_safe (__type, __inst, __block)
+
#define foreach_block(__block, __cfg) \
foreach_list_typed (bblock_t, __block, link, &(__cfg)->block_list)
--
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/20] i965/cfg: Add a foreach_block_safe macro.
---
src/mesa/drivers/dri/i965/brw_cfg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index f7203e2..a5d2df5 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -112,6 +112,9 @@ struct cfg_t {
#define foreach_block(__block, __cfg) \
foreach_list_typed (bblock_t, __block, link, &(__cfg)->block_list)
+#define foreach_block_safe(__block, __cfg) \
+ foreach_list_typed_safe (bblock_t, __block, link, &(__cfg)->block_list)
+
#define foreach_inst_in_block(__type, __inst, __block) \
for (__type *__inst = (__type *)__block->start; \
__inst != __block->end->next; \
--
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/20] i965/cfg: Embed link in bblock_t for main block list.
The next patch adds a foreach_block (block, cfg) macro, which works
better if it provides a direct bblock_t pointer, rather than a
bblock_link pointer that you have to use to find the actual block.
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 10 +-
src/mesa/drivers/dri/i965/brw_cfg.h | 2 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index 07111f5..4a5c912 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
@@ -67,8 +67,8 @@ bblock_t::bblock_t() :
void
bblock_t::add_successor(void *mem_ctx, bblock_t *successor)
{
- successor->parents.push_tail(link(mem_ctx, this));
- children.push_tail(link(mem_ctx, successor));
+ successor->parents.push_tail(::link(mem_ctx, this));
+ children.push_tail(::link(mem_ctx, successor));
}
void
@@ -285,7 +285,7 @@ cfg_t::set_next_block(bblock_t **cur, bblock_t *block, int
ip)
block->start_ip = ip;
block->block_num = num_blocks++;
- block_list.push_tail(link(mem_ctx, block));
+ block_list.push_tail(&block->link);
*cur = block;
}
@@ -295,8 +295,8 @@ cfg_t::make_block_array()
blocks = ralloc_array(mem_ctx, bblock_t *, num_blocks);
int i = 0;
- foreach_list_typed(bblock_link, link, link, &block_list) {
- blocks[i++] = link->block;
+ foreach_list_typed(bblock_t, block, link, &block_list) {
+ blocks[i++] = block;
}
assert(i == num_blocks);
}
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 01fcc1b..324df6c 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -61,6 +61,8 @@ struct bblock_t {
void dump(backend_visitor *v);
#endif
+ struct exec_node link;
+
struct backend_instruction *start;
struct backend_instruction *end;
--
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/20] !UPSTREAM: print cfg counts
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 1 +
src/mesa/drivers/dri/i965/brw_shader.cpp | 4 +++-
src/mesa/drivers/dri/i965/brw_shader.h | 1 +
src/mesa/drivers/dri/i965/brw_vec4.cpp | 1 +
4 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 2fd700f..59d46e8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3171,6 +3171,7 @@ fs_visitor::run()
assert(sanity_param_count == fp->Base.Parameters->NumParameters);
calculate_cfg();
+ fprintf(stderr, "fs%d cfg: %d\n", dispatch_width, num_cfg);
return !failed;
}
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index f56ea68..0deb090 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -551,7 +551,8 @@ backend_visitor::backend_visitor(struct brw_context *brw,
prog(prog),
stage_prog_data(stage_prog_data),
cfg(NULL),
- stage(stage)
+ stage(stage),
+ num_cfg(0)
{
}
@@ -772,6 +773,7 @@ backend_visitor::calculate_cfg()
if (this->cfg)
return;
cfg = new(mem_ctx) cfg_t(&this->instructions);
+ num_cfg++;
}
void
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h
b/src/mesa/drivers/dri/i965/brw_shader.h
index 5c48671..40689eb 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.h
+++ b/src/mesa/drivers/dri/i965/brw_shader.h
@@ -161,6 +161,7 @@ public:
exec_list instructions;
cfg_t *cfg;
+ int num_cfg;
gl_shader_stage stage;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 5f6526d..5d276eb 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1743,6 +1743,7 @@ vec4_visitor::run()
assert(sanity_param_count == prog->Parameters->NumParameters);
calculate_cfg();
+ fprintf(stderr, "vec4 cfg: %d\n", num_cfg);
return !failed;
}
--
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/20] i965: Add and use foreach_block macro.
Use this as an opportunity to rename 'block_num' to 'num'. block->num is
clear, and block->block_num has always been redundant.
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 17 ++---
src/mesa/drivers/dri/i965/brw_cfg.h| 5 +-
.../drivers/dri/i965/brw_dead_control_flow.cpp | 3 +-
.../drivers/dri/i965/brw_fs_copy_propagation.cpp | 89 ++
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 4 +-
.../dri/i965/brw_fs_dead_code_eliminate.cpp| 5 +-
.../drivers/dri/i965/brw_fs_live_variables.cpp | 50 ++--
.../dri/i965/brw_fs_peephole_predicated_break.cpp | 9 +--
.../dri/i965/brw_fs_saturate_propagation.cpp | 5 +-
src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp | 4 +-
src/mesa/drivers/dri/i965/brw_vec4.cpp | 6 +-
src/mesa/drivers/dri/i965/brw_vec4_cse.cpp | 4 +-
.../drivers/dri/i965/brw_vec4_live_variables.cpp | 50 ++--
src/mesa/drivers/dri/i965/intel_asm_annotation.c | 8 +-
14 files changed, 116 insertions(+), 143 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index 4a5c912..d806b83 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
@@ -51,7 +51,7 @@ link(void *mem_ctx, bblock_t *block)
}
bblock_t::bblock_t() :
- start_ip(0), end_ip(0), block_num(0)
+ start_ip(0), end_ip(0), num(0)
{
start = NULL;
end = NULL;
@@ -284,7 +284,7 @@ cfg_t::set_next_block(bblock_t **cur, bblock_t *block, int
ip)
}
block->start_ip = ip;
- block->block_num = num_blocks++;
+ block->num = num_blocks++;
block_list.push_tail(&block->link);
*cur = block;
}
@@ -295,7 +295,7 @@ cfg_t::make_block_array()
blocks = ralloc_array(mem_ctx, bblock_t *, num_blocks);
int i = 0;
- foreach_list_typed(bblock_t, block, link, &block_list) {
+ foreach_block (block, this) {
blocks[i++] = block;
}
assert(i == num_blocks);
@@ -304,19 +304,18 @@ cfg_t::make_block_array()
void
cfg_t::dump(backend_visitor *v)
{
- for (int b = 0; b < this->num_blocks; b++) {
-bblock_t *block = this->blocks[b];
- fprintf(stderr, "START B%d", b);
+ foreach_block (block, this) {
+ fprintf(stderr, "START B%d", block->num);
foreach_list_typed(bblock_link, link, link, &block->parents) {
fprintf(stderr, " <-B%d",
- link->block->block_num);
+ link->block->num);
}
fprintf(stderr, "\n");
block->dump(v);
- fprintf(stderr, "END B%d", b);
+ fprintf(stderr, "END B%d", block->num);
foreach_list_typed(bblock_link, link, link, &block->children) {
fprintf(stderr, " ->B%d",
- link->block->block_num);
+ link->block->num);
}
fprintf(stderr, "\n");
}
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index 324df6c..f7203e2 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -71,7 +71,7 @@ struct bblock_t {
struct exec_list parents;
struct exec_list children;
- int block_num;
+ int num;
/* If the current basic block ends in an IF, ELSE, or ENDIF instruction,
* these pointers will hold the locations of the other associated control
@@ -109,6 +109,9 @@ struct cfg_t {
foreach_block (__block, __cfg) \
foreach_inst_in_block (__type, __inst, __block)
+#define foreach_block(__block, __cfg) \
+ foreach_list_typed (bblock_t, __block, link, &(__cfg)->block_list)
+
#define foreach_inst_in_block(__type, __inst, __block) \
for (__type *__inst = (__type *)__block->start; \
__inst != __block->end->next; \
diff --git a/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
b/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
index f0530a1..e6ace5c 100644
--- a/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
+++ b/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
@@ -42,8 +42,7 @@ dead_control_flow_eliminate(backend_visitor *v)
v->calculate_cfg();
- for (int b = 0; b < v->cfg->num_blocks; b++) {
- bblock_t *block = v->cfg->blocks[b];
+ foreach_block (block, v->cfg) {
bool found = false;
/* ENDIF instructions, by definition, can only be found at the start of
diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
index 0716202..587e231 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
@@ -104,9 +104,9 @@ fs_copy_prop_dataflow::fs_copy_prop_dataflow(void *mem_ctx,
cfg_t *cfg,
bd = rzalloc_array(mem_ctx, struct block_data, cfg->num_blocks);
num_acp = 0;
- for (int b = 0; b < cfg->num_blocks; b++) {
+ foreach_block (block, cfg) {
[Mesa-dev] [PATCH 05/20] i965/cfg: Add a foreach_inst_in_block_safe macro.
---
src/mesa/drivers/dri/i965/brw_cfg.h | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index a5d2df5..913a1ed 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -120,6 +120,14 @@ struct cfg_t {
__inst != __block->end->next; \
__inst = (__type *)__inst->next)
+#define foreach_inst_in_block_safe(__type, __inst, __block)\
+ for (__type *__inst = (__type *)__block->start, \
+ *__next = (__type *)__inst->next, \
+ *__end = (__type *)__block->end->next->next;\
+__next != __end; \
+__inst = __next, \
+__next = (__type *)__next->next)
+
#define foreach_inst_in_block_reverse(__type, __inst, __block) \
for (__type *__inst = (__type *)__block->end; \
__inst != __block->start->prev;\
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/20] i965: Preserve CFG
These 19 patches reduce the number of times we calculate the CFG by 61.74% (after the previous series, which already reduced it by 55%). To do so, I've added some infrastructure to the CFG code to combine blocks, and to insert and remove instructions while preserving the information stored in the containing basic blocks. There are still a couple more places to update, (grep for 'invalidate_live_intervals()') but I'm going on vacation so I think it's good to send the series as it stands today. >From here, I'm planning to fix up the few remaining places, split the flat instruction list into per-BB lists, and then consider some other simplifications (like why do we use a list to represent children when there can be at most two?) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/20] i965/cfg: Add a function to remove a block from the cfg.
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 58 +--
src/mesa/drivers/dri/i965/brw_cfg.h | 4 ++-
2 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index 9cd8b9f..c39edad 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
@@ -50,8 +50,8 @@ link(void *mem_ctx, bblock_t *block)
return &l->link;
}
-bblock_t::bblock_t() :
- start_ip(0), end_ip(0), num(0)
+bblock_t::bblock_t(cfg_t *cfg) :
+ cfg(cfg), start_ip(0), end_ip(0), num(0)
{
start = NULL;
end = NULL;
@@ -291,10 +291,62 @@ cfg_t::~cfg_t()
ralloc_free(mem_ctx);
}
+void
+cfg_t::remove_block(bblock_t *block)
+{
+ foreach_list_typed_safe (bblock_link, predecessor, link, &block->parents) {
+ /* Remove block from all of its predecessors' successor lists. */
+ foreach_list_typed_safe (bblock_link, successor, link,
+ &predecessor->block->children) {
+ if (block == successor->block) {
+successor->link.remove();
+ralloc_free(successor);
+ }
+ }
+
+ /* Add removed-block's successors to its predecessors' successor lists.
*/
+ foreach_list_typed (bblock_link, successor, link, &block->children) {
+ if (!successor->block->is_successor_of(predecessor->block)) {
+predecessor->block->children.push_tail(link(mem_ctx,
+successor->block));
+ }
+ }
+ }
+
+ foreach_list_typed_safe (bblock_link, successor, link, &block->children) {
+ /* Remove block from all of its childrens' parents lists. */
+ foreach_list_typed_safe (bblock_link, predecessor, link,
+ &successor->block->parents) {
+ if (block == predecessor->block) {
+predecessor->link.remove();
+ralloc_free(predecessor);
+ }
+ }
+
+ /* Add removed-block's predecessors to its successors' predecessor
lists. */
+ foreach_list_typed (bblock_link, predecessor, link, &block->parents) {
+ if (!predecessor->block->is_predecessor_of(successor->block)) {
+successor->block->parents.push_tail(link(mem_ctx,
+ predecessor->block));
+ }
+ }
+ }
+
+ block->link.remove();
+
+ for (int b = block->num; b < this->num_blocks - 1; b++) {
+ this->blocks[b] = this->blocks[b + 1];
+ this->blocks[b]->num = b;
+ }
+
+ this->blocks[this->num_blocks - 1]->num = this->num_blocks - 2;
+ this->num_blocks--;
+}
+
bblock_t *
cfg_t::new_block()
{
- bblock_t *block = new(mem_ctx) bblock_t();
+ bblock_t *block = new(mem_ctx) bblock_t(this);
return block;
}
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index a688870..35ee29a 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -55,7 +55,7 @@ struct bblock_t {
#ifdef __cplusplus
DECLARE_RALLOC_CXX_OPERATORS(bblock_t)
- bblock_t();
+ bblock_t(cfg_t *cfg);
void add_successor(void *mem_ctx, bblock_t *successor);
bool is_predecessor_of(const bblock_t *block) const;
@@ -93,6 +93,8 @@ struct cfg_t {
cfg_t(exec_list *instructions);
~cfg_t();
+ void remove_block(bblock_t *block);
+
bblock_t *new_block();
void set_next_block(bblock_t **cur, bblock_t *block, int ip);
void make_block_array();
--
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 v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On Thu, Jul 24, 2014 at 5:17 PM, Emil Velikov wrote: > On 24/07/14 22:08, Dylan Baker wrote: >> On Thursday, July 24, 2014 09:32:38 PM Emil Velikov wrote: >>> On 22/07/14 19:43, Dylan Baker wrote: GBM_DRIVERS_PATH is not documented, and only used to set the location of gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and is documented. Generally this split leads to confusion as to why gbm doesn't work. This patch makes LIBGL_DRIVERS_PATH the main variable, but uses GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL. >>> >>> Dylan if we're going the LIBGL road, can we please use the GBM variable >>> first and then fallback to the LIBGL one ? This way things won't break for >>> people using the former. Meanwhile I'm writing docs/gbm.html with some >>> rough description what gbm is and all the env vars used :-) >>> >> >> Is there a usecase for having a seperate GBM_DRIVERS_PATH? > Guess we'll know that when people come complaining that it broke their setup. > It will be piglit's "OMG this broke my setup - revert revert. But this has > been on the ML for xx days", story all over again. Isn't this a vacuous problem? The drivers GBM opens are the same drivers specified by LIBGL_DRIVERS_PATH, and there's never been any difference or way to install "GBM drivers" elsewhere. I.e., no one ever has specified something different for GBM_DRIVERS_PATH and LIBGL_DRIVERS_PATH intentionally. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On 24/07/14 22:08, Dylan Baker wrote:
> On Thursday, July 24, 2014 09:32:38 PM Emil Velikov wrote:
>> On 22/07/14 19:43, Dylan Baker wrote:
>>> GBM_DRIVERS_PATH is not documented, and only used to set the location of
>>> gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and
>>> is documented.
>>>
>>> Generally this split leads to confusion as to why gbm doesn't work.
>>>
>>> This patch makes LIBGL_DRIVERS_PATH the main variable, but uses
>>> GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL.
>>
>> Dylan if we're going the LIBGL road, can we please use the GBM variable
>> first and then fallback to the LIBGL one ? This way things won't break for
>> people using the former. Meanwhile I'm writing docs/gbm.html with some
>> rough description what gbm is and all the env vars used :-)
>>
>
> Is there a usecase for having a seperate GBM_DRIVERS_PATH?
Guess we'll know that when people come complaining that it broke their setup.
It will be piglit's "OMG this broke my setup - revert revert. But this has
been on the ML for xx days", story all over again.
> I was under the
> impression that people had asked to get a v2 that still used GBM_DRIVERS_PATH
> to
> keep people scripts working.
>
Indeed, but the order seems the wrong way IMHO. Current patch will break if
people have both LIBGL and GBM set. Flip the order and things will work as
original. You can still use LIBGL :)
-Emil
>> git grep -i gbm -- docs/
>> 0 matches found
>>
>> Thanks
>> Emil
>>
>>> v2: - Use GBM_DRIVERS_PATH as a fallback
>>>
>>> Signed-off-by: Dylan Baker
>>> ---
>>>
>>> src/gbm/backends/dri/gbm_dri.c | 11 +--
>>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gbm/backends/dri/gbm_dri.c
>>> b/src/gbm/backends/dri/gbm_dri.c index 347bc99..3e4851c 100644
>>> --- a/src/gbm/backends/dri/gbm_dri.c
>>> +++ b/src/gbm/backends/dri/gbm_dri.c
>>> @@ -211,9 +211,16 @@ dri_load_driver(struct gbm_dri_device *dri)
>>>
>>> char *get_extensions_name;
>>>
>>> search_paths = NULL;
>>>
>>> + /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
>>>
>>> if (geteuid() == getuid()) {
>>>
>>> - /* don't allow setuid apps to use GBM_DRIVERS_PATH */
>>> - search_paths = getenv("GBM_DRIVERS_PATH");
>>> + search_paths = getenv("LIBGL_DRIVERS_PATH");
>>> +
>>> + /* fallback path for compatability, GBM_DRIVERS_PATH should be
>>> + * dropped eventually
>>> + */
>>> + if (search_paths == NULL) {
>>> + search_paths = getenv("GBM_DRIVERS_PATH");
>>> + }
>>>
>>> }
>>> if (search_paths == NULL)
>>>
>>>search_paths = DEFAULT_DRIVER_DIR;
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] gallium: Move sRGB <-> RGB handling to libmesautil
Signed-off-by: Jason Ekstrand
---
src/gallium/Automake.inc | 2 +
src/gallium/auxiliary/Makefile.am | 4 -
src/gallium/auxiliary/Makefile.sources| 1 -
src/gallium/auxiliary/SConscript | 8 +-
src/gallium/auxiliary/util/u_format_pack.py | 2 +-
src/gallium/auxiliary/util/u_format_s3tc.c| 2 +-
src/gallium/auxiliary/util/u_format_srgb.h| 147
src/gallium/auxiliary/util/u_format_srgb.py | 155 --
src/gallium/drivers/llvmpipe/SConscript | 2 +-
src/gallium/drivers/nouveau/Makefile.am | 1 +
src/gallium/drivers/nouveau/nv50/nv50_state.c | 2 +-
src/gallium/targets/graw-gdi/SConscript | 1 +
src/gallium/targets/graw-null/SConscript | 2 +-
src/gallium/targets/graw-xlib/SConscript | 1 +
src/gallium/targets/pipe-loader/Makefile.am | 2 +-
src/gallium/tests/graw/SConscript | 2 +-
src/gallium/tests/unit/SConscript | 2 +-
src/util/Makefile.am | 11 +-
src/util/Makefile.sources | 3 +
src/util/SConscript | 12 +-
src/util/format_srgb.h| 133 ++
src/util/format_srgb.py | 155 ++
22 files changed, 326 insertions(+), 324 deletions(-)
delete mode 100644 src/gallium/auxiliary/util/u_format_srgb.h
delete mode 100644 src/gallium/auxiliary/util/u_format_srgb.py
create mode 100644 src/util/format_srgb.h
create mode 100644 src/util/format_srgb.py
diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc
index 22ee166..74053eb 100644
--- a/src/gallium/Automake.inc
+++ b/src/gallium/Automake.inc
@@ -11,6 +11,7 @@ GALLIUM_CFLAGS = \
# preprocessor is determined by the ordering of the -I flags.
GALLIUM_DRIVER_CFLAGS = \
-I$(srcdir)/include \
+ -I$(top_srcdir)/src \
-I$(top_srcdir)/include \
-I$(top_srcdir)/src/gallium/include \
-I$(top_srcdir)/src/gallium/auxiliary \
@@ -20,6 +21,7 @@ GALLIUM_DRIVER_CFLAGS = \
GALLIUM_DRIVER_CXXFLAGS = \
-I$(srcdir)/include \
+ -I$(top_srcdir)/src \
-I$(top_srcdir)/include \
-I$(top_srcdir)/src/gallium/include \
-I$(top_srcdir)/src/gallium/auxiliary \
diff --git a/src/gallium/auxiliary/Makefile.am
b/src/gallium/auxiliary/Makefile.am
index 727ed1f..493d306 100644
--- a/src/gallium/auxiliary/Makefile.am
+++ b/src/gallium/auxiliary/Makefile.am
@@ -39,10 +39,6 @@ indices/u_unfilled_gen.c: $(srcdir)/indices/u_unfilled_gen.py
$(AM_V_at)$(MKDIR_P) indices
$(AM_V_GEN) $(PYTHON2) $< > $@
-util/u_format_srgb.c: $(srcdir)/util/u_format_srgb.py
- $(AM_V_at)$(MKDIR_P) util
- $(AM_V_GEN) $(PYTHON2) $< > $@
-
util/u_format_table.c: $(srcdir)/util/u_format_table.py
$(srcdir)/util/u_format_pack.py $(srcdir)/util/u_format_parse.py
$(srcdir)/util/u_format.csv
$(AM_V_at)$(MKDIR_P) util
$(AM_V_GEN) $(PYTHON2) $(srcdir)/util/u_format_table.py
$(srcdir)/util/u_format.csv > $@
diff --git a/src/gallium/auxiliary/Makefile.sources
b/src/gallium/auxiliary/Makefile.sources
index 8919783..3eae9e5 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -162,7 +162,6 @@ C_SOURCES := \
GENERATED_SOURCES := \
indices/u_indices_gen.c \
indices/u_unfilled_gen.c \
- util/u_format_srgb.c \
util/u_format_table.c
GALLIVM_SOURCES := \
diff --git a/src/gallium/auxiliary/SConscript b/src/gallium/auxiliary/SConscript
index 31dfed3..94041d2 100644
--- a/src/gallium/auxiliary/SConscript
+++ b/src/gallium/auxiliary/SConscript
@@ -3,6 +3,7 @@ Import('*')
from sys import executable as python_cmd
env.Append(CPPPATH = [
+'#src',
'indices',
'util',
])
@@ -22,13 +23,6 @@ env.CodeGenerate(
)
env.CodeGenerate(
-target = 'util/u_format_srgb.c',
-script = 'util/u_format_srgb.py',
-source = [],
-command = python_cmd + ' $SCRIPT > $TARGET'
-)
-
-env.CodeGenerate(
target = 'util/u_format_table.c',
script = '#src/gallium/auxiliary/util/u_format_table.py',
source = ['#src/gallium/auxiliary/util/u_format.csv'],
diff --git a/src/gallium/auxiliary/util/u_format_pack.py
b/src/gallium/auxiliary/util/u_format_pack.py
index f9496de..a553e23 100644
--- a/src/gallium/auxiliary/util/u_format_pack.py
+++ b/src/gallium/auxiliary/util/u_format_pack.py
@@ -669,7 +669,7 @@ def generate(formats):
print '#include "u_half.h"'
print '#include "u_format.h"'
print '#include "u_format_other.h"'
-print '#include "u_format_srgb.h"'
+print '#include "util/format_srgb.h"'
print '#include "u_format_yuv.h"'
print '#include "u_format_zs.h"'
print
diff --git a/src/gallium/auxiliary/util/u_format_s3tc.c
b/src/gallium/auxiliary/util/u_format_s3tc.c
index 11b4602..7e05989 100644
--- a/src/gallium/auxiliary/util/u_fo
[Mesa-dev] [PATCH 0/6] Add a libmesautil library for sharing code between
There is a lot of code duplicated or awkwardly shared right now between mesa/main, glsl, and gallium. It would be good to gather these useful things into a central place that does not depend on any of the above. People have talked about doing this from time to time; this series aims to get the ball rolling. Right now, we just gather ralloc, hash_table, some macros, and RGB <-> sRGB conversions. Jason Ekstrand (4): mesa/SConscript: Use Makefile.sources instead of duplicating the file lists util: Gather some common macros gallium: Move sRGB <-> RGB handling to libmesautil mesa/main: Use the RGB <-> sRGB conversion functions in libmesautil Kenneth Graunke (2): util: Move ralloc to a new src/util directory. util: Move the open-addressing linear-probing hash_table to src/util. configure.ac | 4 +- src/Makefile.am| 2 +- src/SConscript | 1 + src/gallium/Automake.inc | 3 + src/gallium/auxiliary/Makefile.am | 4 - src/gallium/auxiliary/Makefile.sources | 1 - src/gallium/auxiliary/SConscript | 8 +- src/gallium/auxiliary/util/u_format_pack.py| 2 +- src/gallium/auxiliary/util/u_format_s3tc.c | 2 +- src/gallium/auxiliary/util/u_format_srgb.h | 147 -- src/gallium/auxiliary/util/u_format_srgb.py| 155 --- src/gallium/drivers/llvmpipe/SConscript| 2 +- src/gallium/drivers/nouveau/Makefile.am| 1 + src/gallium/drivers/nouveau/nv50/nv50_state.c | 2 +- src/gallium/drivers/r300/Makefile.am | 3 + src/gallium/drivers/r300/Makefile.sources | 1 - .../drivers/r300/compiler/radeon_pair_regalloc.c | 2 +- src/gallium/drivers/r300/ralloc.c | 1 - src/gallium/state_trackers/dri/SConscript | 1 + src/gallium/state_trackers/glx/xlib/SConscript | 1 + src/gallium/targets/graw-gdi/SConscript| 1 + src/gallium/targets/graw-null/SConscript | 2 +- src/gallium/targets/graw-xlib/SConscript | 1 + src/gallium/targets/libgl-xlib/SConscript | 2 + src/gallium/targets/pipe-loader/Makefile.am| 1 + src/gallium/tests/graw/SConscript | 2 +- src/gallium/tests/unit/SConscript | 2 +- src/glsl/Makefile.am | 17 +- src/glsl/Makefile.sources | 1 - src/glsl/SConscript| 5 +- src/glsl/builtin_types.cpp | 7 +- src/glsl/glcpp/glcpp.h | 2 +- src/glsl/glsl_parser_extras.cpp| 2 +- src/glsl/glsl_types.h | 2 +- src/glsl/ir.h | 2 +- src/glsl/ir_variable_refcount.cpp | 2 +- src/glsl/link_uniform_block_active_visitor.h | 2 +- src/glsl/link_uniform_blocks.cpp | 2 +- src/glsl/list.h| 2 +- src/glsl/opt_dead_code.cpp | 2 +- src/glsl/ralloc.c | 492 - src/glsl/ralloc.h | 444 --- src/glsl/standalone_scaffolding.cpp| 2 +- src/glsl/tests/builtin_variable_test.cpp | 1 - src/glsl/tests/copy_constant_to_storage_tests.cpp | 2 +- src/glsl/tests/general_ir_test.cpp | 1 - src/glsl/tests/invalidate_locations_test.cpp | 2 +- src/glsl/tests/ralloc_test.cpp | 38 -- src/glsl/tests/sampler_types_test.cpp | 1 - src/glsl/tests/set_uniform_initializer_tests.cpp | 2 +- src/glsl/tests/uniform_initializer_utils.cpp | 2 +- src/glsl/tests/varyings_test.cpp | 2 +- src/loader/Makefile.am | 1 + src/mesa/Makefile.sources | 5 +- src/mesa/SConscript| 342 +- src/mesa/drivers/common/meta.c | 2 +- src/mesa/drivers/common/meta_blit.c| 2 +- src/mesa/drivers/dri/common/SConscript | 1 + src/mesa/drivers/dri/i915/i830_context.c | 2 +- src/mesa/drivers/dri/i915/i915_context.c | 2 +- src/mesa/drivers/dri/i915/intel_context.c | 2 +- src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp| 2 +- src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 +- src/mesa/drivers/dri/i965/brw_clip.c | 2 +- src/mesa/drivers/dri/i965/brw_context.c| 2 +- src/mesa/drivers/dri/i965/brw_eu.c | 2 +- src/mesa/drivers/dri/i965/brw_eu_emit.c| 2 +- src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +- src/mesa/
[Mesa-dev] [PATCH 1/6] mesa/SConscript: Use Makefile.sources instead of duplicating the file lists
Signed-off-by: Jason Ekstrand
---
src/mesa/Makefile.sources | 3 +
src/mesa/SConscript | 341 ++
2 files changed, 11 insertions(+), 333 deletions(-)
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index f4904fb..fdfb2d2 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -3,6 +3,9 @@
# This file is among different build systems. SRCDIR must be defined with
# a trailing slash because the Android build system leaves it undefined.
+SRCDIR = $(top_srcdir)/src/mesa/
+BUILDDIR = $(top_builddir)/src/mesa/
+
# this is part of MAIN_FILES
MAIN_ES_FILES = \
$(SRCDIR)main/es1_conversion.c
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index f565786..fbfaccc 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -31,316 +31,22 @@ else:
('HAVE_DLOPEN', '1'),
])
-#
-# Source files
-#
-
-main_sources = [
-'main/api_arrayelt.c',
-'main/api_exec.c',
-'main/api_loopback.c',
-'main/api_validate.c',
-'main/accum.c',
-'main/arbprogram.c',
-'main/atifragshader.c',
-'main/attrib.c',
-'main/arrayobj.c',
-'main/blend.c',
-'main/blit.c',
-'main/bufferobj.c',
-'main/buffers.c',
-'main/clear.c',
-'main/clip.c',
-'main/colortab.c',
-'main/compute.c',
-'main/condrender.c',
-'main/context.c',
-'main/convolve.c',
-'main/cpuinfo.c',
-'main/debug.c',
-'main/depth.c',
-'main/dlist.c',
-'main/drawpix.c',
-'main/drawtex.c',
-'main/enable.c',
-'main/enums.c',
-'main/errors.c',
-'main/es1_conversion.c',
-'main/eval.c',
-'main/execmem.c',
-'main/extensions.c',
-'main/fbobject.c',
-'main/feedback.c',
-'main/ff_fragment_shader.cpp',
-'main/ffvertex_prog.c',
-'main/fog.c',
-'main/formatquery.c',
-'main/formats.c',
-'main/format_pack.c',
-'main/format_unpack.c',
-'main/framebuffer.c',
-'main/genmipmap.c',
-'main/getstring.c',
-'main/glformats.c',
-'main/hash.c',
-'main/hash_table.c',
-'main/hint.c',
-'main/histogram.c',
-'main/image.c',
-'main/imports.c',
-'main/light.c',
-'main/lines.c',
-'main/matrix.c',
-'main/mipmap.c',
-'main/mm.c',
-'main/multisample.c',
-'main/objectlabel.c',
-'main/pack.c',
-'main/pbo.c',
-'main/performance_monitor.c',
-'main/pipelineobj.c',
-'main/pixel.c',
-'main/pixelstore.c',
-'main/pixeltransfer.c',
-'main/points.c',
-'main/polygon.c',
-'main/querymatrix.c',
-'main/queryobj.c',
-'main/rastpos.c',
-'main/readpix.c',
-'main/remap.c',
-'main/renderbuffer.c',
-'main/samplerobj.c',
-'main/scissor.c',
-'main/set.c',
-'main/shaderapi.c',
-'main/shaderimage.c',
-'main/shaderobj.c',
-'main/shader_query.cpp',
-'main/shared.c',
-'main/state.c',
-'main/stencil.c',
-'main/syncobj.c',
-'main/texcompress.c',
-'main/texcompress_cpal.c',
-'main/texcompress_rgtc.c',
-'main/texcompress_s3tc.c',
-'main/texcompress_fxt1.c',
-'main/texcompress_etc.c',
-'main/texenv.c',
-'main/texformat.c',
-'main/texgen.c',
-'main/texgetimage.c',
-'main/teximage.c',
-'main/texobj.c',
-'main/texparam.c',
-'main/texstate.c',
-'main/texstorage.c',
-'main/texstore.c',
-'main/texturebarrier.c',
-'main/textureview.c',
-'main/transformfeedback.c',
-'main/uniform_query.cpp',
-'main/uniforms.c',
-'main/varray.c',
-'main/vdpau.c',
-'main/version.c',
-'main/viewport.c',
-'main/vtxfmt.c',
-]
-
-glget_sources = [
-'main/get.c',
-]
-
-math_sources = [
-'math/m_debug_clip.c',
-'math/m_debug_norm.c',
-'math/m_debug_xform.c',
-'math/m_eval.c',
-'math/m_matrix.c',
-'math/m_translate.c',
-'math/m_vector.c',
-'math/m_xform.c',
-]
-
-swrast_sources = [
-'swrast/s_aaline.c',
-'swrast/s_aatriangle.c',
-'swrast/s_alpha.c',
-'swrast/s_atifragshader.c',
-'swrast/s_bitmap.c',
-'swrast/s_blend.c',
-'swrast/s_blit.c',
-'swrast/s_clear.c',
-'swrast/s_copypix.c',
-'swrast/s_context.c',
-'swrast/s_depth.c',
-'swrast/s_drawpix.c',
-'swrast/s_feedback.c',
-'swrast/s_fog.c',
-'swrast/s_fragprog.c',
-'swrast/s_lines.c',
-'swrast/s_logic.c',
-'swrast/s_masking.c',
-'swrast/s_points.c',
-'swrast/s_renderbuffer.c',
-'swrast/s_span.c',
-'swrast/s_stencil.c',
-'swrast/s_texcombine.c',
-'swrast/s_texfetch.c',
-'swrast/s_texfilter.c',
-'swrast/s_texrender.c',
-'swrast/s_texture.c',
-'swrast/s_triangle.c',
-'swrast/s_zoom.c',
-]
-
-swrast_setup_sources = [
-'swrast_setup/ss_context.c',
-'swrast_setup/ss_triangle.c',
-]
-
-tnl_sources = [
-'tnl/t_context.c',
-'tnl/t_pipeline.c',
-'tnl/t_draw.c',
-'tnl/t_rasterpos.c',
-'tnl/t_vb_program.c',
-'tnl/t_v
[Mesa-dev] [PATCH 6/6] mesa/main: Use the RGB <-> sRGB conversion functions in libmesautil
Signed-off-by: Jason Ekstrand
---
src/mesa/main/format_pack.c | 102 ++-
src/mesa/main/format_unpack.c| 69 --
src/mesa/main/format_unpack.h| 3 --
src/mesa/main/texcompress_etc.c | 19
src/mesa/main/texcompress_s3tc.c | 25 +-
src/mesa/swrast/s_texfetch.c | 30 +---
src/mesa/swrast/s_texfetch_tmp.h | 34 ++---
src/util/format_srgb.h | 15 ++
8 files changed, 112 insertions(+), 185 deletions(-)
diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
index c97c052..6cbf859 100644
--- a/src/mesa/main/format_pack.c
+++ b/src/mesa/main/format_pack.c
@@ -41,6 +41,7 @@
#include "macros.h"
#include "../../gallium/auxiliary/util/u_format_rgb9e5.h"
#include "../../gallium/auxiliary/util/u_format_r11g11b10f.h"
+#include "util/format_srgb.h"
/** Helper struct for MESA_FORMAT_Z32_FLOAT_S8X24_UINT */
@@ -58,39 +59,6 @@ typedef void (*pack_float_rgba_row_func)(GLuint n,
const GLfloat src[][4], void *dst);
-
-static inline GLfloat
-linear_to_srgb(GLfloat cl)
-{
- if (cl < 0.0f)
- return 0.0f;
- else if (cl < 0.0031308f)
- return 12.92f * cl;
- else if (cl < 1.0f)
- return 1.055f * powf(cl, 0.41666f) - 0.055f;
- else
- return 1.0f;
-}
-
-
-static inline GLubyte
-linear_float_to_srgb_ubyte(GLfloat cl)
-{
- GLubyte res = FLOAT_TO_UBYTE(linear_to_srgb(cl));
- return res;
-}
-
-
-static inline GLubyte
-linear_ubyte_to_srgb_ubyte(GLubyte cl)
-{
- GLubyte res = FLOAT_TO_UBYTE(linear_to_srgb(cl / 255.0f));
- return res;
-}
-
-
-
-
/*
* MESA_FORMAT_A8B8G8R8_UNORM
*/
@@ -1043,18 +1011,18 @@ static void
pack_ubyte_BGR_SRGB8(const GLubyte src[4], void *dst)
{
GLubyte *d = ((GLubyte *) dst);
- d[2] = linear_ubyte_to_srgb_ubyte(src[RCOMP]);
- d[1] = linear_ubyte_to_srgb_ubyte(src[GCOMP]);
- d[0] = linear_ubyte_to_srgb_ubyte(src[BCOMP]);
+ d[2] = util_format_linear_to_srgb_8unorm(src[RCOMP]);
+ d[1] = util_format_linear_to_srgb_8unorm(src[GCOMP]);
+ d[0] = util_format_linear_to_srgb_8unorm(src[BCOMP]);
}
static void
pack_float_BGR_SRGB8(const GLfloat src[4], void *dst)
{
GLubyte *d = ((GLubyte *) dst);
- d[2] = linear_float_to_srgb_ubyte(src[RCOMP]);
- d[1] = linear_float_to_srgb_ubyte(src[GCOMP]);
- d[0] = linear_float_to_srgb_ubyte(src[BCOMP]);
+ d[2] = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ d[1] = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ d[0] = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
}
@@ -1064,9 +1032,9 @@ static void
pack_ubyte_A8B8G8R8_SRGB(const GLubyte src[4], void *dst)
{
GLuint *d = ((GLuint *) dst);
- GLubyte r = linear_ubyte_to_srgb_ubyte(src[RCOMP]);
- GLubyte g = linear_ubyte_to_srgb_ubyte(src[GCOMP]);
- GLubyte b = linear_ubyte_to_srgb_ubyte(src[BCOMP]);
+ GLubyte r = util_format_linear_to_srgb_8unorm(src[RCOMP]);
+ GLubyte g = util_format_linear_to_srgb_8unorm(src[GCOMP]);
+ GLubyte b = util_format_linear_to_srgb_8unorm(src[BCOMP]);
*d = PACK_COLOR_(r, g, b, src[ACOMP]);
}
@@ -1075,9 +1043,9 @@ pack_float_A8B8G8R8_SRGB(const GLfloat src[4], void *dst)
{
GLuint *d = ((GLuint *) dst);
GLubyte r, g, b, a;
- r = linear_float_to_srgb_ubyte(src[RCOMP]);
- g = linear_float_to_srgb_ubyte(src[GCOMP]);
- b = linear_float_to_srgb_ubyte(src[BCOMP]);
+ r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
UNCLAMPED_FLOAT_TO_UBYTE(a, src[ACOMP]);
*d = PACK_COLOR_(r, g, b, a);
}
@@ -1089,9 +1057,9 @@ static void
pack_ubyte_B8G8R8A8_SRGB(const GLubyte src[4], void *dst)
{
GLuint *d = ((GLuint *) dst);
- GLubyte r = linear_ubyte_to_srgb_ubyte(src[RCOMP]);
- GLubyte g = linear_ubyte_to_srgb_ubyte(src[GCOMP]);
- GLubyte b = linear_ubyte_to_srgb_ubyte(src[BCOMP]);
+ GLubyte r = util_format_linear_to_srgb_8unorm(src[RCOMP]);
+ GLubyte g = util_format_linear_to_srgb_8unorm(src[GCOMP]);
+ GLubyte b = util_format_linear_to_srgb_8unorm(src[BCOMP]);
*d = PACK_COLOR_(src[ACOMP], r, g, b);
}
@@ -1100,9 +1068,9 @@ pack_float_B8G8R8A8_SRGB(const GLfloat src[4], void *dst)
{
GLuint *d = ((GLuint *) dst);
GLubyte r, g, b, a;
- r = linear_float_to_srgb_ubyte(src[RCOMP]);
- g = linear_float_to_srgb_ubyte(src[GCOMP]);
- b = linear_float_to_srgb_ubyte(src[BCOMP]);
+ r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
UNCLAMPED_FLOAT_TO_UBYTE(a, src[ACOMP]);
*d = PACK_COLOR_(a, r, g, b);
}
@@ -1114,9 +1082,9 @@ static void
pack_ubyte_R8G8B8A8_SRGB(const GLubyte src[4], void *dst)
{
GLuint *d = ((GLuint *) dst);
- GLubyte r = linear_ubyte_to_srgb_ubyte(src[RC
[Mesa-dev] [PATCH 2/6] util: Move ralloc to a new src/util directory.
From: Kenneth Graunke For a long time, we've wanted a place to put utility code which isn't directly tied to Mesa or Gallium internals. This patch creates a new src/util directory for exactly that purpose, and builds the contents as libmesautil.la. ralloc seemed like a good first candidate. These days, it's directly used by mesa/main, i965, i915, and r300g, so keeping it in src/glsl didn't make much sense. Signed-off-by: Kenneth Graunke v2 (Jason Ekstrand): More realloc uses and some scons fixes Signed-off-by: Jason Ekstrand --- configure.ac | 4 +- src/Makefile.am| 2 +- src/SConscript | 1 + src/gallium/drivers/r300/Makefile.am | 3 + src/gallium/drivers/r300/ralloc.c | 2 +- src/gallium/targets/libgl-xlib/SConscript | 1 + src/glsl/Makefile.am | 13 +- src/glsl/Makefile.sources | 1 - src/glsl/SConscript| 3 + src/glsl/glcpp/glcpp.h | 2 +- src/glsl/glsl_parser_extras.cpp| 2 +- src/glsl/glsl_types.h | 2 +- src/glsl/ir.h | 2 +- src/glsl/list.h| 2 +- src/glsl/ralloc.c | 492 - src/glsl/ralloc.h | 444 --- src/glsl/standalone_scaffolding.cpp| 2 +- src/glsl/tests/builtin_variable_test.cpp | 1 - src/glsl/tests/copy_constant_to_storage_tests.cpp | 2 +- src/glsl/tests/general_ir_test.cpp | 1 - src/glsl/tests/invalidate_locations_test.cpp | 2 +- src/glsl/tests/ralloc_test.cpp | 38 -- src/glsl/tests/sampler_types_test.cpp | 1 - src/glsl/tests/set_uniform_initializer_tests.cpp | 2 +- src/glsl/tests/uniform_initializer_utils.cpp | 2 +- src/glsl/tests/varyings_test.cpp | 2 +- src/mesa/Makefile.sources | 1 + src/mesa/SConscript| 1 + src/mesa/drivers/common/meta.c | 2 +- src/mesa/drivers/common/meta_blit.c| 2 +- src/mesa/drivers/dri/i915/i830_context.c | 2 +- src/mesa/drivers/dri/i915/i915_context.c | 2 +- src/mesa/drivers/dri/i915/intel_context.c | 2 +- src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp| 2 +- src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 +- src/mesa/drivers/dri/i965/brw_clip.c | 2 +- src/mesa/drivers/dri/i965/brw_context.c| 2 +- src/mesa/drivers/dri/i965/brw_eu.c | 2 +- src/mesa/drivers/dri/i965/brw_eu_emit.c| 2 +- src/mesa/drivers/dri/i965/brw_gs.c | 2 +- src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c | 2 +- .../drivers/dri/i965/brw_performance_monitor.c | 2 +- src/mesa/drivers/dri/i965/brw_program.c| 2 +- src/mesa/drivers/dri/i965/brw_sf.c | 2 +- src/mesa/drivers/dri/i965/brw_state_batch.c| 2 +- src/mesa/drivers/dri/i965/brw_vs.c | 2 +- src/mesa/drivers/dri/i965/brw_wm.c | 2 +- src/mesa/drivers/dri/i965/gen8_generator.cpp | 2 +- src/mesa/drivers/dri/i965/intel_screen.c | 2 +- src/mesa/drivers/dri/i965/test_eu_compact.c| 2 +- src/mesa/drivers/x11/SConscript| 1 + src/mesa/main/hash_table.c | 2 +- src/mesa/main/performance_monitor.c| 2 +- src/mesa/main/pipelineobj.c| 2 +- src/mesa/main/set.c| 2 +- src/mesa/main/shaderapi.c | 2 +- src/mesa/main/shaderobj.c | 2 +- src/mesa/main/tests/Makefile.am| 1 + src/mesa/program/register_allocate.c | 2 +- src/util/Makefile.am | 53 +++ src/util/Makefile.sources | 2 + src/util/SConscript| 26 ++ src/util/ralloc.c | 492 + src/util/ralloc.h | 444 +++ src/util/tests/Makefile.am | 40 ++ src/util/tests/ralloc_test.cpp | 38 ++ 66 files changed, 1155 insertions(+), 1031 deletions(-) delete mode 100644 src/glsl/ralloc.c delete mode 100644 src/glsl/ralloc.h delete mode 100644 src/glsl/tests/ralloc_test.cpp create mode 100644 src/util/Makefile.am create mode 100644 src/util/Makefile.sources create mode 100644 src/util/SConscript create mode 100644 src/util/ralloc.c create mode 100644
[Mesa-dev] [PATCH 3/6] util: Move the open-addressing linear-probing hash_table to src/util.
From: Kenneth Graunke This hash table is used in core Mesa, the GLSL compiler, and the i965 driver, which makes it a good candidate for the new src/util module. It's much faster than program/hash_table.[ch] (see commit 6991c2922f5 for data), and José's u_hash_table.c has a comment saying Gallium should probably consider switching to a linear probing hash table at some point. So this seems like the best candidate for a shared data structure. Signed-off-by: Kenneth Graunke v2 (Jason Ekstrand): Pick up another hash_table use and patch up scons Signed-off-by: Jason Ekstrand --- configure.ac | 4 +- src/glsl/Makefile.am | 4 - src/glsl/SConscript| 2 - src/glsl/ir_variable_refcount.cpp | 2 +- src/glsl/link_uniform_block_active_visitor.h | 2 +- src/glsl/link_uniform_blocks.cpp | 2 +- src/glsl/opt_dead_code.cpp | 2 +- src/mesa/Makefile.sources | 1 - src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +- src/mesa/drivers/dri/i965/intel_fbo.c | 2 +- src/mesa/main/errors.c | 2 +- src/mesa/main/hash.c | 2 +- src/mesa/main/hash_table.c | 440 - src/mesa/main/hash_table.h | 106 - src/mesa/main/shaderapi.c | 2 +- src/mesa/main/shared.c | 2 +- src/mesa/main/syncobj.c| 2 +- src/mesa/main/tests/Makefile.am| 2 - src/mesa/main/tests/hash_table/.gitignore | 10 - src/mesa/main/tests/hash_table/Makefile.am | 44 --- src/mesa/main/tests/hash_table/collision.c | 80 src/mesa/main/tests/hash_table/delete_and_lookup.c | 74 src/mesa/main/tests/hash_table/delete_management.c | 88 - src/mesa/main/tests/hash_table/destroy_callback.c | 66 src/mesa/main/tests/hash_table/insert_and_lookup.c | 57 --- src/mesa/main/tests/hash_table/insert_many.c | 72 src/mesa/main/tests/hash_table/null_destroy.c | 37 -- src/mesa/main/tests/hash_table/random_entry.c | 88 - src/mesa/main/tests/hash_table/remove_null.c | 45 --- src/mesa/main/tests/hash_table/replacement.c | 64 --- src/mesa/main/vdpau.c | 2 +- src/util/Makefile.am | 1 + src/util/Makefile.sources | 3 +- src/util/SConscript| 1 + src/util/hash_table.c | 440 + src/util/hash_table.h | 106 + src/util/tests/Makefile.am | 2 + src/util/tests/hash_table/.gitignore | 10 + src/util/tests/hash_table/Makefile.am | 46 +++ src/util/tests/hash_table/collision.c | 80 src/util/tests/hash_table/delete_and_lookup.c | 74 src/util/tests/hash_table/delete_management.c | 88 + src/util/tests/hash_table/destroy_callback.c | 66 src/util/tests/hash_table/insert_and_lookup.c | 57 +++ src/util/tests/hash_table/insert_many.c| 72 src/util/tests/hash_table/null_destroy.c | 37 ++ src/util/tests/hash_table/random_entry.c | 88 + src/util/tests/hash_table/remove_null.c| 45 +++ src/util/tests/hash_table/replacement.c| 64 +++ 49 files changed, 1293 insertions(+), 1295 deletions(-) delete mode 100644 src/mesa/main/hash_table.c delete mode 100644 src/mesa/main/hash_table.h delete mode 100644 src/mesa/main/tests/hash_table/.gitignore delete mode 100644 src/mesa/main/tests/hash_table/Makefile.am delete mode 100644 src/mesa/main/tests/hash_table/collision.c delete mode 100644 src/mesa/main/tests/hash_table/delete_and_lookup.c delete mode 100644 src/mesa/main/tests/hash_table/delete_management.c delete mode 100644 src/mesa/main/tests/hash_table/destroy_callback.c delete mode 100644 src/mesa/main/tests/hash_table/insert_and_lookup.c delete mode 100644 src/mesa/main/tests/hash_table/insert_many.c delete mode 100644 src/mesa/main/tests/hash_table/null_destroy.c delete mode 100644 src/mesa/main/tests/hash_table/random_entry.c delete mode 100644 src/mesa/main/tests/hash_table/remove_null.c delete mode 100644 src/mesa/main/tests/hash_table/replacement.c create mode 100644 src/util/hash_table.c create mode 100644 src/util/hash_table.h create mode 100644 src/util/tests/hash_table/.gitignore create mode 100644 src/util/tests/hash_table/Makefile.am create mode 100644 src/util/tests/hash_table/collision.c create mode 100644 src/util/tests/hash_table/delete_and_lookup.c create mode 100644 src/util/tests/hash_table/delete_management.c create mode
[Mesa-dev] [PATCH 4/6] util: Gather some common macros
This gathers macros that have been included across components into util so
that the include chain can be more vertical. In particular, this makes
util stand on its own without any dependence whatsoever on the rest of
mesa.
Signed-off-by: "Jason Ekstrand"
---
src/gallium/Automake.inc | 1 +
src/gallium/drivers/r300/Makefile.am | 2 +-
src/gallium/drivers/r300/Makefile.sources | 1 -
.../drivers/r300/compiler/radeon_pair_regalloc.c | 2 +-
src/gallium/drivers/r300/ralloc.c | 1 -
src/gallium/state_trackers/dri/SConscript | 1 +
src/gallium/state_trackers/glx/xlib/SConscript | 1 +
src/gallium/targets/libgl-xlib/SConscript | 1 +
src/gallium/targets/pipe-loader/Makefile.am| 1 +
src/glsl/builtin_types.cpp | 7 +-
src/loader/Makefile.am | 1 +
src/mesa/drivers/dri/common/SConscript | 1 +
src/mesa/drivers/osmesa/Makefile.am| 1 +
src/mesa/drivers/osmesa/SConscript | 1 +
src/mesa/drivers/x11/SConscript| 1 +
src/mesa/main/compiler.h | 92 +--
src/mesa/main/macros.h | 4 +-
src/util/Makefile.am | 2 -
src/util/SConscript| 2 -
src/util/hash_table.c | 2 +-
src/util/hash_table.h | 4 +-
src/util/macros.h | 128 +
src/util/ralloc.h | 3 +-
23 files changed, 154 insertions(+), 106 deletions(-)
delete mode 12 src/gallium/drivers/r300/ralloc.c
create mode 100644 src/util/macros.h
diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc
index 73d65a4..22ee166 100644
--- a/src/gallium/Automake.inc
+++ b/src/gallium/Automake.inc
@@ -1,5 +1,6 @@
GALLIUM_CFLAGS = \
-I$(top_srcdir)/include \
+ -I$(top_srcdir)/src \
-I$(top_srcdir)/src/gallium/include \
-I$(top_srcdir)/src/gallium/auxiliary \
$(DEFINES)
diff --git a/src/gallium/drivers/r300/Makefile.am
b/src/gallium/drivers/r300/Makefile.am
index 2c5951b..ae6e8d2 100644
--- a/src/gallium/drivers/r300/Makefile.am
+++ b/src/gallium/drivers/r300/Makefile.am
@@ -4,7 +4,7 @@ include Makefile.sources
include $(top_srcdir)/src/gallium/Automake.inc
AM_CFLAGS = \
- -I$(top_srcdir)/src/util \
+ -I$(top_srcdir)/src \
-I$(top_srcdir)/src/mesa/program \
-I$(top_srcdir)/src/mesa \
-I$(top_srcdir)/src/glsl \
diff --git a/src/gallium/drivers/r300/Makefile.sources
b/src/gallium/drivers/r300/Makefile.sources
index 0e9ab52..f987cf8 100644
--- a/src/gallium/drivers/r300/Makefile.sources
+++ b/src/gallium/drivers/r300/Makefile.sources
@@ -67,5 +67,4 @@ COMPILER_TESTS_SOURCES := \
compiler/tests/unit_test.c
HELPER_SOURCES := \
- ralloc.c \
register_allocate.c
diff --git a/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
b/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
index 1970a34..7b02e53 100644
--- a/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
+++ b/src/gallium/drivers/r300/compiler/radeon_pair_regalloc.c
@@ -33,7 +33,7 @@
#include "main/glheader.h"
#include "program/register_allocate.h"
#include "util/u_memory.h"
-#include "ralloc.h"
+#include "util/ralloc.h"
#include "r300_fragprog_swizzle.h"
#include "radeon_compiler.h"
diff --git a/src/gallium/drivers/r300/ralloc.c
b/src/gallium/drivers/r300/ralloc.c
deleted file mode 12
index 7ad6def..000
--- a/src/gallium/drivers/r300/ralloc.c
+++ /dev/null
@@ -1 +0,0 @@
-../../../util/ralloc.c
\ No newline at end of file
diff --git a/src/gallium/state_trackers/dri/SConscript
b/src/gallium/state_trackers/dri/SConscript
index 89b0352..159ca80 100644
--- a/src/gallium/state_trackers/dri/SConscript
+++ b/src/gallium/state_trackers/dri/SConscript
@@ -11,6 +11,7 @@ env.PkgUseModules(['DRM'])
#env.Append(CPPDEFINES = [('__NOT_HAVE_DRM_H', '1')])
env.Append(CPPPATH = [
+'#/src',
'#/src/mapi',
'#/src/mesa',
'#/src/gallium/state_trackers/dri/common',
diff --git a/src/gallium/state_trackers/glx/xlib/SConscript
b/src/gallium/state_trackers/glx/xlib/SConscript
index 88e81b8..0832989 100644
--- a/src/gallium/state_trackers/glx/xlib/SConscript
+++ b/src/gallium/state_trackers/glx/xlib/SConscript
@@ -6,6 +6,7 @@ Import('*')
env = env.Clone()
env.Append(CPPPATH = [
+'#/src',
'#/src/mapi',
'#/src/mesa',
'#/src/mesa/main',
diff --git a/src/gallium/targets/libgl-xlib/SConscript
b/src/gallium/targets/libgl-xlib/SConscript
index 22cf107..cc39b17 100644
--- a/src/gallium/targets/libgl-xlib/SConscript
+++ b/src/gallium/targets/libgl-xlib/SConscript
@@ -29,6 +29,7 @@ env.Prepend(LIBS = [
ws_xlib,
mesautil,
glapi,
+mesaut
Re: [Mesa-dev] [PATCH] winsys/radeon: fix nop packet padding v2.
On Thu, Jul 24, 2014 at 6:28 PM, wrote:
> From: Jerome Glisse
>
> The ucode we got for hawaii does not support 0x1000 special nop
> packet type 3 and this leads to gpu reading invalid memory. As packet
> type 2 still exist just use packet type 2.
>
> Note this only partialy fix hawaii issues and some zbuffer tiling
> issues are still present.
>
> Changed since v1:
> - use packet type 2 instead of packet 3.
We don't need this change if we use the updated firmware in my 3.17
tree. Looks like the original hawaii CP ucode didn't support the new
0x1000 special case NOP packet.
Alex
>
> Signed-off-by: Jérôme Glisse
> ---
> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> index a06ecb2..9ac7d0e 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> @@ -447,13 +447,8 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs
> *rcs,
> /* pad DMA ring to 8 DWs to meet CP fetch alignment requirements
> * r6xx, requires at least 4 dw alignment to avoid a hw bug.
> */
> -if (cs->ws->info.chip_class <= SI) {
> -while (rcs->cdw & 7)
> -OUT_CS(&cs->base, 0x8000); /* type2 nop packet */
> -} else {
> -while (rcs->cdw & 7)
> -OUT_CS(&cs->base, 0x1000); /* type3 nop packet */
> -}
> +while (rcs->cdw & 7)
> +OUT_CS(&cs->base, 0x8000); /* type2 nop packet */
> break;
> case RING_UVD:
> while (rcs->cdw & 15)
> --
> 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 1/2] main/cs: Add additional compute shader constant values
These are
Reviewed-by: Chris Forbes
On Fri, Jul 25, 2014 at 11:04 AM, Jordan Justen wrote:
> On Thu, Jul 24, 2014 at 3:56 PM, Ilia Mirkin wrote:
>> On Thu, Jul 24, 2014 at 6:44 PM, Jordan Justen
>> wrote:
>>> This fixes piglit's arb_compute_shader-minmax test.
>>>
>>> Signed-off-by: Jordan Justen
>>> ---
>>> Re-send (originally sent June 9)
>>
>> Is there any point in making these Const.Foo so that individual
>> drivers can specify different values? Or would all drivers always just
>> want these values?
>
> Yes, I think some will want to become driver configurable. But, I
> figured they should start as constant and be converted as needed.
>
> -Jordan
>
>>>
>>> src/mesa/main/config.h | 11 +++
>>> src/mesa/main/get_hash_params.py | 7 +++
>>> 2 files changed, 18 insertions(+)
>>>
>>> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
>>> index c96502a..4ec4b75 100644
>>> --- a/src/mesa/main/config.h
>>> +++ b/src/mesa/main/config.h
>>> @@ -289,6 +289,17 @@
>>> #define PERFQUERY_HAVE_GPA_EXTENDED_COUNTERS 0
>>> /*@}*/
>>>
>>> +/** For GL_ARB_compute_shader */
>>> +/*@{*/
>>> +#define MAX_COMPUTE_UNIFORM_BLOCKS 12
>>> +#define MAX_COMPUTE_TEXTURE_IMAGE_UNITS 16
>>> +#define MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS 8
>>> +#define MAX_COMPUTE_ATOMIC_COUNTERS 8
>>> +#define MAX_COMPUTE_SHARED_MEMORY_SIZE 32768
>>> +#define MAX_COMPUTE_UNIFORM_COMPONENTS 512
>>> +#define MAX_COMPUTE_IMAGE_UNIFORMS 8
>>> +/*@}*/
>>> +
>>> /*
>>> * Color channel component order
>>> *
>>> diff --git a/src/mesa/main/get_hash_params.py
>>> b/src/mesa/main/get_hash_params.py
>>> index d45962d..35d6172 100644
>>> --- a/src/mesa/main/get_hash_params.py
>>> +++ b/src/mesa/main/get_hash_params.py
>>> @@ -774,6 +774,13 @@ descriptor=[
>>>
>>> # GL_ARB_compute_shader
>>>[ "MAX_COMPUTE_WORK_GROUP_INVOCATIONS",
>>> "CONTEXT_INT(Const.MaxComputeWorkGroupInvocations),
>>> extra_ARB_compute_shader" ],
>>> + [ "MAX_COMPUTE_UNIFORM_BLOCKS", "CONST(MAX_COMPUTE_UNIFORM_BLOCKS),
>>> extra_ARB_compute_shader" ],
>>> + [ "MAX_COMPUTE_TEXTURE_IMAGE_UNITS",
>>> "CONST(MAX_COMPUTE_TEXTURE_IMAGE_UNITS), extra_ARB_compute_shader" ],
>>> + [ "MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS",
>>> "CONST(MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS), extra_ARB_compute_shader" ],
>>> + [ "MAX_COMPUTE_ATOMIC_COUNTERS", "CONST(MAX_COMPUTE_ATOMIC_COUNTERS),
>>> extra_ARB_compute_shader" ],
>>> + [ "MAX_COMPUTE_SHARED_MEMORY_SIZE",
>>> "CONST(MAX_COMPUTE_SHARED_MEMORY_SIZE), extra_ARB_compute_shader" ],
>>> + [ "MAX_COMPUTE_UNIFORM_COMPONENTS",
>>> "CONST(MAX_COMPUTE_UNIFORM_COMPONENTS), extra_ARB_compute_shader" ],
>>> + [ "MAX_COMPUTE_IMAGE_UNIFORMS", "CONST(MAX_COMPUTE_IMAGE_UNIFORMS),
>>> extra_ARB_compute_shader" ],
>>>
>>> # GL_ARB_gpu_shader5
>>>[ "MAX_GEOMETRY_SHADER_INVOCATIONS",
>>> "CONST(MAX_GEOMETRY_SHADER_INVOCATIONS), extra_ARB_gpu_shader5" ],
>>> --
>>> 2.0.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
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] main/cs: Add additional compute shader constant values
On Thu, Jul 24, 2014 at 3:56 PM, Ilia Mirkin wrote:
> On Thu, Jul 24, 2014 at 6:44 PM, Jordan Justen
> wrote:
>> This fixes piglit's arb_compute_shader-minmax test.
>>
>> Signed-off-by: Jordan Justen
>> ---
>> Re-send (originally sent June 9)
>
> Is there any point in making these Const.Foo so that individual
> drivers can specify different values? Or would all drivers always just
> want these values?
Yes, I think some will want to become driver configurable. But, I
figured they should start as constant and be converted as needed.
-Jordan
>>
>> src/mesa/main/config.h | 11 +++
>> src/mesa/main/get_hash_params.py | 7 +++
>> 2 files changed, 18 insertions(+)
>>
>> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
>> index c96502a..4ec4b75 100644
>> --- a/src/mesa/main/config.h
>> +++ b/src/mesa/main/config.h
>> @@ -289,6 +289,17 @@
>> #define PERFQUERY_HAVE_GPA_EXTENDED_COUNTERS 0
>> /*@}*/
>>
>> +/** For GL_ARB_compute_shader */
>> +/*@{*/
>> +#define MAX_COMPUTE_UNIFORM_BLOCKS 12
>> +#define MAX_COMPUTE_TEXTURE_IMAGE_UNITS 16
>> +#define MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS 8
>> +#define MAX_COMPUTE_ATOMIC_COUNTERS 8
>> +#define MAX_COMPUTE_SHARED_MEMORY_SIZE 32768
>> +#define MAX_COMPUTE_UNIFORM_COMPONENTS 512
>> +#define MAX_COMPUTE_IMAGE_UNIFORMS 8
>> +/*@}*/
>> +
>> /*
>> * Color channel component order
>> *
>> diff --git a/src/mesa/main/get_hash_params.py
>> b/src/mesa/main/get_hash_params.py
>> index d45962d..35d6172 100644
>> --- a/src/mesa/main/get_hash_params.py
>> +++ b/src/mesa/main/get_hash_params.py
>> @@ -774,6 +774,13 @@ descriptor=[
>>
>> # GL_ARB_compute_shader
>>[ "MAX_COMPUTE_WORK_GROUP_INVOCATIONS",
>> "CONTEXT_INT(Const.MaxComputeWorkGroupInvocations),
>> extra_ARB_compute_shader" ],
>> + [ "MAX_COMPUTE_UNIFORM_BLOCKS", "CONST(MAX_COMPUTE_UNIFORM_BLOCKS),
>> extra_ARB_compute_shader" ],
>> + [ "MAX_COMPUTE_TEXTURE_IMAGE_UNITS",
>> "CONST(MAX_COMPUTE_TEXTURE_IMAGE_UNITS), extra_ARB_compute_shader" ],
>> + [ "MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS",
>> "CONST(MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS), extra_ARB_compute_shader" ],
>> + [ "MAX_COMPUTE_ATOMIC_COUNTERS", "CONST(MAX_COMPUTE_ATOMIC_COUNTERS),
>> extra_ARB_compute_shader" ],
>> + [ "MAX_COMPUTE_SHARED_MEMORY_SIZE",
>> "CONST(MAX_COMPUTE_SHARED_MEMORY_SIZE), extra_ARB_compute_shader" ],
>> + [ "MAX_COMPUTE_UNIFORM_COMPONENTS",
>> "CONST(MAX_COMPUTE_UNIFORM_COMPONENTS), extra_ARB_compute_shader" ],
>> + [ "MAX_COMPUTE_IMAGE_UNIFORMS", "CONST(MAX_COMPUTE_IMAGE_UNIFORMS),
>> extra_ARB_compute_shader" ],
>>
>> # GL_ARB_gpu_shader5
>>[ "MAX_GEOMETRY_SHADER_INVOCATIONS",
>> "CONST(MAX_GEOMETRY_SHADER_INVOCATIONS), extra_ARB_gpu_shader5" ],
>> --
>> 2.0.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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] main/cs: Add additional compute shader constant values
On Thu, Jul 24, 2014 at 6:44 PM, Jordan Justen
wrote:
> This fixes piglit's arb_compute_shader-minmax test.
>
> Signed-off-by: Jordan Justen
> ---
> Re-send (originally sent June 9)
Is there any point in making these Const.Foo so that individual
drivers can specify different values? Or would all drivers always just
want these values?
>
> src/mesa/main/config.h | 11 +++
> src/mesa/main/get_hash_params.py | 7 +++
> 2 files changed, 18 insertions(+)
>
> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
> index c96502a..4ec4b75 100644
> --- a/src/mesa/main/config.h
> +++ b/src/mesa/main/config.h
> @@ -289,6 +289,17 @@
> #define PERFQUERY_HAVE_GPA_EXTENDED_COUNTERS 0
> /*@}*/
>
> +/** For GL_ARB_compute_shader */
> +/*@{*/
> +#define MAX_COMPUTE_UNIFORM_BLOCKS 12
> +#define MAX_COMPUTE_TEXTURE_IMAGE_UNITS 16
> +#define MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS 8
> +#define MAX_COMPUTE_ATOMIC_COUNTERS 8
> +#define MAX_COMPUTE_SHARED_MEMORY_SIZE 32768
> +#define MAX_COMPUTE_UNIFORM_COMPONENTS 512
> +#define MAX_COMPUTE_IMAGE_UNIFORMS 8
> +/*@}*/
> +
> /*
> * Color channel component order
> *
> diff --git a/src/mesa/main/get_hash_params.py
> b/src/mesa/main/get_hash_params.py
> index d45962d..35d6172 100644
> --- a/src/mesa/main/get_hash_params.py
> +++ b/src/mesa/main/get_hash_params.py
> @@ -774,6 +774,13 @@ descriptor=[
>
> # GL_ARB_compute_shader
>[ "MAX_COMPUTE_WORK_GROUP_INVOCATIONS",
> "CONTEXT_INT(Const.MaxComputeWorkGroupInvocations), extra_ARB_compute_shader"
> ],
> + [ "MAX_COMPUTE_UNIFORM_BLOCKS", "CONST(MAX_COMPUTE_UNIFORM_BLOCKS),
> extra_ARB_compute_shader" ],
> + [ "MAX_COMPUTE_TEXTURE_IMAGE_UNITS",
> "CONST(MAX_COMPUTE_TEXTURE_IMAGE_UNITS), extra_ARB_compute_shader" ],
> + [ "MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS",
> "CONST(MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS), extra_ARB_compute_shader" ],
> + [ "MAX_COMPUTE_ATOMIC_COUNTERS", "CONST(MAX_COMPUTE_ATOMIC_COUNTERS),
> extra_ARB_compute_shader" ],
> + [ "MAX_COMPUTE_SHARED_MEMORY_SIZE",
> "CONST(MAX_COMPUTE_SHARED_MEMORY_SIZE), extra_ARB_compute_shader" ],
> + [ "MAX_COMPUTE_UNIFORM_COMPONENTS",
> "CONST(MAX_COMPUTE_UNIFORM_COMPONENTS), extra_ARB_compute_shader" ],
> + [ "MAX_COMPUTE_IMAGE_UNIFORMS", "CONST(MAX_COMPUTE_IMAGE_UNIFORMS),
> extra_ARB_compute_shader" ],
>
> # GL_ARB_gpu_shader5
>[ "MAX_GEOMETRY_SHADER_INVOCATIONS",
> "CONST(MAX_GEOMETRY_SHADER_INVOCATIONS), extra_ARB_gpu_shader5" ],
> --
> 2.0.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
[Mesa-dev] [PATCH 1/2] main/cs: Add additional compute shader constant values
This fixes piglit's arb_compute_shader-minmax test.
Signed-off-by: Jordan Justen
---
Re-send (originally sent June 9)
src/mesa/main/config.h | 11 +++
src/mesa/main/get_hash_params.py | 7 +++
2 files changed, 18 insertions(+)
diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
index c96502a..4ec4b75 100644
--- a/src/mesa/main/config.h
+++ b/src/mesa/main/config.h
@@ -289,6 +289,17 @@
#define PERFQUERY_HAVE_GPA_EXTENDED_COUNTERS 0
/*@}*/
+/** For GL_ARB_compute_shader */
+/*@{*/
+#define MAX_COMPUTE_UNIFORM_BLOCKS 12
+#define MAX_COMPUTE_TEXTURE_IMAGE_UNITS 16
+#define MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS 8
+#define MAX_COMPUTE_ATOMIC_COUNTERS 8
+#define MAX_COMPUTE_SHARED_MEMORY_SIZE 32768
+#define MAX_COMPUTE_UNIFORM_COMPONENTS 512
+#define MAX_COMPUTE_IMAGE_UNIFORMS 8
+/*@}*/
+
/*
* Color channel component order
*
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index d45962d..35d6172 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -774,6 +774,13 @@ descriptor=[
# GL_ARB_compute_shader
[ "MAX_COMPUTE_WORK_GROUP_INVOCATIONS",
"CONTEXT_INT(Const.MaxComputeWorkGroupInvocations), extra_ARB_compute_shader" ],
+ [ "MAX_COMPUTE_UNIFORM_BLOCKS", "CONST(MAX_COMPUTE_UNIFORM_BLOCKS),
extra_ARB_compute_shader" ],
+ [ "MAX_COMPUTE_TEXTURE_IMAGE_UNITS",
"CONST(MAX_COMPUTE_TEXTURE_IMAGE_UNITS), extra_ARB_compute_shader" ],
+ [ "MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS",
"CONST(MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS), extra_ARB_compute_shader" ],
+ [ "MAX_COMPUTE_ATOMIC_COUNTERS", "CONST(MAX_COMPUTE_ATOMIC_COUNTERS),
extra_ARB_compute_shader" ],
+ [ "MAX_COMPUTE_SHARED_MEMORY_SIZE", "CONST(MAX_COMPUTE_SHARED_MEMORY_SIZE),
extra_ARB_compute_shader" ],
+ [ "MAX_COMPUTE_UNIFORM_COMPONENTS", "CONST(MAX_COMPUTE_UNIFORM_COMPONENTS),
extra_ARB_compute_shader" ],
+ [ "MAX_COMPUTE_IMAGE_UNIFORMS", "CONST(MAX_COMPUTE_IMAGE_UNIFORMS),
extra_ARB_compute_shader" ],
# GL_ARB_gpu_shader5
[ "MAX_GEOMETRY_SHADER_INVOCATIONS",
"CONST(MAX_GEOMETRY_SHADER_INVOCATIONS), extra_ARB_gpu_shader5" ],
--
2.0.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl/cs: Add several GLSL compute shader variables
This fixes piglit (with GL_ARB_compute_shader force enabled):
built-in-constants tests/spec/arb_compute_shader/minimum-maximums.txt
(Also requires piglit patch "arb_compute_shader glsl min/max: Update
gl_MaxComputeUniformComponents")
Signed-off-by: Jordan Justen
---
src/glsl/builtin_variables.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 3497302..4c5b9c0 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -672,6 +672,12 @@ builtin_variable_generator::generate_constants()
}
if (state->is_version(430, 0) || state->ARB_compute_shader_enable) {
+ add_const("gl_MaxComputeAtomicCounterBuffers",
MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS);
+ add_const("gl_MaxComputeAtomicCounters", MAX_COMPUTE_ATOMIC_COUNTERS);
+ add_const("gl_MaxComputeImageUniforms", MAX_COMPUTE_IMAGE_UNIFORMS);
+ add_const("gl_MaxComputeTextureImageUnits",
MAX_COMPUTE_TEXTURE_IMAGE_UNITS);
+ add_const("gl_MaxComputeUniformComponents",
MAX_COMPUTE_UNIFORM_COMPONENTS);
+
add_const_ivec3("gl_MaxComputeWorkGroupCount",
state->Const.MaxComputeWorkGroupCount[0],
state->Const.MaxComputeWorkGroupCount[1],
--
2.0.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE
On Thu, 2014-07-24 at 13:52 -0400, Alex Deucher wrote: > On Thu, Jul 24, 2014 at 12:05 PM, Jan Vesely wrote: > > > > On Thu, 2014-07-24 at 17:07 +0200, Marek Olšák wrote: > >> Sorry, GL 3.1 actually only requires 1024 vec4s. The UBO extension > >> spec contains a mistake. > >> > >> Marek > >> > >> On Thu, Jul 24, 2014 at 4:55 PM, Marek Olšák wrote: > >> > OpenGL 3.1 requires 4096 vec4s (65536 bytes) per constant buffer and > >> > the hardware supports 16 constant buffers. I'm not sure what the > >> > "constant registers" are, but they cannot have anything to do with the > >> > constant buffer limit, because otherwise we wouldn't be able to meet > >> > the requirement for uniform buffer objects. > > > > Hm, it's rather confusing. > > ch. 2.5 describes 512 128bit Constant Registers (W by host R by GPU) in ALU > > state. > > section 4.6.4 mentions that there are 256 128-bit constants (in constant > > file) available in DX9 mode, > > and 1-4096 128bit in memory constants in dx10 mode. (I guess that's where > > the 4096 value comes from) > > > > Then there's constant cache of 64 128 bit constants, which uses the CR > > mentioned above, > > and I believe is used to pass kernel arguments by clover. > > VLIW4/5 asic also have a kcache which is basically a small cache for > access to a subset of the memory backed DX10 constant buffer. > > > > > I know little about OpenGL, what are these different ways to do the same > > thing good for? > > There's not really different ways. On r6xx/r7xx there was an on-chip > buffer (CFILE) were you could write constants since DX9 had a fixed > size constant file. Storing them in sram on-chip is fast, but takes > die space. With DX10, constants were stored in memory. From > evergreen going forward, the hardware only supports DX10 style memory > backed constant buffers. So if you take the CFILE out of the picture, > there's only one way to access constant buffers. thank you for the explanation Jan > > Alex > > > > > > thanks > > Jan > > > >> > > >> > Marek > >> > > >> > On Thu, Jul 24, 2014 at 4:05 PM, Jan Vesely > >> > wrote: > >> >> On Thu, 2014-07-24 at 06:35 -0700, Tom Stellard wrote: > >> >>> On Thu, Jul 24, 2014 at 01:09:49PM +0200, Marek Olšák wrote: > >> >>> > Isn't this redundant with get_shader_param(PIPE_SHADER_COMPUTE, > >> >>> > PIPE_SHADER_CAP_MAX_CONSTS) * 16? > >> >>> > > >> >>> > >> >>> This is what clover was using, but I was confused about what the value > >> >>> was supposed to represent. Now, I think I understand (number of 4 x > >> >>> 32-bit > >> >>> constants). I can use this instead. > >> >> > >> >> Is the value for r600 hw misreported then? The manuals for R600/EG/NI > >> >> say there are 512 such registers. Yet the driver reports 4096. > >> >> See the attached patch. > >> >> > >> >> Jan > >> >> > >> >>> > >> >>> -Tom > >> >>> > Marek > >> >>> > > >> >>> > On Thu, Jul 24, 2014 at 3:05 AM, Tom Stellard > >> >>> > wrote: > >> >>> > > --- > >> >>> > > src/gallium/docs/source/screen.rst | 2 ++ > >> >>> > > src/gallium/include/pipe/p_defines.h | 3 ++- > >> >>> > > 2 files changed, 4 insertions(+), 1 deletion(-) > >> >>> > > > >> >>> > > diff --git a/src/gallium/docs/source/screen.rst > >> >>> > > b/src/gallium/docs/source/screen.rst > >> >>> > > index 830a1a5..219c9f9 100644 > >> >>> > > --- a/src/gallium/docs/source/screen.rst > >> >>> > > +++ b/src/gallium/docs/source/screen.rst > >> >>> > > @@ -334,6 +334,8 @@ pipe_screen::get_compute_param. > >> >>> > >Value type: ``uint32_t`` > >> >>> > > * ``PIPE_COMPUTE_CAP_IMAGES_SUPPORTED``: Whether images are > >> >>> > > supported > >> >>> > >non-zero means yes, zero means no. Value type: ``uint32_t`` > >> >>> > > +* ``PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE``: The maximum size > >> >>> > > in bytes > >> >>> > > + of a constant buffer. Value type: ``uint64_t`` > >> >>> > > > >> >>> > > .. _pipe_bind: > >> >>> > > > >> >>> > > diff --git a/src/gallium/include/pipe/p_defines.h > >> >>> > > b/src/gallium/include/pipe/p_defines.h > >> >>> > > index 43bb1f5..78709b9 100644 > >> >>> > > --- a/src/gallium/include/pipe/p_defines.h > >> >>> > > +++ b/src/gallium/include/pipe/p_defines.h > >> >>> > > @@ -651,7 +651,8 @@ enum pipe_compute_cap > >> >>> > > PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE, > >> >>> > > PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY, > >> >>> > > PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS, > >> >>> > > - PIPE_COMPUTE_CAP_IMAGES_SUPPORTED > >> >>> > > + PIPE_COMPUTE_CAP_IMAGES_SUPPORTED, > >> >>> > > + PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE > >> >>> > > }; > >> >>> > > > >> >>> > > /** > >> >>> > > -- > >> >>> > > 1.8.1.5 > >> >>> > > > >> >>> > > ___ > >> >>> > > mesa-dev mailing list > >> >>> > > mesa-dev@lists.freedesktop.org > >> >>> > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > >> >>> > ___ > >> >>> > mesa-dev mailing list > >> >>> > mesa-dev@lists.fr
Re: [Mesa-dev] [PATCH] radeonsi: add support for trace buffer.
Reviewed-by: Marek Olšák Marek On Fri, Jul 25, 2014 at 12:07 AM, wrote: > From: Jérôme Glisse > > Trace buffer allow to dump a command buffer which is fully repliable > as a standalone c program. This make debuging lockup immensively > simpler. This patch only plug the core minimal stuff and is still > missing the more fancy aspect that are in r600g. It however already > proved useful in debuging hawaii. > > Signed-off-by: Jérôme Glisse > --- > src/gallium/drivers/radeonsi/si_hw_context.c | 2 +- > src/gallium/drivers/radeonsi/si_pipe.c | 3 ++- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c > b/src/gallium/drivers/radeonsi/si_hw_context.c > index 56fa664..c947cd0 100644 > --- a/src/gallium/drivers/radeonsi/si_hw_context.c > +++ b/src/gallium/drivers/radeonsi/si_hw_context.c > @@ -115,7 +115,7 @@ void si_context_gfx_flush(void *context, unsigned flags, > #endif > > /* Flush the CS. */ > - ctx->b.ws->cs_flush(cs, flags, fence, 0); > + ctx->b.ws->cs_flush(cs, flags, fence, ctx->screen->b.cs_count++); > ctx->b.rings.gfx.flushing = false; > > #if SI_TRACE_CS > diff --git a/src/gallium/drivers/radeonsi/si_pipe.c > b/src/gallium/drivers/radeonsi/si_pipe.c > index 4f19268..2a7049b 100644 > --- a/src/gallium/drivers/radeonsi/si_pipe.c > +++ b/src/gallium/drivers/radeonsi/si_pipe.c > @@ -98,7 +98,8 @@ static struct pipe_context *si_create_context(struct > pipe_screen *screen, void * > } > > sctx->b.rings.gfx.cs = ws->cs_create(ws, RING_GFX, > si_context_gfx_flush, > -sctx, NULL); > +sctx, sscreen->b.trace_bo ? > +sscreen->b.trace_bo->cs_buf : > NULL); > sctx->b.rings.gfx.flush = si_context_gfx_flush; > > si_init_all_descriptors(sctx); > -- > 1.9.3 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] winsys/radeon: fix nop packet padding v2.
From: Jerome Glisse
The ucode we got for hawaii does not support 0x1000 special nop
packet type 3 and this leads to gpu reading invalid memory. As packet
type 2 still exist just use packet type 2.
Note this only partialy fix hawaii issues and some zbuffer tiling
issues are still present.
Changed since v1:
- use packet type 2 instead of packet 3.
Signed-off-by: Jérôme Glisse
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index a06ecb2..9ac7d0e 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -447,13 +447,8 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs
*rcs,
/* pad DMA ring to 8 DWs to meet CP fetch alignment requirements
* r6xx, requires at least 4 dw alignment to avoid a hw bug.
*/
-if (cs->ws->info.chip_class <= SI) {
-while (rcs->cdw & 7)
-OUT_CS(&cs->base, 0x8000); /* type2 nop packet */
-} else {
-while (rcs->cdw & 7)
-OUT_CS(&cs->base, 0x1000); /* type3 nop packet */
-}
+while (rcs->cdw & 7)
+OUT_CS(&cs->base, 0x8000); /* type2 nop packet */
break;
case RING_UVD:
while (rcs->cdw & 15)
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/radeon: fix nop packet padding.
On Thu, Jul 24, 2014 at 05:42:21PM -0400, j.gli...@gmail.com wrote:
> From: Jerome Glisse
>
> The gpu packet prefetcher hates the ugly big nop packet those leads
> to prefetching some invalid memory in some case. Apparently hawaii
> is particularly sensible to this.
>
> Note this only partialy fix hawaii issues and some zbuffer tiling
> issues are still present.
Just to clarify this patch is almost good to go, there is the cs[MAX_DW-1]
case that need fixing and i am pondering on how to do that. Also i have not
tested on bonaire but i do expect that it should only fix thing and not
break things.
Cheers,
Jérôme
>
> Signed-off-by: Jérôme Glisse
> ---
> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> index a06ecb2..502a550 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> @@ -451,8 +451,22 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs
> *rcs,
> while (rcs->cdw & 7)
> OUT_CS(&cs->base, 0x8000); /* type2 nop packet */
> } else {
> -while (rcs->cdw & 7)
> -OUT_CS(&cs->base, 0x1000); /* type3 nop packet */
> +switch (rcs->cdw & 7) {
> +case 0:
> +break;
> +case 7:
> +/* FIXME can this be bad if we are at cs[LAST_DW-1] ? Need to
> + * think of something.
> + */
> +OUT_CS(&cs->base, 0xc0001000);
> +OUT_CS(&cs->base, 0xcafedead);
> +/* Note we fallthrough as this will add another 7 dwords */
> +default:
> +OUT_CS(&cs->base, 0xc0001000 | (((8 - (rcs->cdw & 7)) - 1)
> << 16));
> +while (rcs->cdw & 7) {
> +OUT_CS(&cs->base, 0xcafedead);
> +}
> +}
> }
> break;
> case RING_UVD:
> --
> 1.8.3.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] configure.ac: bail out if building gallium_gbm without gallium_egl
The former is the only user of the latter. As such building gbm without egl makes little to no sense. Cc: "10.2" Signed-off-by: Emil Velikov --- configure.ac | 4 1 file changed, 4 insertions(+) diff --git a/configure.ac b/configure.ac index 744e55c..4482161 100644 --- a/configure.ac +++ b/configure.ac @@ -1345,6 +1345,10 @@ if test "x$enable_gallium_gbm" = xyes; then AC_MSG_ERROR([gbm_gallium requires --enable-dri to build]) fi +if test "x$enable_gallium_egl" != xyes; then +AC_MSG_ERROR([gbm_gallium is only used by egl_gallium]) +fi + GALLIUM_STATE_TRACKERS_DIRS="gbm $GALLIUM_STATE_TRACKERS_DIRS" GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS gbm" enable_gallium_loader=yes -- 2.0.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] configure.ac: drop enable_dri check in gallium_gbm
A while back we've mandated that gbm requires enable_dri, thus this check is no longer required. Signed-off-by: Emil Velikov --- configure.ac | 4 1 file changed, 4 deletions(-) diff --git a/configure.ac b/configure.ac index 4482161..46ed001 100644 --- a/configure.ac +++ b/configure.ac @@ -1340,10 +1340,6 @@ if test "x$enable_gallium_gbm" = xyes; then if test "x$enable_gbm" = xno; then AC_MSG_ERROR([cannot enable gbm_gallium without gbm]) fi -# gbm_gallium abuses DRI_LIB_DEPS to link. Make sure it is set. -if test "x$enable_dri" = xno; then -AC_MSG_ERROR([gbm_gallium requires --enable-dri to build]) -fi if test "x$enable_gallium_egl" != xyes; then AC_MSG_ERROR([gbm_gallium is only used by egl_gallium]) -- 2.0.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: add support for trace buffer.
From: Jérôme Glisse Trace buffer allow to dump a command buffer which is fully repliable as a standalone c program. This make debuging lockup immensively simpler. This patch only plug the core minimal stuff and is still missing the more fancy aspect that are in r600g. It however already proved useful in debuging hawaii. Signed-off-by: Jérôme Glisse --- src/gallium/drivers/radeonsi/si_hw_context.c | 2 +- src/gallium/drivers/radeonsi/si_pipe.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c b/src/gallium/drivers/radeonsi/si_hw_context.c index 56fa664..c947cd0 100644 --- a/src/gallium/drivers/radeonsi/si_hw_context.c +++ b/src/gallium/drivers/radeonsi/si_hw_context.c @@ -115,7 +115,7 @@ void si_context_gfx_flush(void *context, unsigned flags, #endif /* Flush the CS. */ - ctx->b.ws->cs_flush(cs, flags, fence, 0); + ctx->b.ws->cs_flush(cs, flags, fence, ctx->screen->b.cs_count++); ctx->b.rings.gfx.flushing = false; #if SI_TRACE_CS diff --git a/src/gallium/drivers/radeonsi/si_pipe.c b/src/gallium/drivers/radeonsi/si_pipe.c index 4f19268..2a7049b 100644 --- a/src/gallium/drivers/radeonsi/si_pipe.c +++ b/src/gallium/drivers/radeonsi/si_pipe.c @@ -98,7 +98,8 @@ static struct pipe_context *si_create_context(struct pipe_screen *screen, void * } sctx->b.rings.gfx.cs = ws->cs_create(ws, RING_GFX, si_context_gfx_flush, -sctx, NULL); +sctx, sscreen->b.trace_bo ? +sscreen->b.trace_bo->cs_buf : NULL); sctx->b.rings.gfx.flush = si_context_gfx_flush; si_init_all_descriptors(sctx); -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] winsys/radeon: fix nop packet padding.
From: Jerome Glisse
The gpu packet prefetcher hates the ugly big nop packet those leads
to prefetching some invalid memory in some case. Apparently hawaii
is particularly sensible to this.
Note this only partialy fix hawaii issues and some zbuffer tiling
issues are still present.
Signed-off-by: Jérôme Glisse
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index a06ecb2..502a550 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -451,8 +451,22 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs
*rcs,
while (rcs->cdw & 7)
OUT_CS(&cs->base, 0x8000); /* type2 nop packet */
} else {
-while (rcs->cdw & 7)
-OUT_CS(&cs->base, 0x1000); /* type3 nop packet */
+switch (rcs->cdw & 7) {
+case 0:
+break;
+case 7:
+/* FIXME can this be bad if we are at cs[LAST_DW-1] ? Need to
+ * think of something.
+ */
+OUT_CS(&cs->base, 0xc0001000);
+OUT_CS(&cs->base, 0xcafedead);
+/* Note we fallthrough as this will add another 7 dwords */
+default:
+OUT_CS(&cs->base, 0xc0001000 | (((8 - (rcs->cdw & 7)) - 1) <<
16));
+while (rcs->cdw & 7) {
+OUT_CS(&cs->base, 0xcafedead);
+}
+}
}
break;
case RING_UVD:
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On Thursday, July 24, 2014 09:32:38 PM Emil Velikov wrote:
> On 22/07/14 19:43, Dylan Baker wrote:
> > GBM_DRIVERS_PATH is not documented, and only used to set the location of
> > gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and
> > is documented.
> >
> > Generally this split leads to confusion as to why gbm doesn't work.
> >
> > This patch makes LIBGL_DRIVERS_PATH the main variable, but uses
> > GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL.
>
> Dylan if we're going the LIBGL road, can we please use the GBM variable
> first and then fallback to the LIBGL one ? This way things won't break for
> people using the former. Meanwhile I'm writing docs/gbm.html with some
> rough description what gbm is and all the env vars used :-)
>
Is there a usecase for having a seperate GBM_DRIVERS_PATH? I was under the
impression that people had asked to get a v2 that still used GBM_DRIVERS_PATH to
keep people scripts working.
> git grep -i gbm -- docs/
> 0 matches found
>
> Thanks
> Emil
>
> > v2: - Use GBM_DRIVERS_PATH as a fallback
> >
> > Signed-off-by: Dylan Baker
> > ---
> >
> > src/gbm/backends/dri/gbm_dri.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gbm/backends/dri/gbm_dri.c
> > b/src/gbm/backends/dri/gbm_dri.c index 347bc99..3e4851c 100644
> > --- a/src/gbm/backends/dri/gbm_dri.c
> > +++ b/src/gbm/backends/dri/gbm_dri.c
> > @@ -211,9 +211,16 @@ dri_load_driver(struct gbm_dri_device *dri)
> >
> > char *get_extensions_name;
> >
> > search_paths = NULL;
> >
> > + /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
> >
> > if (geteuid() == getuid()) {
> >
> > - /* don't allow setuid apps to use GBM_DRIVERS_PATH */
> > - search_paths = getenv("GBM_DRIVERS_PATH");
> > + search_paths = getenv("LIBGL_DRIVERS_PATH");
> > +
> > + /* fallback path for compatability, GBM_DRIVERS_PATH should be
> > + * dropped eventually
> > + */
> > + if (search_paths == NULL) {
> > + search_paths = getenv("GBM_DRIVERS_PATH");
> > + }
> >
> > }
> > if (search_paths == NULL)
> >
> >search_paths = DEFAULT_DRIVER_DIR;
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/26] glsl: Rebuild the symbol table without unreachable symbols
On Tuesday, July 15, 2014 08:05:31 PM Kenneth Graunke wrote:
> On Monday, July 14, 2014 03:48:34 PM Ian Romanick wrote:
> > From: Ian Romanick
> >
> > Previously we had to keep unreachable global symbols in the symbol table
> > because the symbol table is used during linking. Having the symbol
> > table retain pointers to freed memory... what could possibly go wrong?
> > At the same time, this meant that we kept live references to tons of
> > memory that was no longer needed.
> >
> > New strategy: destroy the old symbol table, and make a new one from the
> > reachable symbols.
> >
> > Valgrind massif results for a trimmed apitrace of dota2:
> >
> > ntime(i) total(B) useful-heap(B) extra-
> heap(B)stacks(B)
> > Before (32-bit): 59 40,642,425,451 76,337,968 69,720,886
> 6,617,0820
> > After (32-bit): 46 40,661,487,174 75,116,800 68,854,065
> 6,262,7350
> >
> > Before (64-bit): 79 37,179,441,771 106,986,512 98,112,095
> 8,874,4170
> > After (64-bit): 64 37,200,329,700 104,872,672 96,514,546
> 8,358,1260
> >
> > A real savings of 846KiB on 32-bit and 1.5MiB on 64-bit.
> >
> > Signed-off-by: Ian Romanick
> > Cc: Kenneth Graunke
> > ---
> > src/glsl/glsl_parser_extras.cpp | 37 -
> > 1 file changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/glsl/glsl_parser_extras.cpp
> b/src/glsl/glsl_parser_extras.cpp
> > index b327c2b..2962407 100644
> > --- a/src/glsl/glsl_parser_extras.cpp
> > +++ b/src/glsl/glsl_parser_extras.cpp
> > @@ -1485,7 +1485,7 @@ _mesa_glsl_compile_shader(struct gl_context *ctx,
> struct gl_shader *shader,
> > if (shader->InfoLog)
> >ralloc_free(shader->InfoLog);
> >
> > - shader->symbols = state->symbols;
> > + shader->symbols = new(shader->ir) glsl_symbol_table;
> > shader->CompileStatus = !state->error;
> > shader->InfoLog = state->info_log;
> > shader->Version = state->language_version;
> > @@ -1498,6 +1498,41 @@ _mesa_glsl_compile_shader(struct gl_context *ctx,
> struct gl_shader *shader,
> > /* Retain any live IR, but trash the rest. */
> > reparent_ir(shader->ir, shader->ir);
> >
> > + /* Destroy the symbol table. Create a new symbol table that contains
> only
> > +* the variables and functions that still exist in the IR. The symbol
> > +* table will be used later during linking.
> > +*
> > +* There must NOT be any freed objects still referenced by the symbol
> > +* table. That could cause the linker to dereference freed memory.
> > +*
> > +* We don't have to worry about types or interface-types here because
> those
> > +* are fly-weights that are looked up by glsl_type.
> > +*/
> > + foreach_in_list (ir_instruction, ir, shader->ir) {
> > + switch (ir->ir_type) {
> > + case ir_type_function: {
> > + /* If the function is a built-in that is partially overridden in
> the
> > + * shader, the ir_function stored in the symbol table may not be
> the
> > + * same as the one that appears in the shader. The one in the
> shader
> > + * will only include definitions from inside the shader. We need
> the
> > + * one from the symbol table because it will include built-in
> > + * defintions and definitions from the shader.
> > + */
> > + ir_function *const def = (ir_function *) ir;
> > + ir_function *const decl = state->symbols->get_function(def->name);
>
> Huh. This doesn't match my understanding of the code. I believe there
> should only be one ir_function with a given name, and it should be both in
> the
> shader's instruction stream and in the symbol table.
>
> That single ir_function should contain any definitions and prototypes created
> in the shader's GLSL code, and also prototypes (but not definitions) for any
> built-in signatures called.
>
> If you look at match_function_by_name(), it always uses the existing
> function,
> if there is one, or creates a new one and adds it in both places...walking
> through a couple scenarios, I haven't seen what's going wrong.
>
> I suppose I should try the obvious
>
>shader->symobls->add_function((ir_function *) ir);
>
> and see what breaks. It sure doesn't seem like anything should. I'll try to
> look into it soon.
Okay, I finally got around to looking into this. Doing the obvious approach
breaks these two Piglit tests:
tests/spec/glsl-1.10/linker/override-builtin-{uniform,const}-05.shader_test
These have a single shader containing:
1. A function that calls built-in abs(float)
2. A user redefinition of abs(float)
3. A third call of abs() - which is supposed to be to be the user function.
At step 1, we create an ir_function for abs, and import the built-in signature.
At step 2 - when processing the function definition - we see that the
[Mesa-dev] [PATCH 3/3] glsl: Rebuild the symbol table without unreachable symbols
From: Ian Romanick
Previously we had to keep unreachable global symbols in the symbol table
because the symbol table is used during linking. Having the symbol
table retain pointers to freed memory... what could possibly go wrong?
At the same time, this meant that we kept live references to tons of
memory that was no longer needed.
New strategy: destroy the old symbol table, and make a new one from the
reachable symbols.
Valgrind massif results for a trimmed apitrace of dota2:
ntime(i) total(B) useful-heap(B)
extra-heap(B)stacks(B)
Before (32-bit): 59 40,642,425,451 76,337,968 69,720,886
6,617,0820
After (32-bit): 46 40,661,487,174 75,116,800 68,854,065
6,262,7350
Before (64-bit): 79 37,179,441,771 106,986,512 98,112,095
8,874,4170
After (64-bit): 64 37,200,329,700 104,872,672 96,514,546
8,358,1260
A real savings of 846KiB on 32-bit and 1.5MiB on 64-bit.
v2: (by Kenneth Graunke) Just add the ir_function from the IR stream,
rather than looking it up in the symbol table; they're now
identical.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/glsl/glsl_parser_extras.cpp | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 890123a..a13e076 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -1487,7 +1487,7 @@ _mesa_glsl_compile_shader(struct gl_context *ctx, struct
gl_shader *shader,
if (shader->InfoLog)
ralloc_free(shader->InfoLog);
- shader->symbols = state->symbols;
+ shader->symbols = new(shader->ir) glsl_symbol_table;
shader->CompileStatus = !state->error;
shader->InfoLog = state->info_log;
shader->Version = state->language_version;
@@ -1500,6 +1500,30 @@ _mesa_glsl_compile_shader(struct gl_context *ctx, struct
gl_shader *shader,
/* Retain any live IR, but trash the rest. */
reparent_ir(shader->ir, shader->ir);
+ /* Destroy the symbol table. Create a new symbol table that contains only
+* the variables and functions that still exist in the IR. The symbol
+* table will be used later during linking.
+*
+* There must NOT be any freed objects still referenced by the symbol
+* table. That could cause the linker to dereference freed memory.
+*
+* We don't have to worry about types or interface-types here because those
+* are fly-weights that are looked up by glsl_type.
+*/
+ foreach_in_list (ir_instruction, ir, shader->ir) {
+ switch (ir->ir_type) {
+ case ir_type_function:
+ shader->symbols->add_function((ir_function *) ir);
+ break;
+ case ir_type_variable:
+ shader->symbols->add_variable((ir_variable *) ir);
+ break;
+ default:
+ break;
+ }
+ }
+
+ delete state->symbols;
ralloc_free(state);
}
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] glsl: Make it possible to ignore built-ins when matching signatures.
Historically, we've implemented the rules for overriding built-in
functions by creating multiple ir_functions and relying on the symbol
table to hide the one containing built-in functions. That works, but
has a few drawbacks, so the next patch will change it.
Instead, we'll have a single ir_function for a particular name, which
will contain both built-in and user-defined signatures. Passing an
extra parameter to matching_signature makes it easy to ignore built-ins
when they're supposed to be hidden.
I didn't add the parameter to exact_matching_signature since it wasn't
necessary.
Signed-off-by: Kenneth Graunke
---
src/glsl/ast_function.cpp | 15 ---
src/glsl/builtin_functions.cpp | 3 ++-
src/glsl/ir.h | 4 +++-
src/glsl/ir_function.cpp | 10 +++---
src/glsl/ir_reader.cpp | 3 ++-
src/glsl/link_functions.cpp| 2 +-
src/glsl/linker.cpp| 3 ++-
src/glsl/lower_packed_varyings.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
src/mesa/program/ir_to_mesa.cpp| 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
12 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 4981fe1..39c7bee 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -450,20 +450,21 @@ match_function_by_name(const char *name,
goto done; /* no match */
if (f != NULL) {
+ /* In desktop GL, the presence of a user-defined signature hides any
+ * built-in signatures, so we must ignore them. In contrast, in ES2
+ * user-defined signatures add new overloads, so we must consider them.
+ */
+ bool allow_builtins = state->es_shader || !f->has_user_signature();
+
/* Look for a match in the local shader. If exact, we're done. */
bool is_exact = false;
sig = local_sig = f->matching_signature(state, actual_parameters,
- &is_exact);
+ allow_builtins, &is_exact);
if (is_exact)
goto done;
- if (!state->es_shader && f->has_user_signature()) {
-/* In desktop GL, the presence of a user-defined signature hides any
- * built-in signatures, so we must ignore them. In contrast, in ES2
- * user-defined signatures add new overloads, so we must proceed.
- */
+ if (!allow_builtins)
goto done;
- }
}
/* Local shader has no exact candidates; check the built-ins. */
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index e01742c..185fe98 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -706,7 +706,8 @@ builtin_builder::find(_mesa_glsl_parse_state *state,
if (f == NULL)
return NULL;
- ir_function_signature *sig = f->matching_signature(state,
actual_parameters);
+ ir_function_signature *sig =
+ f->matching_signature(state, actual_parameters, true);
if (sig == NULL)
return NULL;
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index ea19924..260dd34 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -974,6 +974,7 @@ public:
*/
ir_function_signature *matching_signature(_mesa_glsl_parse_state *state,
const exec_list *actual_param,
+ bool allow_builtins,
bool *match_is_exact);
/**
@@ -981,7 +982,8 @@ public:
* conversions into account.
*/
ir_function_signature *matching_signature(_mesa_glsl_parse_state *state,
- const exec_list *actual_param);
+ const exec_list *actual_param,
+ bool allow_builtins);
/**
* Find a signature that exactly matches a set of actual parameters without
diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
index 7d6c2f4..98bec45 100644
--- a/src/glsl/ir_function.cpp
+++ b/src/glsl/ir_function.cpp
@@ -281,15 +281,18 @@ choose_best_inexact_overload(_mesa_glsl_parse_state
*state,
ir_function_signature *
ir_function::matching_signature(_mesa_glsl_parse_state *state,
-const exec_list *actual_parameters)
+const exec_list *actual_parameters,
+bool allow_builtins)
{
bool is_exact;
- return matching_signature(state, actual_parameters, &is_exact);
+ return matching_signature(state, actual_parameters, allow_builtins,
+ &is_exact);
}
ir_function_signature *
ir_function::matching_signature(_mesa_glsl_parse
[Mesa-dev] [PATCH 2/3] glsl: Only create one ir_function for a given name.
Piglit's spec/glsl-1.10/linker/override-builtin-{const,uniform}-05 tests
do the following:
1. Call abs(float) - a built-in function.
2. Create a user-defined replacement for abs(float).
3. Call abs(float) again - now the user function.
At step 1, we created an ir_function which included the built-in
signature, added it to the symbol table, and emitted it into the IR
stream.
Then, when processing the function definition at step 2, we'd see that
there was already an ir_function. But, since there were no user-defined
functions, we skipped over a bunch of code, and ended up creating a
second one. This new ir_function shadowed the original in the symbol
table, but both ended up in the IR stream.
This results in an awkward situation where searching for an ir_function
via the symbol table, a forward linked list walk, and a reverse linked
list walk may return different ir_functions. This seems undesirable.
This patch instead re-uses the existing ir_function, putting both
built-in and user-defined signatures in the same one. The previous
patch's additional filtering ensures everything continues working.
Signed-off-by: Kenneth Graunke
---
src/glsl/ast_to_hir.cpp | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index a15ee9c..499b6da 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4110,12 +4110,27 @@ ast_function::hir(exec_list *instructions,
name);
}
+ /* Create an ir_function if one doesn't already exist. */
+ f = state->symbols->get_function(name);
+ if (f == NULL) {
+ f = new(ctx) ir_function(name);
+ if (!state->symbols->add_function(f)) {
+ /* This function name shadows a non-function use of the same name. */
+ YYLTYPE loc = this->get_location();
+
+ _mesa_glsl_error(&loc, state, "function name `%s' conflicts with "
+ "non-function", name);
+ return NULL;
+ }
+
+ emit_function(state, f);
+ }
+
/* Verify that this function's signature either doesn't match a previously
* seen signature for a function with the same name, or, if a match is
found,
* that the previously seen signature does not have an associated
definition.
*/
- f = state->symbols->get_function(name);
- if (f != NULL && (state->es_shader || f->has_user_signature())) {
+ if (state->es_shader || f->has_user_signature()) {
sig = f->exact_matching_signature(state, &hir_parameters);
if (sig != NULL) {
const char *badvar = sig->qualifiers_match(&hir_parameters);
@@ -4146,18 +4161,6 @@ ast_function::hir(exec_list *instructions,
}
}
}
- } else {
- f = new(ctx) ir_function(name);
- if (!state->symbols->add_function(f)) {
- /* This function name shadows a non-function use of the same name. */
- YYLTYPE loc = this->get_location();
-
- _mesa_glsl_error(&loc, state, "function name `%s' conflicts with "
- "non-function", name);
- return NULL;
- }
-
- emit_function(state, f);
}
/* Verify the return type of main() */
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On Thu, Jul 24, 2014 at 1:43 PM, Kristian Høgsberg wrote:
> On Thu, Jul 24, 2014 at 1:32 PM, Emil Velikov
> wrote:
>> On 22/07/14 19:43, Dylan Baker wrote:
>>> GBM_DRIVERS_PATH is not documented, and only used to set the location of
>>> gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and
>>> is documented.
>>>
>>> Generally this split leads to confusion as to why gbm doesn't work.
>>>
>>> This patch makes LIBGL_DRIVERS_PATH the main variable, but uses
>>> GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL.
>>>
>> Dylan if we're going the LIBGL road, can we please use the GBM variable first
>> and then fallback to the LIBGL one ? This way things won't break for people
>> using the former. Meanwhile I'm writing docs/gbm.html with some rough
>> description what gbm is and all the env vars used :-)
>>
>> git grep -i gbm -- docs/
>> 0 matches found
>
> The entire public API is documented using doxygen. Look in src/gbm/main/gbm.c
... but a more introductory, overview style document would be very
nice to have as well. Thanks for doing that. It would be nice to
also include a pointer to Robs kmscube as a complete example of how to
use the API.
Kristian
> Kristian
>
>>
>> Thanks
>> Emil
>>
>>> v2: - Use GBM_DRIVERS_PATH as a fallback
>>>
>>> Signed-off-by: Dylan Baker
>>> ---
>>> src/gbm/backends/dri/gbm_dri.c | 11 +--
>>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>>> index 347bc99..3e4851c 100644
>>> --- a/src/gbm/backends/dri/gbm_dri.c
>>> +++ b/src/gbm/backends/dri/gbm_dri.c
>>> @@ -211,9 +211,16 @@ dri_load_driver(struct gbm_dri_device *dri)
>>> char *get_extensions_name;
>>>
>>> search_paths = NULL;
>>> + /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
>>> if (geteuid() == getuid()) {
>>> - /* don't allow setuid apps to use GBM_DRIVERS_PATH */
>>> - search_paths = getenv("GBM_DRIVERS_PATH");
>>> + search_paths = getenv("LIBGL_DRIVERS_PATH");
>>> +
>>> + /* fallback path for compatability, GBM_DRIVERS_PATH should be
>>> + * dropped eventually
>>> + */
>>> + if (search_paths == NULL) {
>>> + search_paths = getenv("GBM_DRIVERS_PATH");
>>> + }
>>> }
>>> if (search_paths == NULL)
>>>search_paths = DEFAULT_DRIVER_DIR;
>>>
>>
>> ___
>> 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] main/mesa: missing atomic buffer bindings to mesa are added in this patch
On Thu, Jul 24, 2014 at 1:40 PM, Aditya Avinash wrote: > Do you want me to resend it? Not just for those comments. If there are other comments that necessitate resending, please fix the two things I mentioned. Otherwise someone will just fix them when they commit your patch. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On Thu, Jul 24, 2014 at 1:32 PM, Emil Velikov wrote:
> On 22/07/14 19:43, Dylan Baker wrote:
>> GBM_DRIVERS_PATH is not documented, and only used to set the location of
>> gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and
>> is documented.
>>
>> Generally this split leads to confusion as to why gbm doesn't work.
>>
>> This patch makes LIBGL_DRIVERS_PATH the main variable, but uses
>> GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL.
>>
> Dylan if we're going the LIBGL road, can we please use the GBM variable first
> and then fallback to the LIBGL one ? This way things won't break for people
> using the former. Meanwhile I'm writing docs/gbm.html with some rough
> description what gbm is and all the env vars used :-)
>
> git grep -i gbm -- docs/
> 0 matches found
The entire public API is documented using doxygen. Look in src/gbm/main/gbm.c
Kristian
>
> Thanks
> Emil
>
>> v2: - Use GBM_DRIVERS_PATH as a fallback
>>
>> Signed-off-by: Dylan Baker
>> ---
>> src/gbm/backends/dri/gbm_dri.c | 11 +--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>> index 347bc99..3e4851c 100644
>> --- a/src/gbm/backends/dri/gbm_dri.c
>> +++ b/src/gbm/backends/dri/gbm_dri.c
>> @@ -211,9 +211,16 @@ dri_load_driver(struct gbm_dri_device *dri)
>> char *get_extensions_name;
>>
>> search_paths = NULL;
>> + /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
>> if (geteuid() == getuid()) {
>> - /* don't allow setuid apps to use GBM_DRIVERS_PATH */
>> - search_paths = getenv("GBM_DRIVERS_PATH");
>> + search_paths = getenv("LIBGL_DRIVERS_PATH");
>> +
>> + /* fallback path for compatability, GBM_DRIVERS_PATH should be
>> + * dropped eventually
>> + */
>> + if (search_paths == NULL) {
>> + search_paths = getenv("GBM_DRIVERS_PATH");
>> + }
>> }
>> if (search_paths == NULL)
>>search_paths = DEFAULT_DRIVER_DIR;
>>
>
> ___
> 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] main/mesa: missing atomic buffer bindings to mesa are added in this patch
Hi,
Do you want me to resend it?
On Thursday, July 24, 2014, Matt Turner wrote:
> The commit message should be something like
>
> "mesa: Add missing atomic buffer bindings and unbindings."
>
> On Thu, Jul 24, 2014 at 12:18 PM, Aditya Atluri
> > wrote:
> > ---
> > src/mesa/main/bufferobj.c | 31 +++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> > index 7b1bba0..1dfcda3 100644
> > --- a/src/mesa/main/bufferobj.c
> > +++ b/src/mesa/main/bufferobj.c
> > @@ -832,6 +832,9 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
> > _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer,
> > ctx->Shared->NullBufferObj);
> >
> > + _mesa_reference_buffer_object(ctx, &ctx->AtomicBuffer,
> > +ctx->Shared->NullBufferObj);
> > +
> > _mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer,
> > ctx->Shared->NullBufferObj);
> >
> > @@ -842,6 +845,14 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
> >ctx->UniformBufferBindings[i].Offset = -1;
> >ctx->UniformBufferBindings[i].Size = -1;
> > }
> > +
> > + for (i = 0; i < MAX_COMBINED_ATOMIC_BUFFERS; i++) {
> > + _mesa_reference_buffer_object(ctx,
> > +
> &ctx->AtomicBufferBindings[i].BufferObject,
> > + ctx->Shared->NullBufferObj);
> > + ctx->AtomicBufferBindings[i].Offset = -1;
> > + ctx->AtomicBufferBindings[i].Size = -1;
> > + }
> > }
> >
> >
> > @@ -857,6 +868,8 @@ _mesa_free_buffer_objects( struct gl_context *ctx )
> >
> > _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer, NULL);
> >
> > + _mesa_reference_buffer_object(ctx, &ctx->AtomicBuffer, NULL);
> > +
> > _mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer, NULL);
> >
> > for (i = 0; i < MAX_COMBINED_UNIFORM_BUFFERS; i++) {
> > @@ -864,6 +877,13 @@ _mesa_free_buffer_objects( struct gl_context *ctx )
> >
> &ctx->UniformBufferBindings[i].BufferObject,
> > NULL);
> > }
> > +
> > + for (i = 0; i < MAX_COMBINED_ATOMIC_BUFFERS; i++) {
> > + _mesa_reference_buffer_object(ctx,
> > +
> &ctx->AtomicBufferBindings[i].BufferObject,
> > + NULL);
> > + }
> > +
> > }
> >
> > bool
> > @@ -1200,6 +1220,17 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint *ids)
> > _mesa_BindBuffer( GL_UNIFORM_BUFFER, 0 );
> > }
> >
> > + /* unbind Atomci Buffer binding points */
>
> Atomic
>
--
Regards,
*Aditya Atluri,*
*USA.*
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On 22/07/14 19:43, Dylan Baker wrote:
> GBM_DRIVERS_PATH is not documented, and only used to set the location of
> gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and
> is documented.
>
> Generally this split leads to confusion as to why gbm doesn't work.
>
> This patch makes LIBGL_DRIVERS_PATH the main variable, but uses
> GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL.
>
Dylan if we're going the LIBGL road, can we please use the GBM variable first
and then fallback to the LIBGL one ? This way things won't break for people
using the former. Meanwhile I'm writing docs/gbm.html with some rough
description what gbm is and all the env vars used :-)
git grep -i gbm -- docs/
0 matches found
Thanks
Emil
> v2: - Use GBM_DRIVERS_PATH as a fallback
>
> Signed-off-by: Dylan Baker
> ---
> src/gbm/backends/dri/gbm_dri.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index 347bc99..3e4851c 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -211,9 +211,16 @@ dri_load_driver(struct gbm_dri_device *dri)
> char *get_extensions_name;
>
> search_paths = NULL;
> + /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
> if (geteuid() == getuid()) {
> - /* don't allow setuid apps to use GBM_DRIVERS_PATH */
> - search_paths = getenv("GBM_DRIVERS_PATH");
> + search_paths = getenv("LIBGL_DRIVERS_PATH");
> +
> + /* fallback path for compatability, GBM_DRIVERS_PATH should be
> + * dropped eventually
> + */
> + if (search_paths == NULL) {
> + search_paths = getenv("GBM_DRIVERS_PATH");
> + }
> }
> if (search_paths == NULL)
>search_paths = DEFAULT_DRIVER_DIR;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] main/mesa: missing atomic buffer bindings to mesa are added in this patch
The commit message should be something like
"mesa: Add missing atomic buffer bindings and unbindings."
On Thu, Jul 24, 2014 at 12:18 PM, Aditya Atluri
wrote:
> ---
> src/mesa/main/bufferobj.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index 7b1bba0..1dfcda3 100644
> --- a/src/mesa/main/bufferobj.c
> +++ b/src/mesa/main/bufferobj.c
> @@ -832,6 +832,9 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
> _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer,
> ctx->Shared->NullBufferObj);
>
> + _mesa_reference_buffer_object(ctx, &ctx->AtomicBuffer,
> +ctx->Shared->NullBufferObj);
> +
> _mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer,
> ctx->Shared->NullBufferObj);
>
> @@ -842,6 +845,14 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
>ctx->UniformBufferBindings[i].Offset = -1;
>ctx->UniformBufferBindings[i].Size = -1;
> }
> +
> + for (i = 0; i < MAX_COMBINED_ATOMIC_BUFFERS; i++) {
> + _mesa_reference_buffer_object(ctx,
> +
> &ctx->AtomicBufferBindings[i].BufferObject,
> + ctx->Shared->NullBufferObj);
> + ctx->AtomicBufferBindings[i].Offset = -1;
> + ctx->AtomicBufferBindings[i].Size = -1;
> + }
> }
>
>
> @@ -857,6 +868,8 @@ _mesa_free_buffer_objects( struct gl_context *ctx )
>
> _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer, NULL);
>
> + _mesa_reference_buffer_object(ctx, &ctx->AtomicBuffer, NULL);
> +
> _mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer, NULL);
>
> for (i = 0; i < MAX_COMBINED_UNIFORM_BUFFERS; i++) {
> @@ -864,6 +877,13 @@ _mesa_free_buffer_objects( struct gl_context *ctx )
>
> &ctx->UniformBufferBindings[i].BufferObject,
> NULL);
> }
> +
> + for (i = 0; i < MAX_COMBINED_ATOMIC_BUFFERS; i++) {
> + _mesa_reference_buffer_object(ctx,
> +
> &ctx->AtomicBufferBindings[i].BufferObject,
> + NULL);
> + }
> +
> }
>
> bool
> @@ -1200,6 +1220,17 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint *ids)
> _mesa_BindBuffer( GL_UNIFORM_BUFFER, 0 );
> }
>
> + /* unbind Atomci Buffer binding points */
Atomic
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] main/mesa: missing atomic buffer bindings to mesa are added in this patch
---
src/mesa/main/bufferobj.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 7b1bba0..1dfcda3 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -832,6 +832,9 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
_mesa_reference_buffer_object(ctx, &ctx->UniformBuffer,
ctx->Shared->NullBufferObj);
+ _mesa_reference_buffer_object(ctx, &ctx->AtomicBuffer,
+ctx->Shared->NullBufferObj);
+
_mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer,
ctx->Shared->NullBufferObj);
@@ -842,6 +845,14 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
ctx->UniformBufferBindings[i].Offset = -1;
ctx->UniformBufferBindings[i].Size = -1;
}
+
+ for (i = 0; i < MAX_COMBINED_ATOMIC_BUFFERS; i++) {
+ _mesa_reference_buffer_object(ctx,
+ &ctx->AtomicBufferBindings[i].BufferObject,
+ ctx->Shared->NullBufferObj);
+ ctx->AtomicBufferBindings[i].Offset = -1;
+ ctx->AtomicBufferBindings[i].Size = -1;
+ }
}
@@ -857,6 +868,8 @@ _mesa_free_buffer_objects( struct gl_context *ctx )
_mesa_reference_buffer_object(ctx, &ctx->UniformBuffer, NULL);
+ _mesa_reference_buffer_object(ctx, &ctx->AtomicBuffer, NULL);
+
_mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer, NULL);
for (i = 0; i < MAX_COMBINED_UNIFORM_BUFFERS; i++) {
@@ -864,6 +877,13 @@ _mesa_free_buffer_objects( struct gl_context *ctx )
&ctx->UniformBufferBindings[i].BufferObject,
NULL);
}
+
+ for (i = 0; i < MAX_COMBINED_ATOMIC_BUFFERS; i++) {
+ _mesa_reference_buffer_object(ctx,
+ &ctx->AtomicBufferBindings[i].BufferObject,
+ NULL);
+ }
+
}
bool
@@ -1200,6 +1220,17 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint *ids)
_mesa_BindBuffer( GL_UNIFORM_BUFFER, 0 );
}
+ /* unbind Atomci Buffer binding points */
+ for (j = 0; j < ctx->Const.MaxAtomicBufferBindings; j++) {
+if (ctx->AtomicBufferBindings[j].BufferObject == bufObj) {
+ _mesa_BindBufferBase( GL_ATOMIC_COUNTER_BUFFER, j, 0 );
+}
+ }
+
+ if (ctx->UniformBuffer == bufObj) {
+_mesa_BindBuffer( GL_ATOMIC_COUNTER_BUFFER, 0 );
+ }
+
/* unbind any pixel pack/unpack pointers bound to this buffer */
if (ctx->Pack.BufferObj == bufObj) {
_mesa_BindBuffer( GL_PIXEL_PACK_BUFFER_EXT, 0 );
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: rename shader cap MAX_CONSTS to MAX_CONST_BUFFER_SIZE
From: Marek Olšák
This new name isn't so confusing.
I also changed the gallivm limit, because it looked wrong.
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h | 4 ++--
src/gallium/auxiliary/tgsi/tgsi_exec.h| 8
src/gallium/auxiliary/util/u_caps.c | 4 ++--
src/gallium/docs/source/screen.rst| 2 +-
src/gallium/drivers/freedreno/freedreno_screen.c | 4 ++--
src/gallium/drivers/i915/i915_screen.c| 4 ++--
src/gallium/drivers/ilo/ilo_screen.c | 4 ++--
src/gallium/drivers/nouveau/nv30/nv30_screen.c| 8
src/gallium/drivers/nouveau/nv50/nv50_screen.c| 4 ++--
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 4 ++--
src/gallium/drivers/r300/r300_screen.c| 8
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_pipe.h | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c| 4 ++--
src/gallium/drivers/svga/svga_screen.c| 8
src/gallium/include/pipe/p_defines.h | 2 +-
src/gallium/state_trackers/clover/core/device.cpp | 2 +-
src/mesa/state_tracker/st_extensions.c| 5 +++--
18 files changed, 40 insertions(+), 39 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
index 9ccaf46..0b72dd0 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
@@ -97,8 +97,8 @@ gallivm_get_shader_param(enum pipe_shader_cap param)
return LP_MAX_TGSI_NESTING;
case PIPE_SHADER_CAP_MAX_INPUTS:
return PIPE_MAX_SHADER_INPUTS;
- case PIPE_SHADER_CAP_MAX_CONSTS:
- return 16 * 2024;
+ case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE:
+ return 16 * 4096;
case PIPE_SHADER_CAP_MAX_CONST_BUFFERS:
return PIPE_MAX_CONSTANT_BUFFERS;
case PIPE_SHADER_CAP_MAX_TEMPS:
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h
b/src/gallium/auxiliary/tgsi/tgsi_exec.h
index 56a7034..07c96b2 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
@@ -215,9 +215,9 @@ struct tgsi_sampler
*/
#define TGSI_EXEC_MAX_INPUT_ATTRIBS PIPE_MAX_SHADER_INPUTS
-/* The maximum number of constant vectors per constant buffer.
+/* The maximum number of bytes per constant buffer.
*/
-#define TGSI_EXEC_MAX_CONST_BUFFER 4096
+#define TGSI_EXEC_MAX_CONST_BUFFER_SIZE (4096 * 16)
/* The maximum number of vertices per primitive */
#define TGSI_MAX_PRIM_VERTICES 6
@@ -427,8 +427,8 @@ tgsi_exec_get_shader_param(enum pipe_shader_cap param)
return TGSI_EXEC_MAX_NESTING;
case PIPE_SHADER_CAP_MAX_INPUTS:
return TGSI_EXEC_MAX_INPUT_ATTRIBS;
- case PIPE_SHADER_CAP_MAX_CONSTS:
- return TGSI_EXEC_MAX_CONST_BUFFER;
+ case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE:
+ return TGSI_EXEC_MAX_CONST_BUFFER_SIZE;
case PIPE_SHADER_CAP_MAX_CONST_BUFFERS:
return PIPE_MAX_CONSTANT_BUFFERS;
case PIPE_SHADER_CAP_MAX_TEMPS:
diff --git a/src/gallium/auxiliary/util/u_caps.c
b/src/gallium/auxiliary/util/u_caps.c
index 6230707..ec8938b 100644
--- a/src/gallium/auxiliary/util/u_caps.c
+++ b/src/gallium/auxiliary/util/u_caps.c
@@ -198,13 +198,13 @@ static unsigned caps_sm3[] = {
UTIL_CHECK_SHADER(FRAGMENT, MAX_INPUTS, 10),
UTIL_CHECK_SHADER(FRAGMENT, MAX_TEMPS, 32),
UTIL_CHECK_SHADER(FRAGMENT, MAX_ADDRS, 1),
-UTIL_CHECK_SHADER(FRAGMENT, MAX_CONSTS, 224),
+UTIL_CHECK_SHADER(FRAGMENT, MAX_CONST_BUFFER_SIZE, 224 * 16),
UTIL_CHECK_SHADER(VERTEX, MAX_INSTRUCTIONS, 512),
UTIL_CHECK_SHADER(VERTEX, MAX_INPUTS, 16),
UTIL_CHECK_SHADER(VERTEX, MAX_TEMPS, 32),
UTIL_CHECK_SHADER(VERTEX, MAX_ADDRS, 2),
-UTIL_CHECK_SHADER(VERTEX, MAX_CONSTS, 256),
+UTIL_CHECK_SHADER(VERTEX, MAX_CONST_BUFFER_SIZE, 256 * 16),
UTIL_CHECK_TERMINATE
};
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index ba583fe..bdc23f7 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -250,7 +250,7 @@ support different features.
* ``PIPE_SHADER_CAP_MAX_TEX_INDIRECTIONS``: The maximum number of texture
indirections.
* ``PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH``: The maximum nested control flow
depth.
* ``PIPE_SHADER_CAP_MAX_INPUTS``: The maximum number of input registers.
-* ``PIPE_SHADER_CAP_MAX_CONSTS``: The maximum number of constants.
+* ``PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE``: The maximum size per constant
buffer in bytes.
* ``PIPE_SHADER_CAP_MAX_CONST_BUFFERS``: Maximum number of constant buffers
that can be bound
to any shader stage using ``set_constant_buffer``. If 0 or 1, the pipe will
only permit binding one constant buffer per shader, and the shaders will
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
index c574cb8..4c82713 100644
--- a/src/gallium/drivers/fre
Re: [Mesa-dev] [PATCH 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead
On 07/24/2014 07:50 PM, Emil Velikov wrote:
> On 24/07/14 17:07, Matt Turner wrote:
>> On Thu, Jul 24, 2014 at 5:44 AM, Emil Velikov
>> wrote:
>>> On 23/07/14 22:16, Ian Romanick wrote:
On 07/22/2014 02:07 PM, Alon Levy wrote:
> Signed-off-by: Alon Levy
> ---
> src/glsl/glsl_parser.yy | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
> index faaf438..25370cd 100644
> --- a/src/glsl/glsl_parser.yy
> +++ b/src/glsl/glsl_parser.yy
> @@ -26,6 +26,10 @@
> #include
> #include
>
> +#ifdef _MSC_VER <= 1800
> +#define strcasecmp _stricmp
> +#endif
> +
glsl_parser.yy should already get the strcasecmp work around from
src/mesa/main/imports.h.
>>> Just a general question - wouldn't it be better if we move some/all these
>>> quirks around the POSIX standard(s) into a header similar to c99_compat ?
>>> ...
>>> before the amount of duplication gets out of hand.
>>
>> Sounds like a good idea to me, although I don't think strcasecmp is part of
>> C99.
>>
> You're absolutely correct. I was thinking about posix_compat.h ("header
> similar to c99_compat") where he can put all the quirks needed for non POSIX
> compliant setups. Unfortunately I don't think I have the time for this atm.
>
> -Emil
>
I can make a patch for just this case as a start.. If anyone has some
clues as to the rest of the non posix parts and how to test that I'm not
screwing anything up I can go for a fuller patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE
On Thu, Jul 24, 2014 at 12:05 PM, Jan Vesely wrote: > > On Thu, 2014-07-24 at 17:07 +0200, Marek Olšák wrote: >> Sorry, GL 3.1 actually only requires 1024 vec4s. The UBO extension >> spec contains a mistake. >> >> Marek >> >> On Thu, Jul 24, 2014 at 4:55 PM, Marek Olšák wrote: >> > OpenGL 3.1 requires 4096 vec4s (65536 bytes) per constant buffer and >> > the hardware supports 16 constant buffers. I'm not sure what the >> > "constant registers" are, but they cannot have anything to do with the >> > constant buffer limit, because otherwise we wouldn't be able to meet >> > the requirement for uniform buffer objects. > > Hm, it's rather confusing. > ch. 2.5 describes 512 128bit Constant Registers (W by host R by GPU) in ALU > state. > section 4.6.4 mentions that there are 256 128-bit constants (in constant > file) available in DX9 mode, > and 1-4096 128bit in memory constants in dx10 mode. (I guess that's where the > 4096 value comes from) > > Then there's constant cache of 64 128 bit constants, which uses the CR > mentioned above, > and I believe is used to pass kernel arguments by clover. VLIW4/5 asic also have a kcache which is basically a small cache for access to a subset of the memory backed DX10 constant buffer. > > I know little about OpenGL, what are these different ways to do the same > thing good for? There's not really different ways. On r6xx/r7xx there was an on-chip buffer (CFILE) were you could write constants since DX9 had a fixed size constant file. Storing them in sram on-chip is fast, but takes die space. With DX10, constants were stored in memory. From evergreen going forward, the hardware only supports DX10 style memory backed constant buffers. So if you take the CFILE out of the picture, there's only one way to access constant buffers. Alex > > thanks > Jan > >> > >> > Marek >> > >> > On Thu, Jul 24, 2014 at 4:05 PM, Jan Vesely wrote: >> >> On Thu, 2014-07-24 at 06:35 -0700, Tom Stellard wrote: >> >>> On Thu, Jul 24, 2014 at 01:09:49PM +0200, Marek Olšák wrote: >> >>> > Isn't this redundant with get_shader_param(PIPE_SHADER_COMPUTE, >> >>> > PIPE_SHADER_CAP_MAX_CONSTS) * 16? >> >>> > >> >>> >> >>> This is what clover was using, but I was confused about what the value >> >>> was supposed to represent. Now, I think I understand (number of 4 x >> >>> 32-bit >> >>> constants). I can use this instead. >> >> >> >> Is the value for r600 hw misreported then? The manuals for R600/EG/NI >> >> say there are 512 such registers. Yet the driver reports 4096. >> >> See the attached patch. >> >> >> >> Jan >> >> >> >>> >> >>> -Tom >> >>> > Marek >> >>> > >> >>> > On Thu, Jul 24, 2014 at 3:05 AM, Tom Stellard >> >>> > wrote: >> >>> > > --- >> >>> > > src/gallium/docs/source/screen.rst | 2 ++ >> >>> > > src/gallium/include/pipe/p_defines.h | 3 ++- >> >>> > > 2 files changed, 4 insertions(+), 1 deletion(-) >> >>> > > >> >>> > > diff --git a/src/gallium/docs/source/screen.rst >> >>> > > b/src/gallium/docs/source/screen.rst >> >>> > > index 830a1a5..219c9f9 100644 >> >>> > > --- a/src/gallium/docs/source/screen.rst >> >>> > > +++ b/src/gallium/docs/source/screen.rst >> >>> > > @@ -334,6 +334,8 @@ pipe_screen::get_compute_param. >> >>> > >Value type: ``uint32_t`` >> >>> > > * ``PIPE_COMPUTE_CAP_IMAGES_SUPPORTED``: Whether images are >> >>> > > supported >> >>> > >non-zero means yes, zero means no. Value type: ``uint32_t`` >> >>> > > +* ``PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE``: The maximum size >> >>> > > in bytes >> >>> > > + of a constant buffer. Value type: ``uint64_t`` >> >>> > > >> >>> > > .. _pipe_bind: >> >>> > > >> >>> > > diff --git a/src/gallium/include/pipe/p_defines.h >> >>> > > b/src/gallium/include/pipe/p_defines.h >> >>> > > index 43bb1f5..78709b9 100644 >> >>> > > --- a/src/gallium/include/pipe/p_defines.h >> >>> > > +++ b/src/gallium/include/pipe/p_defines.h >> >>> > > @@ -651,7 +651,8 @@ enum pipe_compute_cap >> >>> > > PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE, >> >>> > > PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY, >> >>> > > PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS, >> >>> > > - PIPE_COMPUTE_CAP_IMAGES_SUPPORTED >> >>> > > + PIPE_COMPUTE_CAP_IMAGES_SUPPORTED, >> >>> > > + PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE >> >>> > > }; >> >>> > > >> >>> > > /** >> >>> > > -- >> >>> > > 1.8.1.5 >> >>> > > >> >>> > > ___ >> >>> > > 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 mailing list >> >>> mesa-dev@lists.freedesktop.org >> >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> >> >> >> -- >> >> Jan Vesely > > -- > Jan Vesely > > -- > Jan Vesely > > ___
Re: [Mesa-dev] [PATCH 1/2] i965: Viewport extents on gen8
On Thu, Jul 24, 2014 at 10:22:25AM -0700, Ben Widawsky wrote:
> On Thu, Jul 24, 2014 at 10:29:11AM +0300, Pohjolainen, Topi wrote:
> > On Thu, Jul 03, 2014 at 11:23:13AM -0700, Ben Widawsky wrote:
> > > Viewport extents are a 3rd rectangle that defines which pixels get
> > > discarded as part of the rasterization process. This can potentially
> > > improve performance by reducing cache usage, and freeing up PS cycles.
> > > This will get hit if one's viewport is smaller than the full
> > > renderbuffer, and scissoring is not used.
> > >
> > > The functionality itself very much resembles scissoring.
> > > ---
> > > src/mesa/drivers/dri/i965/gen8_viewport_state.c | 24
> > > +++-
> > > 1 file changed, 15 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> > > b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> > > index b366246..2bf5fbb 100644
> > > --- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> > > +++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> > > @@ -86,17 +86,23 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
> > >vp[10] = -gby; /* y-min */
> > >vp[11] = gby; /* y-max */
> > >
> > > - /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space
> > > Viewport */
> > > + /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space
> > > Viewport
> > > + * The hardware will take the intersection of the drawing
> > > rectangle,
> > > + * scissor rectangle, and the viewport extents. We don't need to be
> > > + * smart, and can therefore just program the viewport extents.
> > > + */
> > > + float viewport_Xmax = ctx->ViewportArray[i].X +
> > > ctx->ViewportArray[i].Width;
> > > + float viewport_Ymax = ctx->ViewportArray[i].Y +
> > > ctx->ViewportArray[i].Height;
> >
> > These could be both declared as constants and the right hand sides should go
> > to their own lines as they are now overflowing the 80-char limit.
>
> Got it.
>
> >
> > Otherwise this looks to me as the right thing to do, and not only from
> > performance point of view. I'm thinking a case where the limits for the
> > drawbuffer are not set but where the viewport limits are - with the current
> > logic we wouldn't apply the limits, right? I guess we don't have any such
> > piglit test case.
>
> I'm new here. I don't understand. Can you explain what you mean by
> drawbuffer limits not being set set? I wasn't really aware such a thing
> was possible (if I followed your meaning).
I'm asking for the same reason, I don't know how these things are set in the
core. I meant the DrawBuffer::_Xmin/Xmax/Ymin/Ymax. So I'm thinking a case
where DrawBuffer::_Xmin/Xmax/Ymin/Ymax do not impose any limits but where
ViewportArray[] do. Current logic wouldn't take them into account but your
version would.
But then on the other hand after your change I don't see how the constraints
in DrawBuffer::_Xmin/Xmax/Ymin/Ymax would be taken into account.
>
> >
> > But then I also realized that if we applied this, then gen8 wouldn't take
> > the
> > drawbuffer limits into account anywhere else. So this should break some
> > piglit
> > tests?
>
> I didn't run full, but quick didn't have any regressions.
>
> >
> > I tried to look at the earlier generations from six onwards and actually
> > couldn't find any state atom using the drawbuffer limits. (The only
> > reference
> > is SF-scissor setting in brw_sf_state.c:upload_sf_vp() which is for gen <
> > 6).
> > I guess I can say I'm confused.
> >
> > >if (render_to_fbo) {
> > > - vp[12] = ctx->DrawBuffer->_Xmin;
> > > - vp[13] = ctx->DrawBuffer->_Xmax - 1;
> > > - vp[14] = ctx->DrawBuffer->_Ymin;
> > > - vp[15] = ctx->DrawBuffer->_Ymax - 1;
> > > + vp[12] = ctx->ViewportArray[i].X;
> > > + vp[13] = viewport_Xmax - 1;
> > > + vp[14] = ctx->ViewportArray[i].Y;
> > > + vp[15] = viewport_Ymax - 1;
> > >} else {
> > > - vp[12] = ctx->DrawBuffer->_Xmin;
> > > - vp[13] = ctx->DrawBuffer->_Xmax - 1;
> > > - vp[14] = ctx->DrawBuffer->Height - ctx->DrawBuffer->_Ymax;
> > > - vp[15] = ctx->DrawBuffer->Height - ctx->DrawBuffer->_Ymin - 1;
> > > + vp[12] = ctx->ViewportArray[i].X;
> > > + vp[13] = viewport_Xmax - 1;
> > > + vp[14] = ctx->DrawBuffer->Height - viewport_Ymax;
> > > + vp[15] = ctx->DrawBuffer->Height - ctx->ViewportArray[i].Y - 1;
> > >}
> > >
> > >vp += 16;
>
> I'll take a look, but Ken may have a more immediate answer. I was
> distracted by other things for the 3 weeks, but I am back looking at
> this now (and the GB clipping as well). My quick answer is that hardware
> will just do the right thing (I only looked at GEN8), but I need to read
> the docs further.
>
> I've yet to find a perf win, though some benchmarks do hit this path.
> I'll do some more piglit testing as well, a
[Mesa-dev] [PATCH] r600g: switch SNORM conversion to DX and GLES behavior
From: Marek Olšák it also matches GL 4.2 further discussion: http://lists.freedesktop.org/archives/mesa-dev/2013-August/042680.html --- src/gallium/drivers/r600/evergreen_state.c | 2 -- src/gallium/drivers/r600/r600_asm.c| 1 - src/gallium/drivers/r600/r600_shader.c | 2 -- src/gallium/drivers/r600/r600_state.c | 2 -- 4 files changed, 7 deletions(-) diff --git a/src/gallium/drivers/r600/evergreen_state.c b/src/gallium/drivers/r600/evergreen_state.c index 9688b5e..005184d 100644 --- a/src/gallium/drivers/r600/evergreen_state.c +++ b/src/gallium/drivers/r600/evergreen_state.c @@ -635,7 +635,6 @@ texture_buffer_sampler_view(struct r600_pipe_sampler_view *view, S_030008_DATA_FORMAT(format) | S_030008_NUM_FORMAT_ALL(num_format) | S_030008_FORMAT_COMP_ALL(format_comp) | - S_030008_SRF_MODE_ALL(1) | S_030008_ENDIAN_SWAP(endian); view->tex_resource_words[3] = swizzle_res; /* @@ -814,7 +813,6 @@ evergreen_create_sampler_view_custom(struct pipe_context *ctx, } view->tex_resource_words[4] = (word4 | - S_030010_SRF_MODE_ALL(V_030010_SRF_MODE_ZERO_CLAMP_MINUS_ONE) | S_030010_ENDIAN_SWAP(endian)); view->tex_resource_words[5] = S_030014_BASE_ARRAY(state->u.tex.first_layer) | S_030014_LAST_ARRAY(state->u.tex.last_layer); diff --git a/src/gallium/drivers/r600/r600_asm.c b/src/gallium/drivers/r600/r600_asm.c index e75f7d6..4da918c 100644 --- a/src/gallium/drivers/r600/r600_asm.c +++ b/src/gallium/drivers/r600/r600_asm.c @@ -2375,7 +2375,6 @@ void *r600_create_vertex_fetch_shader(struct pipe_context *ctx, vtx.data_format = format; vtx.num_format_all = num_format; vtx.format_comp_all = format_comp; - vtx.srf_mode_all = 1; vtx.offset = elements[i].src_offset; vtx.endian = endian; diff --git a/src/gallium/drivers/r600/r600_shader.c b/src/gallium/drivers/r600/r600_shader.c index db928f3..0dfb58d 100644 --- a/src/gallium/drivers/r600/r600_shader.c +++ b/src/gallium/drivers/r600/r600_shader.c @@ -854,7 +854,6 @@ static int tgsi_fetch_rel_const(struct r600_shader_ctx *ctx, vtx.data_format = FMT_32_32_32_32_FLOAT; vtx.num_format_all = 2; /* NUM_FORMAT_SCALED */ vtx.format_comp_all = 1;/* FORMAT_COMP_SIGNED */ - vtx.srf_mode_all = 1; /* SRF_MODE_NO_ZERO */ vtx.endian = r600_endian_swap(32); if ((r = r600_bytecode_add_vtx(ctx->bc, &vtx))) @@ -4354,7 +4353,6 @@ static int do_vtx_fetch_inst(struct r600_shader_ctx *ctx, boolean src_requires_l vtx.dst_sel_z = (inst->Dst[0].Register.WriteMask & 4) ? 2 : 7; /* SEL_Z */ vtx.dst_sel_w = (inst->Dst[0].Register.WriteMask & 8) ? 3 : 7; /* SEL_W */ vtx.use_const_fields = 1; - vtx.srf_mode_all = 1; /* SRF_MODE_NO_ZERO */ if ((r = r600_bytecode_add_vtx(ctx->bc, &vtx))) return r; diff --git a/src/gallium/drivers/r600/r600_state.c b/src/gallium/drivers/r600/r600_state.c index 9e7a8e9..70bb370 100644 --- a/src/gallium/drivers/r600/r600_state.c +++ b/src/gallium/drivers/r600/r600_state.c @@ -618,7 +618,6 @@ texture_buffer_sampler_view(struct r600_pipe_sampler_view *view, S_038008_DATA_FORMAT(format) | S_038008_NUM_FORMAT_ALL(num_format) | S_038008_FORMAT_COMP_ALL(format_comp) | - S_038008_SRF_MODE_ALL(1) | S_038008_ENDIAN_SWAP(endian); view->tex_resource_words[3] = 0; /* @@ -729,7 +728,6 @@ r600_create_sampler_view_custom(struct pipe_context *ctx, view->tex_resource_words[3] = tmp->surface.level[offset_level + 1].offset >> 8; } view->tex_resource_words[4] = (word4 | - S_038010_SRF_MODE_ALL(V_038010_SRF_MODE_ZERO_CLAMP_MINUS_ONE) | S_038010_REQUEST_SIZE(1) | S_038010_ENDIAN_SWAP(endian) | S_038010_BASE_LEVEL(0)); -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Add support for BPTC texture compression
On Thu, Jul 24, 2014 at 8:55 AM, Neil Roberts wrote: > Ilia Mirkin writes: > >> Just a thought -- if online compression is highly unexpected, perhaps >> it'd be reasonably to make a *horrid* compressor that doesn't rely on >> any external libraries? I don't know how complex the BPTC format is, >> but I suspect it may be possible to do a simple conversion that does >> ~0 compression (and may actually make things larger). > > The compression ratio is fixed so the only variable is the quality of > the image. I did make a naïve compressor for the RGBA UNORM format but I > opted for the approach going via DXT3 instead because it looks nicer. I > later modified that compressor to work for the half-float formats > because we can't use DXT3 there. If we did want to avoid any > dependencies and we don't care about the quality then that naïve > compressor could still be an viable approach. Here's an example of the > quality: > > http://busydoingnothing.co.uk/doge/ That's a great reference image. Do you have a version of the image compressed with nVidias online compressor? Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Viewport extents on gen8
On Thu, Jul 24, 2014 at 10:29:11AM +0300, Pohjolainen, Topi wrote:
> On Thu, Jul 03, 2014 at 11:23:13AM -0700, Ben Widawsky wrote:
> > Viewport extents are a 3rd rectangle that defines which pixels get
> > discarded as part of the rasterization process. This can potentially
> > improve performance by reducing cache usage, and freeing up PS cycles.
> > This will get hit if one's viewport is smaller than the full
> > renderbuffer, and scissoring is not used.
> >
> > The functionality itself very much resembles scissoring.
> > ---
> > src/mesa/drivers/dri/i965/gen8_viewport_state.c | 24
> > +++-
> > 1 file changed, 15 insertions(+), 9 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> > b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> > index b366246..2bf5fbb 100644
> > --- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> > +++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c
> > @@ -86,17 +86,23 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw)
> >vp[10] = -gby; /* y-min */
> >vp[11] = gby; /* y-max */
> >
> > - /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space
> > Viewport */
> > + /* _NEW_SCISSOR | _NEW_VIEWPORT | _NEW_BUFFERS: Screen Space Viewport
> > + * The hardware will take the intersection of the drawing rectangle,
> > + * scissor rectangle, and the viewport extents. We don't need to be
> > + * smart, and can therefore just program the viewport extents.
> > + */
> > + float viewport_Xmax = ctx->ViewportArray[i].X +
> > ctx->ViewportArray[i].Width;
> > + float viewport_Ymax = ctx->ViewportArray[i].Y +
> > ctx->ViewportArray[i].Height;
>
> These could be both declared as constants and the right hand sides should go
> to their own lines as they are now overflowing the 80-char limit.
Got it.
>
> Otherwise this looks to me as the right thing to do, and not only from
> performance point of view. I'm thinking a case where the limits for the
> drawbuffer are not set but where the viewport limits are - with the current
> logic we wouldn't apply the limits, right? I guess we don't have any such
> piglit test case.
I'm new here. I don't understand. Can you explain what you mean by
drawbuffer limits not being set set? I wasn't really aware such a thing
was possible (if I followed your meaning).
>
> But then I also realized that if we applied this, then gen8 wouldn't take the
> drawbuffer limits into account anywhere else. So this should break some piglit
> tests?
I didn't run full, but quick didn't have any regressions.
>
> I tried to look at the earlier generations from six onwards and actually
> couldn't find any state atom using the drawbuffer limits. (The only reference
> is SF-scissor setting in brw_sf_state.c:upload_sf_vp() which is for gen < 6).
> I guess I can say I'm confused.
>
> >if (render_to_fbo) {
> > - vp[12] = ctx->DrawBuffer->_Xmin;
> > - vp[13] = ctx->DrawBuffer->_Xmax - 1;
> > - vp[14] = ctx->DrawBuffer->_Ymin;
> > - vp[15] = ctx->DrawBuffer->_Ymax - 1;
> > + vp[12] = ctx->ViewportArray[i].X;
> > + vp[13] = viewport_Xmax - 1;
> > + vp[14] = ctx->ViewportArray[i].Y;
> > + vp[15] = viewport_Ymax - 1;
> >} else {
> > - vp[12] = ctx->DrawBuffer->_Xmin;
> > - vp[13] = ctx->DrawBuffer->_Xmax - 1;
> > - vp[14] = ctx->DrawBuffer->Height - ctx->DrawBuffer->_Ymax;
> > - vp[15] = ctx->DrawBuffer->Height - ctx->DrawBuffer->_Ymin - 1;
> > + vp[12] = ctx->ViewportArray[i].X;
> > + vp[13] = viewport_Xmax - 1;
> > + vp[14] = ctx->DrawBuffer->Height - viewport_Ymax;
> > + vp[15] = ctx->DrawBuffer->Height - ctx->ViewportArray[i].Y - 1;
> >}
> >
> >vp += 16;
I'll take a look, but Ken may have a more immediate answer. I was
distracted by other things for the 3 weeks, but I am back looking at
this now (and the GB clipping as well). My quick answer is that hardware
will just do the right thing (I only looked at GEN8), but I need to read
the docs further.
I've yet to find a perf win, though some benchmarks do hit this path.
I'll do some more piglit testing as well, and update with that info.
--
Ben Widawsky, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/gallium: implemlent EGL_KHR_create_context v3
On Fri, Jun 27, 2014 at 1:59 AM, Knut Andre Tidemann
wrote:
> v2: fix style and wrong major version comparison.
> v3: fix version check in context creation.
> ---
> src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
> src/gallium/state_trackers/egl/common/egl_g3d_api.c | 12
> 2 files changed, 13 insertions(+)
>
> diff --git a/src/gallium/state_trackers/egl/common/egl_g3d.c
> b/src/gallium/state_trackers/egl/common/egl_g3d.c
> index d3f5e92..22b5e4a 100644
> --- a/src/gallium/state_trackers/egl/common/egl_g3d.c
> +++ b/src/gallium/state_trackers/egl/common/egl_g3d.c
> @@ -584,6 +584,7 @@ egl_g3d_initialize(_EGLDriver *drv, _EGLDisplay *dpy)
> dpy->Extensions.KHR_fence_sync = EGL_TRUE;
>
> dpy->Extensions.KHR_surfaceless_context = EGL_TRUE;
> + dpy->Extensions.KHR_create_context = EGL_TRUE;
>
> if (dpy->Platform == _EGL_PLATFORM_DRM) {
>dpy->Extensions.MESA_drm_display = EGL_TRUE;
> diff --git a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
> b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
> index b19d899..5e900cc 100644
> --- a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
> +++ b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
> @@ -72,6 +72,11 @@ egl_g3d_choose_st(_EGLDriver *drv, _EGLContext *ctx,
>break;
> case EGL_OPENGL_API:
>api = ST_API_OPENGL;
> + if (((ctx->ClientMajorVersion >= 4) ||
> +(ctx->ClientMajorVersion == 3 && ctx->ClientMinorVersion >= 2))
> &&
> +ctx->Profile == EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR) {
> + *profile = ST_PROFILE_OPENGL_CORE;
> + }
What if you only specify the core profile bit without specifying a version?
I don't know that you're required to specify a version to get a core
profile. The default major/minor versions are 1/0 and the default
profile mask is core, so it seems like that should give you a core
context by default. Maybe we're missing a test for this.
>break;
> default:
>_eglLog(_EGL_WARNING, "unknown client API 0x%04x", ctx->ClientAPI);
> @@ -166,6 +171,12 @@ egl_g3d_create_context(_EGLDriver *drv, _EGLDisplay
> *dpy, _EGLConfig *conf,
> if (gconf)
>stattribs.visual = gconf->stvis;
>
> + if (gctx->base.Flags & EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR)
> + stattribs.flags = ST_CONTEXT_FLAG_DEBUG;
Need to handle EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR and
EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR here too?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/gallium: implemlent EGL_KHR_create_context v3
On Thu, Jul 24, 2014 at 5:37 AM, Knut Andre Tidemann
wrote:
> On 06/27/2014 10:59 AM, Knut Andre Tidemann wrote:
>>
>> v2: fix style and wrong major version comparison.
>> v3: fix version check in context creation.
>> ---
>> src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
>> src/gallium/state_trackers/egl/common/egl_g3d_api.c | 12
>> 2 files changed, 13 insertions(+)
>>
>> diff --git a/src/gallium/state_trackers/egl/common/egl_g3d.c
>> b/src/gallium/state_trackers/egl/common/egl_g3d.c
>> index d3f5e92..22b5e4a 100644
>> --- a/src/gallium/state_trackers/egl/common/egl_g3d.c
>> +++ b/src/gallium/state_trackers/egl/common/egl_g3d.c
>> @@ -584,6 +584,7 @@ egl_g3d_initialize(_EGLDriver *drv, _EGLDisplay *dpy)
>> dpy->Extensions.KHR_fence_sync = EGL_TRUE;
>>
>> dpy->Extensions.KHR_surfaceless_context = EGL_TRUE;
>> + dpy->Extensions.KHR_create_context = EGL_TRUE;
>>
>> if (dpy->Platform == _EGL_PLATFORM_DRM) {
>> dpy->Extensions.MESA_drm_display = EGL_TRUE;
>> diff --git a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
>> b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
>> index b19d899..5e900cc 100644
>> --- a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
>> +++ b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
>> @@ -72,6 +72,11 @@ egl_g3d_choose_st(_EGLDriver *drv, _EGLContext *ctx,
>> break;
>> case EGL_OPENGL_API:
>> api = ST_API_OPENGL;
>> + if (((ctx->ClientMajorVersion >= 4) ||
>> +(ctx->ClientMajorVersion == 3 && ctx->ClientMinorVersion >=
>> 2)) &&
>> +ctx->Profile == EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR) {
>> + *profile = ST_PROFILE_OPENGL_CORE;
>> + }
>> break;
>> default:
>> _eglLog(_EGL_WARNING, "unknown client API 0x%04x",
>> ctx->ClientAPI);
>> @@ -166,6 +171,12 @@ egl_g3d_create_context(_EGLDriver *drv, _EGLDisplay
>> *dpy, _EGLConfig *conf,
>> if (gconf)
>> stattribs.visual = gconf->stvis;
>>
>> + if (gctx->base.Flags & EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR)
>> + stattribs.flags = ST_CONTEXT_FLAG_DEBUG;
>> +
>> + stattribs.major = gctx->base.ClientMajorVersion;
>> + stattribs.minor = gctx->base.ClientMinorVersion;
>> +
>> gctx->stapi = egl_g3d_choose_st(drv, &gctx->base,
>> &stattribs.profile);
>> if (!gctx->stapi) {
>> FREE(gctx);
>> @@ -175,6 +186,7 @@ egl_g3d_create_context(_EGLDriver *drv, _EGLDisplay
>> *dpy, _EGLConfig *conf,
>> gctx->stctxi = gctx->stapi->create_context(gctx->stapi, gdpy->smapi,
>>&stattribs, &ctx_err, (gshare) ? gshare->stctxi : NULL);
>> if (!gctx->stctxi) {
>> + _eglError(EGL_BAD_MATCH, "eglCreateContext");
>> FREE(gctx);
>> return NULL;
>> }
>>
>
>
> Is there any interest in this? If not I would like to make a feature request
> as it is the only way to create a core context with EGL at the moment.
Yes, unfortunately I don't know the gallium code. I've been hoping a
gallium person would review this, since we really want to tell people
to switch to EGL, but with features like this missing from other
drivers I don't think we can do it with a straight face.
I'll review it as best I can.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead
On 24/07/14 17:07, Matt Turner wrote:
> On Thu, Jul 24, 2014 at 5:44 AM, Emil Velikov
> wrote:
>> On 23/07/14 22:16, Ian Romanick wrote:
>>> On 07/22/2014 02:07 PM, Alon Levy wrote:
Signed-off-by: Alon Levy
---
src/glsl/glsl_parser.yy | 4
1 file changed, 4 insertions(+)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index faaf438..25370cd 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -26,6 +26,10 @@
#include
#include
+#ifdef _MSC_VER <= 1800
+#define strcasecmp _stricmp
+#endif
+
>>>
>>> glsl_parser.yy should already get the strcasecmp work around from
>>> src/mesa/main/imports.h.
>>>
>> Just a general question - wouldn't it be better if we move some/all these
>> quirks around the POSIX standard(s) into a header similar to c99_compat ? ...
>> before the amount of duplication gets out of hand.
>
> Sounds like a good idea to me, although I don't think strcasecmp is part of
> C99.
>
You're absolutely correct. I was thinking about posix_compat.h ("header
similar to c99_compat") where he can put all the quirks needed for non POSIX
compliant setups. Unfortunately I don't think I have the time for this atm.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] Add support for swrast to the DRM EGL platform
On 24/07/14 14:30, Pekka Paalanen wrote:
> On Thu, 24 Jul 2014 13:34:42 +0100
> Emil Velikov wrote:
>
>> On 24/07/14 07:23, Pekka Paalanen wrote:
>>> On Thu, 24 Jul 2014 01:43:35 +0100
>>> Emil Velikov wrote:
>>>
From: Giovanni Campagna
Turn GBM into a swrast loader (providing putimage/getimage backed
by a dumb KMS buffer). This allows to run KMS+DRM GL applications
(such as weston or mutter-wayland) unmodified on cards that don't
have any client side HW acceleration component but that can do
modeset (examples include simpledrm and qxl)
[Emil Velikov]
- Fix make check.
- Split dri_open_driver() from dri_load_driver().
- Don't try to bind the swrast extensions when using dri.
- Handle swrast->CreateNewScreen() failure.
- strdup the driver_name, as it's free'd at destruction.
- s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE/
- Move gbm_dri_bo_map/unmap to gbm_driiint.h.
- Correct swrast fallback logic.
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/platform_drm.c | 153 +++
src/gbm/backends/dri/gbm_dri.c | 203
+++-
src/gbm/backends/dri/gbm_driint.h | 57 +-
src/gbm/gbm-symbols-check | 1 +
src/gbm/main/gbm.h | 3 +
5 files changed, 369 insertions(+), 48 deletions(-)
>>>
diff --git a/src/gbm/backends/dri/gbm_dri.c
b/src/gbm/backends/dri/gbm_dri.c
index 347bc99..1aca506 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
>>>
@@ -743,7 +886,7 @@ static struct gbm_device *
dri_device_create(int fd)
{
struct gbm_dri_device *dri;
- int ret;
+ int ret, force_sw;
dri = calloc(1, sizeof *dri);
if (!dri)
@@ -763,7 +906,15 @@ dri_device_create(int fd)
dri->base.type = GBM_DRM_DRIVER_TYPE_DRI;
dri->base.base.name = "drm";
- ret = dri_screen_create(dri);
+ force_sw = getenv("GBM_ALWAYS_SOFTWARE") != NULL;
+ if (!force_sw) {
+ ret = dri_screen_create(dri);
+ if (ret)
+ ret = dri_screen_create_swrast(dri);
+ } else {
+ ret = dri_screen_create_swrast(dri);
+ }
+
if (ret)
goto err_dri;
>>>
>>> Hi,
>>>
>>> is GBM_ALWAYS_SOFTWARE a new env var?
>>> Is it documented somewhere?
>> None of the GBM env variables are. In a matter of fact there isn't even a
>> single reference of gbm in the docs - env vars or otherwise. It's like gbm
>> does not exist :'(
>>
>> Will need to get a new document out there similar to egl.html.
>> Any objections if we do that as a follow up patch ?
>
> I would be happy to see any documentation at some point. :-)
>
>>> How does it interact with EGL_SOFTWARE?
>>> Does GBM_ALWAYS_SOFTWARE affect GBM's ability to import dmabufs
>>> somehow, or only the surfaces that will be passed to EGL?
>>> (Importing dmabufs to be passed directly to KMS for scanout.)
>>>
>> Considering it's a variable that needs to be explicitly set, the behaviour
>> depends on the current state of the software backend.
>>
>> AFAICS current swrast/kms_swrast does not allow/use dmabufs.
>
> Maybe that was a stupid question on my part, as I don't know
> whether generic DRM API even has a way to import dmabufs at all.
> Something like dumb buffer import...
>
AFAICS one needs to use a device driver capable of handling dmabufs, otherwise
the core drm will return EINVAL/ENOSYS.
I don't see any "software" implementation (dumb buffer) that can be used here.
IMHO all the above should be mentioned somewhere/documented rather than
expecting everything to magically work exactly as you expected it to.
>>> I'm terribly confused with all the *SOFTWARE* variables, and it seems
>>> I'm not alone as someone just recently filed a bunch of Weston bug
>>> reports while trying to get software GL rendering with
>>> LIBGL_ALWAYS_SOFTWARE on DRM/KMS.
>>>
>>>
>> I have the sneaking suspicion that most people see LIBGL_ALWAYS_SOFTWARE as
>> the magic variable that reads your mind and makes things work as you would
>> imagine them. Would be great to move from that to read the documentation and
>> amend propose improvements of it when needed.
>
> Right. What about EGL_SOFTWARE? Why not use that on GBM platform too? A
> quick grep implies that X11 and Wayland platforms use it (but only with
> egl_gallium.so?)?
>
A bit of history - when Chia-I was doing all the EGL work, he was considerable
enough to make individual switches for people to toggle when needed. He also
documented all of these :)
> GBM_ALWAYS_SOFTWARE sounds like a platform-specific variable, but
> should forcing software rendering be platform-specific?
>
GBM is not EGL I fear. Also EGL is not the only user of GBM.
If we were to have zero users of libgbm outside of mesa(libegl) and then w
Re: [Mesa-dev] [PATCH 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead
On Thu, Jul 24, 2014 at 5:44 AM, Emil Velikov wrote: > On 23/07/14 22:16, Ian Romanick wrote: >> On 07/22/2014 02:07 PM, Alon Levy wrote: >>> Signed-off-by: Alon Levy >>> --- >>> src/glsl/glsl_parser.yy | 4 >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy >>> index faaf438..25370cd 100644 >>> --- a/src/glsl/glsl_parser.yy >>> +++ b/src/glsl/glsl_parser.yy >>> @@ -26,6 +26,10 @@ >>> #include >>> #include >>> >>> +#ifdef _MSC_VER <= 1800 >>> +#define strcasecmp _stricmp >>> +#endif >>> + >> >> glsl_parser.yy should already get the strcasecmp work around from >> src/mesa/main/imports.h. >> > Just a general question - wouldn't it be better if we move some/all these > quirks around the POSIX standard(s) into a header similar to c99_compat ? ... > before the amount of duplication gets out of hand. Sounds like a good idea to me, although I don't think strcasecmp is part of C99. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE
On Thu, 2014-07-24 at 17:07 +0200, Marek Olšák wrote: > Sorry, GL 3.1 actually only requires 1024 vec4s. The UBO extension > spec contains a mistake. > > Marek > > On Thu, Jul 24, 2014 at 4:55 PM, Marek Olšák wrote: > > OpenGL 3.1 requires 4096 vec4s (65536 bytes) per constant buffer and > > the hardware supports 16 constant buffers. I'm not sure what the > > "constant registers" are, but they cannot have anything to do with the > > constant buffer limit, because otherwise we wouldn't be able to meet > > the requirement for uniform buffer objects. Hm, it's rather confusing. ch. 2.5 describes 512 128bit Constant Registers (W by host R by GPU) in ALU state. section 4.6.4 mentions that there are 256 128-bit constants (in constant file) available in DX9 mode, and 1-4096 128bit in memory constants in dx10 mode. (I guess that's where the 4096 value comes from) Then there's constant cache of 64 128 bit constants, which uses the CR mentioned above, and I believe is used to pass kernel arguments by clover. I know little about OpenGL, what are these different ways to do the same thing good for? thanks Jan > > > > Marek > > > > On Thu, Jul 24, 2014 at 4:05 PM, Jan Vesely wrote: > >> On Thu, 2014-07-24 at 06:35 -0700, Tom Stellard wrote: > >>> On Thu, Jul 24, 2014 at 01:09:49PM +0200, Marek Olšák wrote: > >>> > Isn't this redundant with get_shader_param(PIPE_SHADER_COMPUTE, > >>> > PIPE_SHADER_CAP_MAX_CONSTS) * 16? > >>> > > >>> > >>> This is what clover was using, but I was confused about what the value > >>> was supposed to represent. Now, I think I understand (number of 4 x > >>> 32-bit > >>> constants). I can use this instead. > >> > >> Is the value for r600 hw misreported then? The manuals for R600/EG/NI > >> say there are 512 such registers. Yet the driver reports 4096. > >> See the attached patch. > >> > >> Jan > >> > >>> > >>> -Tom > >>> > Marek > >>> > > >>> > On Thu, Jul 24, 2014 at 3:05 AM, Tom Stellard > >>> > wrote: > >>> > > --- > >>> > > src/gallium/docs/source/screen.rst | 2 ++ > >>> > > src/gallium/include/pipe/p_defines.h | 3 ++- > >>> > > 2 files changed, 4 insertions(+), 1 deletion(-) > >>> > > > >>> > > diff --git a/src/gallium/docs/source/screen.rst > >>> > > b/src/gallium/docs/source/screen.rst > >>> > > index 830a1a5..219c9f9 100644 > >>> > > --- a/src/gallium/docs/source/screen.rst > >>> > > +++ b/src/gallium/docs/source/screen.rst > >>> > > @@ -334,6 +334,8 @@ pipe_screen::get_compute_param. > >>> > >Value type: ``uint32_t`` > >>> > > * ``PIPE_COMPUTE_CAP_IMAGES_SUPPORTED``: Whether images are supported > >>> > >non-zero means yes, zero means no. Value type: ``uint32_t`` > >>> > > +* ``PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE``: The maximum size in > >>> > > bytes > >>> > > + of a constant buffer. Value type: ``uint64_t`` > >>> > > > >>> > > .. _pipe_bind: > >>> > > > >>> > > diff --git a/src/gallium/include/pipe/p_defines.h > >>> > > b/src/gallium/include/pipe/p_defines.h > >>> > > index 43bb1f5..78709b9 100644 > >>> > > --- a/src/gallium/include/pipe/p_defines.h > >>> > > +++ b/src/gallium/include/pipe/p_defines.h > >>> > > @@ -651,7 +651,8 @@ enum pipe_compute_cap > >>> > > PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE, > >>> > > PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY, > >>> > > PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS, > >>> > > - PIPE_COMPUTE_CAP_IMAGES_SUPPORTED > >>> > > + PIPE_COMPUTE_CAP_IMAGES_SUPPORTED, > >>> > > + PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE > >>> > > }; > >>> > > > >>> > > /** > >>> > > -- > >>> > > 1.8.1.5 > >>> > > > >>> > > ___ > >>> > > 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 mailing list > >>> mesa-dev@lists.freedesktop.org > >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > >> > >> -- > >> Jan Vesely -- Jan Vesely -- Jan Vesely signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE
On 24 July 2014 16:55, Marek Olšák wrote: > the hardware supports 16 constant buffers. I'm not sure what the > "constant registers" are, but they cannot have anything to do with the Probably the old CFILE constants, of which there actually only were 256, and which IIRC were removed since Evergreen. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Add support for BPTC texture compression
Ilia Mirkin writes: > Just a thought -- if online compression is highly unexpected, perhaps > it'd be reasonably to make a *horrid* compressor that doesn't rely on > any external libraries? I don't know how complex the BPTC format is, > but I suspect it may be possible to do a simple conversion that does > ~0 compression (and may actually make things larger). The compression ratio is fixed so the only variable is the quality of the image. I did make a naïve compressor for the RGBA UNORM format but I opted for the approach going via DXT3 instead because it looks nicer. I later modified that compressor to work for the half-float formats because we can't use DXT3 there. If we did want to avoid any dependencies and we don't care about the quality then that naïve compressor could still be an viable approach. Here's an example of the quality: http://busydoingnothing.co.uk/doge/ - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Add support for BPTC texture compression
On 07/23/2014 07:41 PM, Matt Turner wrote: > On Wed, Jul 23, 2014 at 3:16 PM, Ian Romanick wrote: >> On 07/22/2014 12:09 PM, Neil Roberts wrote: >>> Here's a first attempt at a patch series to implement BPTC texture >>> compression in the i965 driver on Gen>=7. >>> >>> Getting it to work on the hardware is pretty trivial as it's just a >>> case of adding some new Mesa format enums and then plugging them >>> together with the right Intel surface type. However GL requires that >>> you are able to get the library to compress textures on the fly so we >>> need a compressor too. I think for BPTC it doesn't really make much >>> sense to actually use this because it takes a very long time to search >>> the entire space and compress an image properly. For example the >>> NVidia compressor takes in the order of an hour for a full-screen >>> image. Instead I've just done the minimal work needed to get something >>> that gives vaguely passable results. >> >> Is that NVIDIA's off-line compression tool, or is that the compressor in >> the driver? A brute-force compressor will be very, very slow for BPTC. >> There are other approaches that are much faster without sacrificing >> very much quality. > > I suggested http://squish.paradice-insight.us/ which appears to be > down now. It has a (MIT licensed) BC7 compressor and no free BC6H > compressor. I suggested using it as an external dependency and > contributing a BC6H compressor back. > > I think the github repo is https://github.com/Ethatron/squish-ccr > > I was thinking one of the cool things we might be able to do a ETC2 -> > BC7 transcode on platforms without ETC2 hardware decompression. We > won't be able to do that without a good compressor. I had forgotten about that idea. There is value in that. Though, I suspect we'd want to do that transcode on the GPU, and probably do it block-by-block as Neil suggests. That's probably step 9, and we're still on step 2. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Add support for BPTC texture compression
On 07/24/2014 07:43 AM, Ilia Mirkin wrote: > On Thu, Jul 24, 2014 at 10:37 AM, Neil Roberts wrote: >> Ian Romanick writes: >> >>> Is that NVIDIA's off-line compression tool, or is that the compressor >>> in the driver? >> >> I was talking about the offline compressor. I don't know what NVidia's >> online compressor is like. Yes, perhaps if we can get a quick compressor >> with reasonable results then it starts to make sense to compress on the >> fly. > > Just a thought -- if online compression is highly unexpected, perhaps > it'd be reasonably to make a *horrid* compressor that doesn't rely on > any external libraries? I don't know how complex the BPTC format is, > but I suspect it may be possible to do a simple conversion that does > ~0 compression (and may actually make things larger). > > This would allow you to separate the problem of BPTC support in mesa > and all the potential external dependency/licensing issues. Almost all texture compression formats, including BPTC, are fixed-rate codecs. You always get M:N compression, but the quality of the result may differ. > Cheers, > > -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE
Sorry, GL 3.1 actually only requires 1024 vec4s. The UBO extension spec contains a mistake. Marek On Thu, Jul 24, 2014 at 4:55 PM, Marek Olšák wrote: > OpenGL 3.1 requires 4096 vec4s (65536 bytes) per constant buffer and > the hardware supports 16 constant buffers. I'm not sure what the > "constant registers" are, but they cannot have anything to do with the > constant buffer limit, because otherwise we wouldn't be able to meet > the requirement for uniform buffer objects. > > Marek > > On Thu, Jul 24, 2014 at 4:05 PM, Jan Vesely wrote: >> On Thu, 2014-07-24 at 06:35 -0700, Tom Stellard wrote: >>> On Thu, Jul 24, 2014 at 01:09:49PM +0200, Marek Olšák wrote: >>> > Isn't this redundant with get_shader_param(PIPE_SHADER_COMPUTE, >>> > PIPE_SHADER_CAP_MAX_CONSTS) * 16? >>> > >>> >>> This is what clover was using, but I was confused about what the value >>> was supposed to represent. Now, I think I understand (number of 4 x 32-bit >>> constants). I can use this instead. >> >> Is the value for r600 hw misreported then? The manuals for R600/EG/NI >> say there are 512 such registers. Yet the driver reports 4096. >> See the attached patch. >> >> Jan >> >>> >>> -Tom >>> > Marek >>> > >>> > On Thu, Jul 24, 2014 at 3:05 AM, Tom Stellard >>> > wrote: >>> > > --- >>> > > src/gallium/docs/source/screen.rst | 2 ++ >>> > > src/gallium/include/pipe/p_defines.h | 3 ++- >>> > > 2 files changed, 4 insertions(+), 1 deletion(-) >>> > > >>> > > diff --git a/src/gallium/docs/source/screen.rst >>> > > b/src/gallium/docs/source/screen.rst >>> > > index 830a1a5..219c9f9 100644 >>> > > --- a/src/gallium/docs/source/screen.rst >>> > > +++ b/src/gallium/docs/source/screen.rst >>> > > @@ -334,6 +334,8 @@ pipe_screen::get_compute_param. >>> > >Value type: ``uint32_t`` >>> > > * ``PIPE_COMPUTE_CAP_IMAGES_SUPPORTED``: Whether images are supported >>> > >non-zero means yes, zero means no. Value type: ``uint32_t`` >>> > > +* ``PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE``: The maximum size in >>> > > bytes >>> > > + of a constant buffer. Value type: ``uint64_t`` >>> > > >>> > > .. _pipe_bind: >>> > > >>> > > diff --git a/src/gallium/include/pipe/p_defines.h >>> > > b/src/gallium/include/pipe/p_defines.h >>> > > index 43bb1f5..78709b9 100644 >>> > > --- a/src/gallium/include/pipe/p_defines.h >>> > > +++ b/src/gallium/include/pipe/p_defines.h >>> > > @@ -651,7 +651,8 @@ enum pipe_compute_cap >>> > > PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE, >>> > > PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY, >>> > > PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS, >>> > > - PIPE_COMPUTE_CAP_IMAGES_SUPPORTED >>> > > + PIPE_COMPUTE_CAP_IMAGES_SUPPORTED, >>> > > + PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE >>> > > }; >>> > > >>> > > /** >>> > > -- >>> > > 1.8.1.5 >>> > > >>> > > ___ >>> > > 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 mailing list >>> mesa-dev@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> >> -- >> Jan Vesely ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Add support for BPTC texture compression
Matt Turner writes: > I was thinking one of the cool things we might be able to do a ETC2 -> > BC7 transcode on platforms without ETC2 hardware decompression. We > won't be able to do that without a good compressor. That sounds like a fun project. It would be a shame to have to completely decompress it and then recompress it though. It looks like for ETC1 it wouldn't be too tricky to losslessly map it to mode 3 of BPTC. You could emulate the 2x4 or 4x2 selection by using either partition 0 or 13 resepectively and then you could pick 4 endpoint colours that match the range allowed by the difference values. The 'T' and 'H' modes of ETC2 would probably be a lot trickier to map though because the indices effectively let you pick between either of the two subsets on a per-texel basis. Maybe you could do a decompress-recompress per-block only if it is using one of these two modes. I'm not sure about the planar mode. There might be some complicated way to represent it with the 3-subsets of mode 0. - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE
OpenGL 3.1 requires 4096 vec4s (65536 bytes) per constant buffer and the hardware supports 16 constant buffers. I'm not sure what the "constant registers" are, but they cannot have anything to do with the constant buffer limit, because otherwise we wouldn't be able to meet the requirement for uniform buffer objects. Marek On Thu, Jul 24, 2014 at 4:05 PM, Jan Vesely wrote: > On Thu, 2014-07-24 at 06:35 -0700, Tom Stellard wrote: >> On Thu, Jul 24, 2014 at 01:09:49PM +0200, Marek Olšák wrote: >> > Isn't this redundant with get_shader_param(PIPE_SHADER_COMPUTE, >> > PIPE_SHADER_CAP_MAX_CONSTS) * 16? >> > >> >> This is what clover was using, but I was confused about what the value >> was supposed to represent. Now, I think I understand (number of 4 x 32-bit >> constants). I can use this instead. > > Is the value for r600 hw misreported then? The manuals for R600/EG/NI > say there are 512 such registers. Yet the driver reports 4096. > See the attached patch. > > Jan > >> >> -Tom >> > Marek >> > >> > On Thu, Jul 24, 2014 at 3:05 AM, Tom Stellard >> > wrote: >> > > --- >> > > src/gallium/docs/source/screen.rst | 2 ++ >> > > src/gallium/include/pipe/p_defines.h | 3 ++- >> > > 2 files changed, 4 insertions(+), 1 deletion(-) >> > > >> > > diff --git a/src/gallium/docs/source/screen.rst >> > > b/src/gallium/docs/source/screen.rst >> > > index 830a1a5..219c9f9 100644 >> > > --- a/src/gallium/docs/source/screen.rst >> > > +++ b/src/gallium/docs/source/screen.rst >> > > @@ -334,6 +334,8 @@ pipe_screen::get_compute_param. >> > >Value type: ``uint32_t`` >> > > * ``PIPE_COMPUTE_CAP_IMAGES_SUPPORTED``: Whether images are supported >> > >non-zero means yes, zero means no. Value type: ``uint32_t`` >> > > +* ``PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE``: The maximum size in >> > > bytes >> > > + of a constant buffer. Value type: ``uint64_t`` >> > > >> > > .. _pipe_bind: >> > > >> > > diff --git a/src/gallium/include/pipe/p_defines.h >> > > b/src/gallium/include/pipe/p_defines.h >> > > index 43bb1f5..78709b9 100644 >> > > --- a/src/gallium/include/pipe/p_defines.h >> > > +++ b/src/gallium/include/pipe/p_defines.h >> > > @@ -651,7 +651,8 @@ enum pipe_compute_cap >> > > PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE, >> > > PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY, >> > > PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS, >> > > - PIPE_COMPUTE_CAP_IMAGES_SUPPORTED >> > > + PIPE_COMPUTE_CAP_IMAGES_SUPPORTED, >> > > + PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE >> > > }; >> > > >> > > /** >> > > -- >> > > 1.8.1.5 >> > > >> > > ___ >> > > 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 mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- > Jan Vesely ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/wgl: Clamp wglChoosePixelFormatARB's output nNumFormats to nMaxFormats.
From: José Fonseca
While running https://github.com/nvMcJohn/apitest with apitrace I noticed that
Mesa was producing bogus results:
wglChoosePixelFormatARB(hdc, piAttribIList = {...}, pfAttribFList = &0,
nMaxFormats = 1, piFormats = {19, 65576, 37, 198656, 131075, 0, 402653184, 0,
0, 0, 0, -573575710}, nNumFormats = &12) = TRUE
However https://www.opengl.org/registry/specs/ARB/wgl_pixel_format.txt states
returns the number of matching formats. The returned
value is guaranteed to be no larger than .
Cc: "10.2"
---
src/gallium/state_trackers/wgl/stw_ext_pixelformat.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/wgl/stw_ext_pixelformat.c
b/src/gallium/state_trackers/wgl/stw_ext_pixelformat.c
index d303b01..91682d1 100644
--- a/src/gallium/state_trackers/wgl/stw_ext_pixelformat.c
+++ b/src/gallium/state_trackers/wgl/stw_ext_pixelformat.c
@@ -448,9 +448,11 @@ wglChoosePixelFormatARB(
*/
for (i = 0; i < count; i++) {
if (scores[i].points > 0) {
- if (*nNumFormats < nMaxFormats)
-piFormats[*nNumFormats] = scores[i].index + 1;
+piFormats[*nNumFormats] = scores[i].index + 1;
(*nNumFormats)++;
+if (*nNumFormats >= nMaxFormats) {
+ break;
+}
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/imports.h: VS2013 doesn't provide strcasecmp
On 07/24/2014 02:12 PM, Alon Levy wrote:
> From: Alon Levy
Forgot to add Ian as cc.
>
> Fixed build error at glsl_parser.yy for Visual Studio 2013
>
> Signed-off-by: Alon Levy
> ---
> Thanks for the review. I verified and VS2013 (vs12) doesn't include
> strcasecmp,
> I corrected the file you mentioned, here is a better patch. (this supercedes
> the previous patch)
>
> src/mesa/main/imports.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
> index 9e221cc..06b460d 100644
> --- a/src/mesa/main/imports.h
> +++ b/src/mesa/main/imports.h
> @@ -141,6 +141,9 @@ static inline float acoshf(float x) { return logf(x +
> sqrtf(x * x - 1.0f)); }
> static inline float atanhf(float x) { return (logf(1.0f + x) - logf(1.0f -
> x)) / 2.0f; }
> static inline int isblank(int ch) { return ch == ' ' || ch == '\t'; }
> #define strtoll(p, e, b) _strtoi64(p, e, b)
> +#endif
> +
> +#if defined(_MSC_VER)
> #define strcasecmp(s1, s2) _stricmp(s1, s2)
> #endif
> /*@}*/
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Add support for BPTC texture compression
On Thu, Jul 24, 2014 at 10:37 AM, Neil Roberts wrote: > Ian Romanick writes: > >> Is that NVIDIA's off-line compression tool, or is that the compressor >> in the driver? > > I was talking about the offline compressor. I don't know what NVidia's > online compressor is like. Yes, perhaps if we can get a quick compressor > with reasonable results then it starts to make sense to compress on the > fly. Just a thought -- if online compression is highly unexpected, perhaps it'd be reasonably to make a *horrid* compressor that doesn't rely on any external libraries? I don't know how complex the BPTC format is, but I suspect it may be possible to do a simple conversion that does ~0 compression (and may actually make things larger). This would allow you to separate the problem of BPTC support in mesa and all the potential external dependency/licensing issues. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Add support for BPTC texture compression
Ian Romanick writes: > Is that NVIDIA's off-line compression tool, or is that the compressor > in the driver? I was talking about the offline compressor. I don't know what NVidia's online compressor is like. Yes, perhaps if we can get a quick compressor with reasonable results then it starts to make sense to compress on the fly. I'll take a look at using FasTC or Squish. However, it looks like both of these libraries also support S3TC. If that's the case then would it be a bit bad to have a hard dependency on one of those libraries? Maybe distros would be reluctant to package those libraries if they are worried about S3TC. > This means that we can only enable BPTC when libtxc_dxtn.so is > available... which means patch 5 needs some changes. :( Yes, fair enough. As you say though I think it would be better to avoid tying BPTC to S3TC so maybe this approach just isn't the right idea. - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] os_process.c: Add cygwin as an expected platform
From: Yaakov Selkowitz mesa/mesa/src/gallium/auxiliary/os/os_process.c:40:2: warning: #warning unexpected platform in os_process.c [-Wcpp] #warning unexpected platform in os_process.c mesa/mesa/src/gallium/auxiliary/os/os_process.c:77:2: warning: #warning unexpected platform in os_process.c [-Wcpp] #warning unexpected platform in os_process.c Signed-off-by: Yaakov Selkowitz Reviewed-by: Jon TURNEY --- src/gallium/auxiliary/os/os_process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/os/os_process.c b/src/gallium/auxiliary/os/os_process.c index ef38e1d..3e060b9 100644 --- a/src/gallium/auxiliary/os/os_process.c +++ b/src/gallium/auxiliary/os/os_process.c @@ -32,7 +32,7 @@ #if defined(PIPE_SUBSYSTEM_WINDOWS_USER) # include -#elif defined(__GLIBC__) +#elif defined(__GLIBC__) || defined(__CYGWIN__) # include #elif defined(PIPE_OS_BSD) || defined(PIPE_OS_APPLE) # include @@ -68,7 +68,7 @@ os_get_process_name(char *procname, size_t size) name = lpProcessName; -#elif defined(__GLIBC__) +#elif defined(__GLIBC__) || defined(__CYGWIN__) name = program_invocation_short_name; #elif defined(PIPE_OS_BSD) || defined(PIPE_OS_APPLE) /* *BSD and OS X */ -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/2] Teach some platform checks about Cygwin
A couple of small fixes to teach platform checks about Cygwin's characteristics Ideally, these would be autoconf checks, and we wouldn't have to do anything here, but it seems that ship has long sailed. Yaakov Selkowitz (2): xmlconfig: Use program_invocation_short_name when building for cygwin os_process.c: Add cygwin as an expected platform src/gallium/auxiliary/os/os_process.c | 4 ++-- src/mesa/drivers/dri/common/xmlconfig.c | 2 ++ 2 files changed, 4 insertions(+), 2 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 1/2] xmlconfig: Use program_invocation_short_name when building for cygwin
From: Yaakov Selkowitz mesa/mesa/src/mesa/drivers/dri/common/xmlconfig.c:104:10: warning: #warning "Per application configuration won't work with your OS version." [-Wcpp] #warning "Per application configuration won't work with your OS version." Signed-off-by: Yaakov Selkowitz Reviewed-by: Jon TURNEY --- src/mesa/drivers/dri/common/xmlconfig.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/mesa/drivers/dri/common/xmlconfig.c b/src/mesa/drivers/dri/common/xmlconfig.c index 58d0e06..ce37647 100644 --- a/src/mesa/drivers/dri/common/xmlconfig.c +++ b/src/mesa/drivers/dri/common/xmlconfig.c @@ -45,6 +45,8 @@ extern char *program_invocation_name, *program_invocation_short_name; #endif #define GET_PROGRAM_NAME() program_invocation_short_name +#elif defined(__CYGWIN__) +#define GET_PROGRAM_NAME() program_invocation_short_name #elif defined(__FreeBSD__) && (__FreeBSD__ >= 2) #include #if (__FreeBSD_version >= 44) -- 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 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE
On Thu, 2014-07-24 at 06:35 -0700, Tom Stellard wrote: > On Thu, Jul 24, 2014 at 01:09:49PM +0200, Marek Olšák wrote: > > Isn't this redundant with get_shader_param(PIPE_SHADER_COMPUTE, > > PIPE_SHADER_CAP_MAX_CONSTS) * 16? > > > > This is what clover was using, but I was confused about what the value > was supposed to represent. Now, I think I understand (number of 4 x 32-bit > constants). I can use this instead. Is the value for r600 hw misreported then? The manuals for R600/EG/NI say there are 512 such registers. Yet the driver reports 4096. See the attached patch. Jan > > -Tom > > Marek > > > > On Thu, Jul 24, 2014 at 3:05 AM, Tom Stellard > > wrote: > > > --- > > > src/gallium/docs/source/screen.rst | 2 ++ > > > src/gallium/include/pipe/p_defines.h | 3 ++- > > > 2 files changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/src/gallium/docs/source/screen.rst > > > b/src/gallium/docs/source/screen.rst > > > index 830a1a5..219c9f9 100644 > > > --- a/src/gallium/docs/source/screen.rst > > > +++ b/src/gallium/docs/source/screen.rst > > > @@ -334,6 +334,8 @@ pipe_screen::get_compute_param. > > >Value type: ``uint32_t`` > > > * ``PIPE_COMPUTE_CAP_IMAGES_SUPPORTED``: Whether images are supported > > >non-zero means yes, zero means no. Value type: ``uint32_t`` > > > +* ``PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE``: The maximum size in > > > bytes > > > + of a constant buffer. Value type: ``uint64_t`` > > > > > > .. _pipe_bind: > > > > > > diff --git a/src/gallium/include/pipe/p_defines.h > > > b/src/gallium/include/pipe/p_defines.h > > > index 43bb1f5..78709b9 100644 > > > --- a/src/gallium/include/pipe/p_defines.h > > > +++ b/src/gallium/include/pipe/p_defines.h > > > @@ -651,7 +651,8 @@ enum pipe_compute_cap > > > PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE, > > > PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY, > > > PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS, > > > - PIPE_COMPUTE_CAP_IMAGES_SUPPORTED > > > + PIPE_COMPUTE_CAP_IMAGES_SUPPORTED, > > > + PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE > > > }; > > > > > > /** > > > -- > > > 1.8.1.5 > > > > > > ___ > > > 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 mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Jan Vesely From 48536e44883f8f3f4846235dc60982328cfc6805 Mon Sep 17 00:00:00 2001 From: Jan Vesely Date: Thu, 24 Jul 2014 09:58:40 -0400 Subject: [PATCH 1/1] r600g: Fix number of reported constant regs. See table 2.6 of R600 and table 2.9 of EG/NI manual Signed-off-by: Jan Vesely --- src/gallium/drivers/r600/r600_pipe.c | 2 +- src/gallium/drivers/r600/r600_pipe.h | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index ee6a416..d9636ee 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -420,7 +420,7 @@ static int r600_get_shader_param(struct pipe_screen* pscreen, unsigned shader, e /* XXX Isn't this equal to TEMPS? */ return 1; /* Max native address registers */ case PIPE_SHADER_CAP_MAX_CONSTS: - return R600_MAX_CONST_BUFFER_SIZE; + return 512; case PIPE_SHADER_CAP_MAX_CONST_BUFFERS: return R600_MAX_USER_CONST_BUFFERS; case PIPE_SHADER_CAP_MAX_PREDS: diff --git a/src/gallium/drivers/r600/r600_pipe.h b/src/gallium/drivers/r600/r600_pipe.h index 4585ace..f01134c 100644 --- a/src/gallium/drivers/r600/r600_pipe.h +++ b/src/gallium/drivers/r600/r600_pipe.h @@ -54,8 +54,6 @@ #define R600_BUFFER_INFO_CONST_BUFFER (R600_MAX_USER_CONST_BUFFERS + 2) #define R600_GS_RING_CONST_BUFFER (R600_MAX_USER_CONST_BUFFERS + 3) -#define R600_MAX_CONST_BUFFER_SIZE 4096 - #ifdef PIPE_ARCH_BIG_ENDIAN #define R600_BIG_ENDIAN 1 #else -- 1.9.3 signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] Add the format enums for BPTC-compressed images
On Wed, Jul 23, 2014 at 5:57 PM, Ian Romanick wrote: > On 07/22/2014 12:09 PM, Neil Roberts wrote: >> diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c >> index 9dbfe9f..b708b49 100644 >> --- a/src/mesa/main/texcompress.c >> +++ b/src/mesa/main/texcompress.c >> @@ -235,6 +235,12 @@ _mesa_gl_compressed_format_base_format(GLenum format) >> * GL_EXT_texture_compression_latc. At the very least, Catalyst 11.6 does >> not >> * expose the 3dc formats through this mechanism. >> * >> + * The spec for GL_ARB_texture_compression_bptc doesn't mention whether it >> + * should be included in GL_COMPRESSED_TEXTURE_FORMATS. However as it takes >> a >> + * very long time to compress the textures in this format it's probably not >> + * very useful as a general format where the GL will have to compress it on >> + * the fly. >> + * > > What do NVIDIA and AMD do? We should mimic that. I asked our closed source GL team and they said they do include it in GL_COMPRESSED_TEXTURE_FORMATS. Alex > >> * \param ctx the GL context >> * \param formats the resulting format list (may be NULL). >> * > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE
On Thu, Jul 24, 2014 at 01:09:49PM +0200, Marek Olšák wrote: > Isn't this redundant with get_shader_param(PIPE_SHADER_COMPUTE, > PIPE_SHADER_CAP_MAX_CONSTS) * 16? > This is what clover was using, but I was confused about what the value was supposed to represent. Now, I think I understand (number of 4 x 32-bit constants). I can use this instead. -Tom > Marek > > On Thu, Jul 24, 2014 at 3:05 AM, Tom Stellard wrote: > > --- > > src/gallium/docs/source/screen.rst | 2 ++ > > src/gallium/include/pipe/p_defines.h | 3 ++- > > 2 files changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/src/gallium/docs/source/screen.rst > > b/src/gallium/docs/source/screen.rst > > index 830a1a5..219c9f9 100644 > > --- a/src/gallium/docs/source/screen.rst > > +++ b/src/gallium/docs/source/screen.rst > > @@ -334,6 +334,8 @@ pipe_screen::get_compute_param. > >Value type: ``uint32_t`` > > * ``PIPE_COMPUTE_CAP_IMAGES_SUPPORTED``: Whether images are supported > >non-zero means yes, zero means no. Value type: ``uint32_t`` > > +* ``PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE``: The maximum size in bytes > > + of a constant buffer. Value type: ``uint64_t`` > > > > .. _pipe_bind: > > > > diff --git a/src/gallium/include/pipe/p_defines.h > > b/src/gallium/include/pipe/p_defines.h > > index 43bb1f5..78709b9 100644 > > --- a/src/gallium/include/pipe/p_defines.h > > +++ b/src/gallium/include/pipe/p_defines.h > > @@ -651,7 +651,8 @@ enum pipe_compute_cap > > PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE, > > PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY, > > PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS, > > - PIPE_COMPUTE_CAP_IMAGES_SUPPORTED > > + PIPE_COMPUTE_CAP_IMAGES_SUPPORTED, > > + PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE > > }; > > > > /** > > -- > > 1.8.1.5 > > > > ___ > > 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] Add support for swrast to the DRM EGL platform
On Thu, 24 Jul 2014 13:34:42 +0100
Emil Velikov wrote:
> On 24/07/14 07:23, Pekka Paalanen wrote:
> > On Thu, 24 Jul 2014 01:43:35 +0100
> > Emil Velikov wrote:
> >
> >> From: Giovanni Campagna
> >>
> >> Turn GBM into a swrast loader (providing putimage/getimage backed
> >> by a dumb KMS buffer). This allows to run KMS+DRM GL applications
> >> (such as weston or mutter-wayland) unmodified on cards that don't
> >> have any client side HW acceleration component but that can do
> >> modeset (examples include simpledrm and qxl)
> >>
> >> [Emil Velikov]
> >> - Fix make check.
> >> - Split dri_open_driver() from dri_load_driver().
> >> - Don't try to bind the swrast extensions when using dri.
> >> - Handle swrast->CreateNewScreen() failure.
> >> - strdup the driver_name, as it's free'd at destruction.
> >> - s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE/
> >> - Move gbm_dri_bo_map/unmap to gbm_driiint.h.
> >> - Correct swrast fallback logic.
> >>
> >> Signed-off-by: Emil Velikov
> >> ---
> >> src/egl/drivers/dri2/platform_drm.c | 153 +++
> >> src/gbm/backends/dri/gbm_dri.c | 203
> >> +++-
> >> src/gbm/backends/dri/gbm_driint.h | 57 +-
> >> src/gbm/gbm-symbols-check | 1 +
> >> src/gbm/main/gbm.h | 3 +
> >> 5 files changed, 369 insertions(+), 48 deletions(-)
> >>
> >
> >> diff --git a/src/gbm/backends/dri/gbm_dri.c
> >> b/src/gbm/backends/dri/gbm_dri.c
> >> index 347bc99..1aca506 100644
> >> --- a/src/gbm/backends/dri/gbm_dri.c
> >> +++ b/src/gbm/backends/dri/gbm_dri.c
> >
> >> @@ -743,7 +886,7 @@ static struct gbm_device *
> >> dri_device_create(int fd)
> >> {
> >> struct gbm_dri_device *dri;
> >> - int ret;
> >> + int ret, force_sw;
> >>
> >> dri = calloc(1, sizeof *dri);
> >> if (!dri)
> >> @@ -763,7 +906,15 @@ dri_device_create(int fd)
> >> dri->base.type = GBM_DRM_DRIVER_TYPE_DRI;
> >> dri->base.base.name = "drm";
> >>
> >> - ret = dri_screen_create(dri);
> >> + force_sw = getenv("GBM_ALWAYS_SOFTWARE") != NULL;
> >> + if (!force_sw) {
> >> + ret = dri_screen_create(dri);
> >> + if (ret)
> >> + ret = dri_screen_create_swrast(dri);
> >> + } else {
> >> + ret = dri_screen_create_swrast(dri);
> >> + }
> >> +
> >> if (ret)
> >>goto err_dri;
> >
> > Hi,
> >
> > is GBM_ALWAYS_SOFTWARE a new env var?
> > Is it documented somewhere?
> None of the GBM env variables are. In a matter of fact there isn't even a
> single reference of gbm in the docs - env vars or otherwise. It's like gbm
> does not exist :'(
>
> Will need to get a new document out there similar to egl.html.
> Any objections if we do that as a follow up patch ?
I would be happy to see any documentation at some point. :-)
> > How does it interact with EGL_SOFTWARE?
> > Does GBM_ALWAYS_SOFTWARE affect GBM's ability to import dmabufs
> > somehow, or only the surfaces that will be passed to EGL?
> > (Importing dmabufs to be passed directly to KMS for scanout.)
> >
> Considering it's a variable that needs to be explicitly set, the behaviour
> depends on the current state of the software backend.
>
> AFAICS current swrast/kms_swrast does not allow/use dmabufs.
Maybe that was a stupid question on my part, as I don't know
whether generic DRM API even has a way to import dmabufs at all.
Something like dumb buffer import...
> > I'm terribly confused with all the *SOFTWARE* variables, and it seems
> > I'm not alone as someone just recently filed a bunch of Weston bug
> > reports while trying to get software GL rendering with
> > LIBGL_ALWAYS_SOFTWARE on DRM/KMS.
> >
> >
> I have the sneaking suspicion that most people see LIBGL_ALWAYS_SOFTWARE as
> the magic variable that reads your mind and makes things work as you would
> imagine them. Would be great to move from that to read the documentation and
> amend propose improvements of it when needed.
Right. What about EGL_SOFTWARE? Why not use that on GBM platform too? A
quick grep implies that X11 and Wayland platforms use it (but only with
egl_gallium.so?)?
GBM_ALWAYS_SOFTWARE sounds like a platform-specific variable, but
should forcing software rendering be platform-specific?
Btw. how do you force software rendering if using egl_dri2 driver on
any platform? And not using libGL but, say, GLESv2? Uhh... :-)
Thanks,
pq
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead
On 23/07/14 22:16, Ian Romanick wrote: > On 07/22/2014 02:07 PM, Alon Levy wrote: >> Signed-off-by: Alon Levy >> --- >> src/glsl/glsl_parser.yy | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy >> index faaf438..25370cd 100644 >> --- a/src/glsl/glsl_parser.yy >> +++ b/src/glsl/glsl_parser.yy >> @@ -26,6 +26,10 @@ >> #include >> #include >> >> +#ifdef _MSC_VER <= 1800 >> +#define strcasecmp _stricmp >> +#endif >> + > > glsl_parser.yy should already get the strcasecmp work around from > src/mesa/main/imports.h. > Just a general question - wouldn't it be better if we move some/all these quirks around the POSIX standard(s) into a header similar to c99_compat ? ... before the amount of duplication gets out of hand. -Emil >> #include "ast.h" >> #include "glsl_parser_extras.h" >> #include "glsl_types.h" > > ___ > 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] egl/gallium: implemlent EGL_KHR_create_context v3
On 06/27/2014 10:59 AM, Knut Andre Tidemann wrote:
v2: fix style and wrong major version comparison.
v3: fix version check in context creation.
---
src/gallium/state_trackers/egl/common/egl_g3d.c | 1 +
src/gallium/state_trackers/egl/common/egl_g3d_api.c | 12
2 files changed, 13 insertions(+)
diff --git a/src/gallium/state_trackers/egl/common/egl_g3d.c
b/src/gallium/state_trackers/egl/common/egl_g3d.c
index d3f5e92..22b5e4a 100644
--- a/src/gallium/state_trackers/egl/common/egl_g3d.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d.c
@@ -584,6 +584,7 @@ egl_g3d_initialize(_EGLDriver *drv, _EGLDisplay *dpy)
dpy->Extensions.KHR_fence_sync = EGL_TRUE;
dpy->Extensions.KHR_surfaceless_context = EGL_TRUE;
+ dpy->Extensions.KHR_create_context = EGL_TRUE;
if (dpy->Platform == _EGL_PLATFORM_DRM) {
dpy->Extensions.MESA_drm_display = EGL_TRUE;
diff --git a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
index b19d899..5e900cc 100644
--- a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
@@ -72,6 +72,11 @@ egl_g3d_choose_st(_EGLDriver *drv, _EGLContext *ctx,
break;
case EGL_OPENGL_API:
api = ST_API_OPENGL;
+ if (((ctx->ClientMajorVersion >= 4) ||
+(ctx->ClientMajorVersion == 3 && ctx->ClientMinorVersion >= 2)) &&
+ctx->Profile == EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR) {
+ *profile = ST_PROFILE_OPENGL_CORE;
+ }
break;
default:
_eglLog(_EGL_WARNING, "unknown client API 0x%04x", ctx->ClientAPI);
@@ -166,6 +171,12 @@ egl_g3d_create_context(_EGLDriver *drv, _EGLDisplay *dpy,
_EGLConfig *conf,
if (gconf)
stattribs.visual = gconf->stvis;
+ if (gctx->base.Flags & EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR)
+ stattribs.flags = ST_CONTEXT_FLAG_DEBUG;
+
+ stattribs.major = gctx->base.ClientMajorVersion;
+ stattribs.minor = gctx->base.ClientMinorVersion;
+
gctx->stapi = egl_g3d_choose_st(drv, &gctx->base, &stattribs.profile);
if (!gctx->stapi) {
FREE(gctx);
@@ -175,6 +186,7 @@ egl_g3d_create_context(_EGLDriver *drv, _EGLDisplay *dpy,
_EGLConfig *conf,
gctx->stctxi = gctx->stapi->create_context(gctx->stapi, gdpy->smapi,
&stattribs, &ctx_err, (gshare) ? gshare->stctxi : NULL);
if (!gctx->stctxi) {
+ _eglError(EGL_BAD_MATCH, "eglCreateContext");
FREE(gctx);
return NULL;
}
Is there any interest in this? If not I would like to make a feature
request as it is the only way to create a core context with EGL at the
moment.
--
Knut Tidemann
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] Add support for swrast to the DRM EGL platform
On 24/07/14 07:23, Pekka Paalanen wrote:
> On Thu, 24 Jul 2014 01:43:35 +0100
> Emil Velikov wrote:
>
>> From: Giovanni Campagna
>>
>> Turn GBM into a swrast loader (providing putimage/getimage backed
>> by a dumb KMS buffer). This allows to run KMS+DRM GL applications
>> (such as weston or mutter-wayland) unmodified on cards that don't
>> have any client side HW acceleration component but that can do
>> modeset (examples include simpledrm and qxl)
>>
>> [Emil Velikov]
>> - Fix make check.
>> - Split dri_open_driver() from dri_load_driver().
>> - Don't try to bind the swrast extensions when using dri.
>> - Handle swrast->CreateNewScreen() failure.
>> - strdup the driver_name, as it's free'd at destruction.
>> - s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE/
>> - Move gbm_dri_bo_map/unmap to gbm_driiint.h.
>> - Correct swrast fallback logic.
>>
>> Signed-off-by: Emil Velikov
>> ---
>> src/egl/drivers/dri2/platform_drm.c | 153 +++
>> src/gbm/backends/dri/gbm_dri.c | 203
>> +++-
>> src/gbm/backends/dri/gbm_driint.h | 57 +-
>> src/gbm/gbm-symbols-check | 1 +
>> src/gbm/main/gbm.h | 3 +
>> 5 files changed, 369 insertions(+), 48 deletions(-)
>>
>
>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>> index 347bc99..1aca506 100644
>> --- a/src/gbm/backends/dri/gbm_dri.c
>> +++ b/src/gbm/backends/dri/gbm_dri.c
>
>> @@ -743,7 +886,7 @@ static struct gbm_device *
>> dri_device_create(int fd)
>> {
>> struct gbm_dri_device *dri;
>> - int ret;
>> + int ret, force_sw;
>>
>> dri = calloc(1, sizeof *dri);
>> if (!dri)
>> @@ -763,7 +906,15 @@ dri_device_create(int fd)
>> dri->base.type = GBM_DRM_DRIVER_TYPE_DRI;
>> dri->base.base.name = "drm";
>>
>> - ret = dri_screen_create(dri);
>> + force_sw = getenv("GBM_ALWAYS_SOFTWARE") != NULL;
>> + if (!force_sw) {
>> + ret = dri_screen_create(dri);
>> + if (ret)
>> + ret = dri_screen_create_swrast(dri);
>> + } else {
>> + ret = dri_screen_create_swrast(dri);
>> + }
>> +
>> if (ret)
>>goto err_dri;
>
> Hi,
>
> is GBM_ALWAYS_SOFTWARE a new env var?
> Is it documented somewhere?
None of the GBM env variables are. In a matter of fact there isn't even a
single reference of gbm in the docs - env vars or otherwise. It's like gbm
does not exist :'(
Will need to get a new document out there similar to egl.html.
Any objections if we do that as a follow up patch ?
> How does it interact with EGL_SOFTWARE?
> Does GBM_ALWAYS_SOFTWARE affect GBM's ability to import dmabufs
> somehow, or only the surfaces that will be passed to EGL?
> (Importing dmabufs to be passed directly to KMS for scanout.)
>
Considering it's a variable that needs to be explicitly set, the behaviour
depends on the current state of the software backend.
AFAICS current swrast/kms_swrast does not allow/use dmabufs.
> I'm terribly confused with all the *SOFTWARE* variables, and it seems
> I'm not alone as someone just recently filed a bunch of Weston bug
> reports while trying to get software GL rendering with
> LIBGL_ALWAYS_SOFTWARE on DRM/KMS.
>
>
I have the sneaking suspicion that most people see LIBGL_ALWAYS_SOFTWARE as
the magic variable that reads your mind and makes things work as you would
imagine them. Would be great to move from that to read the documentation and
amend propose improvements of it when needed.
Cheers,
Emil
> Thanks,
> pq
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
