date:20150304

Re: [Mesa-dev] egl dma-buf export extension again

2015-03-04 Thread Daniel Stone

Hi,

On 3 March 2015 at 23:26, Kristian Høgsberg  wrote:
> On Tue, Mar 3, 2015 at 10:43 AM, Chad Versace  wrote:
>> Please use EGLImages as the import/export object. That provides
>> consistency with existing similar EGL APIs. And it allows a clean
>> separation between EGL-aware code and GL-aware code in applications
>> and compositors.
>>
>> For what it's worth, extensions in this area being developed by Google's
>> Chrome OS team also use EGLImages as the transport object.
>
> We can't both implement EGLImages in a compliant way *and* use them
> for cross-process sharing like we do.  The spec language around
> orphaning and siblings is obscure, but the idea is that whenever you
> add a sibling (another client API object, eg a texture or a vg
> renderbuffer) the contents become invalid.  The intended use case is
> that you create all siblings up front and then start using them.  For
> example, to share an image between VG and GL, you create the VG
> buffer, then the EGLImage and then the GL texture.  Implementations
> will defer allocation until all the siblings are set up and then only
> once you start rendering allocate the memory.  This allows the
> implementation to accommodate constraints from all siblings. If you
> add another sibling, the implementation may have to reallocate storage
> to satisfy new constraints.  This clearly isn't compatible with how we
> create and share EGLImages left and right across process boundaries.
> Khronos specifically developed EGLStreams as a cross-process color
> buffer sharing mechanism without pulling in EGLImage as a dependency.
>
> Anyway, the damage is done and we can continue digging ourselves
> deeper into this hole, but we should at least 1) have a good reason
> why the extra EGLImage indirection is necessary (it also rules out GLX
> usage) and 2) acknowledge that we're going to continue to rely on our
> broken EGLImage semantics.

Which is all fair enough, but I think it's worth noting that
SurfaceFlinger, when confronted with the exact same problem space,
decided that the same answer was the best way forward. So we've got
some precedent established there.

Given the various interesting and creative ways in which people have
broken their EGLImage implementations, I'm not really sure that I want
to leave them to chance another, much less standard, spec, which has
less of a precedent around it.

Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] main/base_tex_format: Properly handle STENCIL_INDEX1/4/16

2015-03-04 Thread Pohjolainen, Topi

On Tue, Mar 03, 2015 at 05:08:23PM +, Neil Roberts wrote:
> Jason Ekstrand  writes:
> 
> > On Mon, Mar 2, 2015 at 11:33 AM, Ilia Mirkin  wrote:
> >
> >> On Mon, Mar 2, 2015 at 2:32 PM, Jason Ekstrand 
> >> wrote:
> >> >
> >> >
> >> > On Mon, Mar 2, 2015 at 11:18 AM, Ilia Mirkin 
> >> wrote:
> >> >>
> >> >> Hmmm... I was just looking at this code in connection to attepmting to
> >> >> enable ARB_texture_stencil8, and it _seems_ like that should be if
> >> >> (ARB_texture_stencil8) -- I didn't see what in ARB_stencil_texturing
> >> >> had to do with being able to have a GL_STENCIL_INDEX* internal
> >> >> format...
> >> >
> >> >
> >> > I just pushed it because it does fix a bug...  However, you do raise a
> >> good
> >> > point.  Maybe we should change the i965 driver to use GL_STENCIL_INDEX
> >> for
> >> > the internal format for our internal stencil buffers.
> >>
> >> How do you end up with a GL_STENCIL_INDEX internal format in the first
> >> place? Without ARB_texture_stencil8 that's not a thing, is it?
> >>
> >
> > We're using it internally for doing stencil blits.  I'm going to Cc Neil
> > and he can explain what's going on there better than I can as he was the
> > one who wrote most of that code.
> 
> Do you mean the code to do the meta stencil blit? I haven't touched
> that. Maybe I can pass the buck on to Topi :)

I may not be answering to the question but I'll explain what the meta path
does. It sets the texturing mode using:

   _mesa_TexParameteri(target, GL_DEPTH_STENCIL_TEXTURE_MODE,
  GL_STENCIL_INDEX);

This in order to follow the spec:

"Texture lookups involving texture objects with an internal format of
 DEPTH_STENCIL can read the stencil value as described in section
 3.10.18 by setting the DEPTH_STENCIL_TEXTURE_MODE to STENCIL_INDEX."

But this should be effecting only gl_texture_object::StencilSampling which
is considered by the surface state setup later on in i965. I don't believe
I have altered any internal format related logic for this.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] RFC: Prune stale components

2015-03-04 Thread Jose Fonseca

On 04/03/15 00:24, Emil Velikov wrote:

On 03/03/15 22:04, Jose Fonseca wrote:

On 03/03/15 18:39, Emil Velikov wrote:

On 3 March 2015 at 17:16, Jose Fonseca wrote:
...

I've prototyped this in

https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Ejrfonseca_mesa_log_-3Fh-3Dremove-2Dst-2Degl&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=DBmTkQmzY89vDw_KLOol0FBhKxmBTyqNfsx_ly5H-ZU&s=zhIQc271rsRkCQHGsaFYKm3SFwRTGWAib63t3Fjdhyo&e=

The changes are massive, so I'm not sure it's even worth spamming the
list
with them.

Could you please give a look and let me know if there are any concerns?

I've spotted a few trivial bits:

- windows/gdi: Remove.
Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST
The driver had interesting api/wrapper similar to osmesa. Did not know
that :-)

- st/egl: Remove.
Update the src/egl/main/Sconscript to create a SharedLibrary, add
versioning, create symlink - copy the bits from egl-static.

Drop st/egl and targets/egl-static from
src/gallium/Makefile.am:EXTRA_DIST

Remove the _EGL_BUILT_IN_DRIVER_GALLIUM define from
src/egl/main/Android.mk.
- st/vega: Remove.
A few "openvg" references left - one in configure.ac another one in
docs/contents.html

Thanks. I pushed a new version of the branch with all issues fixed.

I'm guessing you made a typo in src/egl/main/SConscript

+egl = env.InstallSharedLibrary(egl, version=(1, 0, 0))

Shouldn't the version be 1.4 ?

No, it wasn't a typo. It matches what autotools does now.

I can't say which is more correct 1.0 or 1.4, but it doesn't make sense
for SCons to do something different than autotools for the exact same code.

The only snafu is Android.mk -- it will be broken with gallium
drivers until
somebody familiar with that infrastructure updates it to use
egl_dri2. But
it should build fine without gallium drivers.

The Android build is mostly limping around mesa 10.4. I've pinged the
Android-x86 guys, but but might get to it soon(ish). Don't worry too
much about it.

I'm guessing that the scons and automake build do not point out
anything unusual ?

Right. automake, scons/linux and scons/windows all build happily. Of
course, automake has many options, and I only tested one (with dri and
gallium sw rasterizers).

These components are rather nicely isolated, so it should not matter
that much.

I'm suspecting that scons does not link against all libs for libEGL.

ldd -r build/linux-x86_64-debug/egl/main/libEGL.so is clean.

Adding -Wl,--no-undefined/-Wl,-z,defs to SHLINKFLAGS should clear it up,
yet feel free to do it as a follow up. I would highly recommend adding
it (-Wl...) for every SharedLibrary in scons. Using the version scripts
like autotools, to restrict the exported symbols, will be great.

I'll see what can be done.

Unfortunately (at least in the past) we used to have .so depending on
symbols from the .so/executable that dlopened it (ie, cyclic
dependencies), so doing this universally woulddn't be possible. Not sure
if that's still the case.

With the versioning question addressed, feel free to add
Reviewed-by: Emil Velikov

Thanks for the reviews.

Please drop a couple of lines in the release notes, when you're finished
removing all the old/unused bits.

Sure.

-Emil

P.S. Strange. After spending so much time fixing the builds, it feels so
nice as various chunks of it end up removed :-P

Yeah. I feel the same, even with code I wrote myself. Maintaining code
takes a toll in time and energy (all those worries about things one
should have done but never had the time). So removing code (or
abandoning projects) is effectively taking a weight from ones
conscience. And enables one to use that time/energy for better things.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: Fix GCC unused-variable warning in release build.

2015-03-04 Thread Timothy Arceri

Reviewed-by: Timothy Arceri 

On Tue, 2015-03-03 at 18:49 -0800, Vinson Lee wrote:
>   CXX  ast_array_index.lo
> ast_array_index.cpp: In function ‘void update_max_array_access(ir_rvalue*, 
> int, YYLTYPE*, _mesa_glsl_parse_state*)’:
> ast_array_index.cpp:86:30: warning: unused variable ‘interface_type’ 
> [-Wunused-variable]
>  const glsl_type *interface_type =
>   ^
> 
> Signed-off-by: Vinson Lee 
> ---
>  src/glsl/ast_array_index.cpp | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/src/glsl/ast_array_index.cpp b/src/glsl/ast_array_index.cpp
> index ff0c757..ecef651 100644
> --- a/src/glsl/ast_array_index.cpp
> +++ b/src/glsl/ast_array_index.cpp
> @@ -83,11 +83,9 @@ update_max_array_access(ir_rvalue *ir, int idx, YYLTYPE 
> *loc,
>  
>if (deref_var != NULL) {
>   if (deref_var->var->is_interface_instance()) {
> -const glsl_type *interface_type =
> -   deref_var->var->get_interface_type();
>  unsigned field_index =
> deref_record->record->type->field_index(deref_record->field);
> -assert(field_index < interface_type->length);
> +assert(field_index < 
> deref_var->var->get_interface_type()->length);
>  
>  unsigned *const max_ifc_array_access =
> deref_var->var->get_max_ifc_array_access();


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH excerpt] mesa: Wrap unlikely() around conditions leading to _mesa_error().

2015-03-04 Thread Kenneth Graunke

On Monday, March 02, 2015 03:03:00 PM Eric Anholt wrote:
> Kenneth Graunke  writes:
> 
> > Generated by the following Coccinelle semantic patch:
> >
> > @@
> > expression E;
> > @@
> > if (
> > -E
> > +unlikely(E)
> >  )
> > { ... _mesa_error(...) ... }
> >
> > Improves performance in OglBatch7 (a CPU-bound microbenchmark) on
> > an i7 4750HQ (Haswell) by 1.08546% +/- 0.519734% (n=292).
> >
> > Signed-off-by: Kenneth Graunke 
> 
> Neat!
> 
> I think you're supposed to be able to get the same result by marking
> _mesa_error as attribute cold.  Then nobody can forget to mark their
> conditions as unlikely in the future.

Oh, neat!  I wasn't aware of __attribute__((cold)).

I tried it out and ran some measurements, this time on Baytrail (since
it should more more sensitive to CPU improvements like this).  Oddly,
the results were different:

attribute cold on _mesa_error: -1.60367% +/- 0.43555%
unlikely on all _mesa_error callers: -2.92994% +/- 0.0632798%

I haven't dug into the assembly yet to try and see why.

(It's also bizarre to me that these /hurt/ performance on Baytrail, on
a CPU-limited microbenchmark that never hits _mesa_error, both with or
without the performance governor set.  More mysteries...)

I'll have to try measuring on Haswell.

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

[Mesa-dev] GSoC 2015 Proposal : Porting Glean tests to piglit

2015-03-04 Thread Juliet Fru

Hello,

Here is my proposal for Adding Porting Glean tests to piglit. I'll like to
get your comments and tweaks.

Thanks,
Juliet
 Porting Glean tests to Piglit framework OPW Proposal


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] nesa-10.4.4: gallivm/lp_bld_misc.cpp:503:38: error: no viable conversion from 'ShaderMemoryManager *' to 'std::unique_ptr'

2015-03-04 Thread Jose Fonseca


On 04/03/15 02:00, Emil Velikov wrote:

On 27 February 2015 at 23:28, Sedat Dilek  wrote:

On Mon, Feb 9, 2015 at 6:30 PM, Emil Velikov  wrote:

On 07/02/15 21:44, Sedat Dilek wrote:

Hi,

I was building mesa v10.4.4 with my llvm-toolchain v3.6.0rc2.

My build breaks like this...

...

Please cherry-pick...

commit ef7e0b39a24966526b102643523feac765771842
"gallivm: Update for RTDyldMemoryManager becoming an unique_ptr."

..for mesa 10.4 Git branch.


Hi Sedat,

Picking a fix in a stable branch against a non-final release sounds like
a no-go in our books. As the official llvm 3.6 rolls out we'll pick this
fix for the stable branches - until then I would recommend (a) applying
it locally or (b) using mesa from the 10.5 or master branch.



Just FYI...

[LLVMdev] LLVM 3.6 Release (see [1]).

Please pick this patch for-10.4, thanks.


As promised, mesa 10.4.6 will feature this.


But is cross-porting this patch enough?

As I said when this first issue was raised fixing the build with LLVM 
3.6 is just half of the problem.  It must also _run_ correctly.  And 
building correctly doesn't necessarily means it will run correctly.




That is, unless somebody actually ensures that all LLVM 3.6 related 
fixes have been crossported and that things run correctly, it is 
misleading to enable the build of Mesa 10.4.6 with LLVM 3.6.


I don't know about radeon drivers, but at least from llvmpipe POV I 
simply don't have the time to do this (go through every LLVM 3.6 related 
patch, ensure they are all in 10.4.6, and test).



I quickly went through the diffs between 10.4 branch, and found one such 
commit is missing:



http://cgit.freedesktop.org/mesa/mesa/commit/?id=74f505fa73eda0c9b5b1984bebb44cedac8e8794
  https://bugs.freedesktop.org/show_bug.cgi?id=85467

But there might be more, and I don't know if crossporting this is safe 
or not.



Therefore my stance for is that building Mesa stable releases with LLVM 
releases after the Mesa release was branched is still unsupported.  If 
people want to do so, they will do at their own peril. And any incoming 
bugs will be "unsupported, use Mesa.



If having a Mesa release capable of building LLVM 3.6 is so important, I 
think it might be easier/safer to just make a new release from a recent 
enough commit, than trying to backport it.



Jose

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] RFC: Prune stale components

2015-03-04 Thread Emil Velikov

On 4 March 2015 at 08:31, Jose Fonseca  wrote:
> On 04/03/15 00:24, Emil Velikov wrote:
>>
>> On 03/03/15 22:04, Jose Fonseca wrote:
>>>
>>> On 03/03/15 18:39, Emil Velikov wrote:

 On 3 March 2015 at 17:16, Jose Fonseca  wrote:
 ...
>
>
> I've prototyped this in
>
>
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Ejrfonseca_mesa_log_-3Fh-3Dremove-2Dst-2Degl&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=DBmTkQmzY89vDw_KLOol0FBhKxmBTyqNfsx_ly5H-ZU&s=zhIQc271rsRkCQHGsaFYKm3SFwRTGWAib63t3Fjdhyo&e=
>
>
> The changes are massive, so I'm not sure it's even worth spamming the
> list
> with them.
>
> Could you please give a look and let me know if there are any concerns?
>
 I've spotted a few trivial bits:

- windows/gdi: Remove.
 Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST
 The driver had interesting api/wrapper similar to osmesa. Did not know
 that :-)

 -  st/egl: Remove.
 Update the src/egl/main/Sconscript to create a SharedLibrary, add
 versioning, create symlink - copy the bits from egl-static.
>>>
>>>
 Drop st/egl and targets/egl-static from
 src/gallium/Makefile.am:EXTRA_DIST
>>>
>>>
 Remove the _EGL_BUILT_IN_DRIVER_GALLIUM define from
 src/egl/main/Android.mk.
- st/vega: Remove.
 A few "openvg" references left - one in configure.ac another one in
 docs/contents.html
>>>
>>>
>>> Thanks. I pushed a new version of the branch with all issues fixed.
>>>
>> I'm guessing you made a typo in src/egl/main/SConscript
>>
>> +egl = env.InstallSharedLibrary(egl, version=(1, 0, 0))
>>
>> Shouldn't the version be 1.4 ?
>
>
> No, it wasn't a typo.  It matches what autotools does now.
>
> I can't say which is more correct 1.0 or 1.4, but it doesn't make sense for
> SCons to do something different than autotools for the exact same code.
>
Nicely spotted. I've naively assumed that we had 1.4 for Autotools.

>>
>>>

> The only snafu is Android.mk -- it will be broken with gallium
> drivers until
> somebody familiar with that infrastructure updates it to use
> egl_dri2. But
> it should build fine without gallium drivers.
>
 The Android build is mostly limping around mesa 10.4. I've pinged the
 Android-x86 guys, but but might get to it soon(ish). Don't worry too
 much about it.

 I'm guessing that the scons and automake build do not point out
 anything unusual ?
>>>
>>>
>>> Right. automake, scons/linux and scons/windows all build happily. Of
>>> course, automake has many options, and I only tested one (with dri and
>>> gallium sw rasterizers).
>>>
>> These components are rather nicely isolated, so it should not matter
>> that much.
>>
>> I'm suspecting that scons does not link against all libs for libEGL.
>
>
> ldd -r build/linux-x86_64-debug/egl/main/libEGL.so is clean.
>
>> Adding -Wl,--no-undefined/-Wl,-z,defs to SHLINKFLAGS should clear it up,
>> yet feel free to do it as a follow up. I would highly recommend adding
>> it (-Wl...) for every SharedLibrary in scons. Using the version scripts
>> like autotools, to restrict the exported symbols, will be great.
>
>
> I'll see what can be done.
>
> Unfortunately (at least in the past) we used to have .so depending on
> symbols from the .so/executable that dlopened it (ie, cyclic dependencies),
> so doing this universally woulddn't be possible. Not sure if that's still
> the case.
>
The only such case in current mesa ought to be the dri modules
(LoadableModule) - both gallium and classic ones. That is for the
Autotools build, cannot say anything for scons.

Thanks again for clearing these up.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] New stable-branch 10.4 candidate pushed

2015-03-04 Thread Emil Velikov

Hello list,

A candidate for the Mesa 10.4.6 release is now available. The current
patch queue is as follows:
 - 16 queued
 - 7 nominated (outstanding)
 - and 0 rejected (obsolete) patches

In a nut shell this gives us a few build fixes, bugfix in libGL for the
GLX_MESA_query_renderer specification. correct handling of saturates for
pre SM 3.0 hardware (r300, nv30) and a few driver specific patches -
radeonsi and i965.

Take a look at section "Mesa stable queue" for more information.

NOTE: This release resolves the build against LLVM 3.6, effectively adding
partial support. Everyone is welcome to use it, but be warned that it's not
fully supported.


Testing
---
The following results are against piglit a68d27e7254.


Changes - classic i965(snb)
---
None.


Changes - swrast classic

Fixes
 - ARB_framebuffer_object
+ fbo-drawbuffers-none glColorMaskIndexed fail > pass
+ fbo-drawbuffers-none gl_FragDatafail > pass

 - ATI_draw_buffers
+ arbfp-no-index  fail > pass
+ ati_draw_buffers-arbfp  fail > pass

 - EXT_framebuffer_object
+ fbo-drawbuffers-arbfp   fail > pass
+ fbo-drawbuffers-blend-add   fail > pass
+ fbo-drawbuffers-maxtargets  fail > pass


Changes - gallium softpipe, llvmpipe (LLVM 3.5.1)

None.


Testing reports/general approval

Any testing reports (or general approval of the state of the branch)
will be greatly appreciated.


Trivial merge conflicts
---
Here are the commits where I manually merged conflicts, so these might
merit additional review:

commit a598a9bdfe9f5d0ed35ca89a55cf74a2b678e8e1
Author: Matt Turner 

mesa: Correct backwards NULL check.

(cherry picked from commit 491d42135ad0e5670756216154f2ba9fc79d4ba7)


commit 39ae85732d29906ea2a16dfdfc77f8e5dbed5853
Author: Eduardo Lima Mitev 

mesa: Fix error validating args for TexSubImage3D

(cherry picked from commit 2aa71e9485a5a062b1bd2dd8bdc081a8fa4c873d)


commit 61c1aabb9f25a6e0710ab6a49a9fb889c4fa7752
Author: Marek Olšák 

radeonsi: fix point sprites

(cherry picked from commit 7820a11e3dea2aca8e2b9b4ed9faf94ff5696990)

Squashed with commit

radeonsi: fix a warning caused by previous commit

(cherry picked from commit 050bf75c8bbaa7cad537aabaf8612129edfee3a4)



The plan is to have 10.4.6 this Friday(6th March).

If you have any questions or comments that you would like to share
before the release, please go ahead.


Cheers,
Emil


Mesa stable queue
-

Nominated (15)
==

Brian Paul (3):
  configure: don't try to build gallium DRI drivers if --disable-dri is set

Daniel Stone (1):
  egl: Report correct GBM formats

Emil Velikov (1):
  mesa: rename format_info.c to format_info.h

Frank Henigman (1):
  intel: fix EGLImage renderbuffer _BaseFormat

Laura Ekstrand (4):
  common: Correct texture init for meta pbo uploads and downloads.
  common: Correct PBO 2D_ARRAY handling.
  main: Fix target checking for CompressedTexSubImage*D.
  main: Fix target checking for CopyTexSubImage*D.

Mario Kleiner (1):
  glx: Handle out-of-sequence swap completion events correctly.

Matt Turner (4):
  mesa: Indent break statements and add a missing one.
  mesa: Free memory allocated for luminance in readpixels.
  r300g: Use PATH_MAX instead of limiting ourselves to 100 chars.
  r300g: Check return value of snprintf().


Queued (16)
===

Abdiel Janulgue (2):
  glsl: Don't optimize min/max into saturate when EmitNoSat is set
  st/mesa: For vertex shaders, don't emit saturate when SM 3.0 is 
unsupported

Andreas Boll (1):
  glx: Fix returned values of GLX_RENDERER_PREFERRED_PROFILE_MESA

Brian Paul (2):
  swrast: fix multiple color buffer writing
  st/mesa: fix sampler view reference counting bug in glDraw/CopyPixels

Chris Forbes (1):
  i965/gs: Check newly-generated GS-out VUE map against correct stage

Eduardo Lima Mitev (1):
  mesa: Fix error validating args for TexSubImage3D

Emil Velikov (1):
  install-lib-links: remove the .install-lib-links file

Jonathan Gray (1):
  auxilary/os: correct sysctl use in os_get_total_physical_memory()

José Fonseca (1):
  gallivm: Update for RTDyldMemoryManager becoming an unique_ptr.

Leo Liu (1):
  st/omx/dec/h264: fix picture out-of-order with poc type 0 v2

Lucas Stach (1):
  install-lib-links: don't depend on .libs directory

Marek Olšák (2):
  vbo: fix an unitialized-variable warning
  radeonsi: fix point sprites

Matt Turner (3):
  glsl: Rewrite and fix min/max to saturate optimization.
  mesa: Correct backwards NULL check.
  i965/fs: Don't use backend_visitor::instructions after creating the CFG.


___
mesa-dev mailing list
mesa-

Re: [Mesa-dev] [PATCH] gallivm: init MM = NULL to silence warning

2015-03-04 Thread Jose Fonseca


On 04/03/15 04:20, Matt Turner wrote:

On Tue, Mar 3, 2015 at 8:07 PM, Brian Paul  wrote:

---
  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp 
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 5210acc..e2578cf 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -493,7 +493,7 @@ 
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
 builder.setMCPU(MCPU);
  #endif

-   ShaderMemoryManager *MM;
+   ShaderMemoryManager *MM = NULL;
 if (useMCJIT) {
  #if HAVE_LLVM > 0x0303
 BaseMemoryManager* JMM = reinterpret_cast(CMM);
--
1.9.1


I'm guessing it's the 'delete MM;' that generates the warning? If so,
shouldn't you just wrap it in #if HAVE_LLVM > ...?

I think MCJIT is the only option in llvm >= 3.6? The code could
probably be trivially refactored to avoid the assert(0) as well.

 From what I can tell, it seems like adding initializers is nearly
always the wrong thing to do.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=eFrgqffTZg-fVfsgBecewE76PU07pVGCehKDjd2rc2Q&s=NmdJuPH44mfwP-iaquREc8ZPTboVxNFpMQhNXlMv2FY&e=



Yes, this is probably related to 
https://bugs.freedesktop.org/show_bug.cgi?id=89387


But unfortunately I haven't found time to catch up with it.

Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: init MM = NULL to silence warning

2015-03-04 Thread Jose Fonseca


On 04/03/15 12:58, Jose Fonseca wrote:

On 04/03/15 04:20, Matt Turner wrote:

On Tue, Mar 3, 2015 at 8:07 PM, Brian Paul  wrote:

---
  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 5210acc..e2578cf 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -493,7 +493,7 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
 builder.setMCPU(MCPU);
  #endif

-   ShaderMemoryManager *MM;
+   ShaderMemoryManager *MM = NULL;
 if (useMCJIT) {
  #if HAVE_LLVM > 0x0303
 BaseMemoryManager* JMM =
reinterpret_cast(CMM);
--
1.9.1


I'm guessing it's the 'delete MM;' that generates the warning? If so,
shouldn't you just wrap it in #if HAVE_LLVM > ...?

I think MCJIT is the only option in llvm >= 3.6? The code could
probably be trivially refactored to avoid the assert(0) as well.

 From what I can tell, it seems like adding initializers is nearly
always the wrong thing to do.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=eFrgqffTZg-fVfsgBecewE76PU07pVGCehKDjd2rc2Q&s=NmdJuPH44mfwP-iaquREc8ZPTboVxNFpMQhNXlMv2FY&e=




Yes, this is probably related to
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D89387&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=QY0p_bDuP-f3LPn9v8UCnsJc9MFPxmK5yIA_AQLYfpk&s=QtRiKhT6OE4Vfm-MYI7OR5SNu_iqhBPIOUnOp_5tmTc&e=

But unfortunately I haven't found time to catch up with it.


On closer look, this is a different issue.  As Matt said, the issue is 
the delete for older LLVM.


That said, `delete NULL` is safe, hence Brian's patch is good.

Jose

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 89387] Double delete in lp_bld_misc.cpp

2015-03-04 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=89387

José Fonseca  changed:

   What|Removed |Added

 QA Contact|mesa-dev@lists.freedesktop. |jfons...@vmware.com
   |org |

--- Comment #1 from José Fonseca  ---
Would this fix it?

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 5210acc..7387ffb 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -502,6 +502,7 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,

 #if HAVE_LLVM >= 0x0306
   
builder.setMCJITMemoryManager(std::unique_ptr(MM));
+   MM = NULL;
 #else
builder.setMCJITMemoryManager(MM);
 #endif

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] scons: Update for the fact that we require GCC 4.2

2015-03-04 Thread Jose Fonseca

---
 scons/gallium.py | 25 ++---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/scons/gallium.py b/scons/gallium.py
index f839758..7533f06 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -369,20 +369,16 @@ def generate(env):
 'HAVE___BUILTIN_FFS',
 'HAVE___BUILTIN_FFSLL',
 'HAVE_FUNC_ATTRIBUTE_FLATTEN',
+# GCC 3.0
+'HAVE_FUNC_ATTRIBUTE_FORMAT',
+'HAVE_FUNC_ATTRIBUTE_PACKED',
+# GCC 3.4
+'HAVE___BUILTIN_CTZ',
+'HAVE___BUILTIN_POPCOUNT',
+'HAVE___BUILTIN_POPCOUNTLL',
+'HAVE___BUILTIN_CLZ',
+'HAVE___BUILTIN_CLZLL',
 ]
-if distutils.version.LooseVersion(ccversion) >= 
distutils.version.LooseVersion('3'):
-cppdefines += [
-'HAVE_FUNC_ATTRIBUTE_FORMAT',
-'HAVE_FUNC_ATTRIBUTE_PACKED',
-]
-if distutils.version.LooseVersion(ccversion) >= 
distutils.version.LooseVersion('3.4'):
-cppdefines += [
-'HAVE___BUILTIN_CTZ',
-'HAVE___BUILTIN_POPCOUNT',
-'HAVE___BUILTIN_POPCOUNTLL',
-'HAVE___BUILTIN_CLZ',
-'HAVE___BUILTIN_CLZLL',
-]
 if distutils.version.LooseVersion(ccversion) >= 
distutils.version.LooseVersion('4.5'):
 cppdefines += ['HAVE___BUILTIN_UNREACHABLE']
 env.Append(CPPDEFINES = cppdefines)
@@ -420,8 +416,7 @@ def generate(env):
 '-m32',
 #'-march=pentium4',
 ]
-if distutils.version.LooseVersion(ccversion) >= 
distutils.version.LooseVersion('4.2') \
-   and platform != 'haiku':
+if platform != 'haiku':
 # NOTE: We need to ensure stack is realigned given that we
 # produce shared objects, and have no control over the stack
 # alignment policy of the application. Therefore we need
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] scons: Use -Werror MSVC compatibility flags per-directory.

2015-03-04 Thread Jose Fonseca

Matching what we already do with autotools builds.
---
 scons/gallium.py| 27 ---
 src/egl/main/SConscript |  2 ++
 src/gallium/auxiliary/SConscript|  4 
 src/gallium/drivers/llvmpipe/SConscript |  2 ++
 src/glsl/SConscript |  2 ++
 src/loader/SConscript   |  2 ++
 src/mapi/glapi/SConscript   |  2 ++
 src/mesa/SConscript |  2 ++
 src/util/SConscript |  2 ++
 9 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/scons/gallium.py b/scons/gallium.py
index c34468f..f839758 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -87,6 +87,25 @@ def createInstallMethods(env):
 env.AddMethod(install_shared_library, 'InstallSharedLibrary')
 
 
+def msvc2013_compat(env):
+if env['gcc']:
+env.Append(CCFLAGS = [
+'-Werror=vla',
+'-Werror=pointer-arith',
+])
+
+def msvc2008_compat(env):
+msvc2013_compat(env)
+if env['gcc']:
+env.Append(CFLAGS = [
+'-Werror=declaration-after-statement',
+])
+
+def createMSVCCompatMethods(env):
+env.AddMethod(msvc2013_compat, 'MSVC2013Compat')
+env.AddMethod(msvc2008_compat, 'MSVC2008Compat')
+
+
 def num_jobs():
 try:
 return int(os.environ['NUMBER_OF_PROCESSORS'])
@@ -443,13 +462,6 @@ def generate(env):
 '-Wmissing-prototypes',
 '-std=gnu99',
 ]
-if distutils.version.LooseVersion(ccversion) >= 
distutils.version.LooseVersion('4.2'):
-ccflags += [
-'-Wpointer-arith',
-]
-cflags += [
-'-Wdeclaration-after-statement',
-]
 if icc:
 cflags += [
 '-std=gnu99',
@@ -617,6 +629,7 @@ def generate(env):
 # Custom builders and methods
 env.Tool('custom')
 createInstallMethods(env)
+createMSVCCompatMethods(env)
 
 env.PkgCheckModules('X11', ['x11', 'xext', 'xdamage', 'xfixes', 'glproto 
>= 1.4.13'])
 env.PkgCheckModules('XCB', ['x11-xcb', 'xcb-glx >= 1.8.1', 'xcb-dri2 >= 
1.8'])
diff --git a/src/egl/main/SConscript b/src/egl/main/SConscript
index 399c020..b4e9b67 100644
--- a/src/egl/main/SConscript
+++ b/src/egl/main/SConscript
@@ -6,6 +6,8 @@ Import('*')
 
 env = env.Clone()
 
+env.MSVC2013Compat()
+
 env.Append(CPPDEFINES = [
 '_EGL_DRIVER_SEARCH_DIR=\\"\\"',
 ])
diff --git a/src/gallium/auxiliary/SConscript b/src/gallium/auxiliary/SConscript
index 6cb6b8c..d5fa880 100644
--- a/src/gallium/auxiliary/SConscript
+++ b/src/gallium/auxiliary/SConscript
@@ -8,6 +8,10 @@ env.Append(CPPPATH = [
 'util',
 ])
 
+env = env.Clone()
+
+env.MSVC2008Compat()
+
 env.CodeGenerate(
 target = 'indices/u_indices_gen.c', 
 script = 'indices/u_indices_gen.py', 
diff --git a/src/gallium/drivers/llvmpipe/SConscript 
b/src/gallium/drivers/llvmpipe/SConscript
index 1bea611..3a51efc 100644
--- a/src/gallium/drivers/llvmpipe/SConscript
+++ b/src/gallium/drivers/llvmpipe/SConscript
@@ -9,6 +9,8 @@ if not env['llvm']:
 
 env = env.Clone()
 
+env.MSVC2008Compat()
+
 llvmpipe = env.ConvenienceLibrary(
target = 'llvmpipe',
source = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
diff --git a/src/glsl/SConscript b/src/glsl/SConscript
index 21c8266..26de455 100644
--- a/src/glsl/SConscript
+++ b/src/glsl/SConscript
@@ -6,6 +6,8 @@ from sys import executable as python_cmd
 
 env = env.Clone()
 
+env.MSVC2013Compat()
+
 env.Prepend(CPPPATH = [
 '#include',
 '#src',
diff --git a/src/loader/SConscript b/src/loader/SConscript
index 359fc18..16d1053 100644
--- a/src/loader/SConscript
+++ b/src/loader/SConscript
@@ -2,6 +2,8 @@ Import('*')
 
 env = env.Clone()
 
+env.MSVC2013Compat()
+
 env.Prepend(CPPPATH = [
 '#include'
 ])
diff --git a/src/mapi/glapi/SConscript b/src/mapi/glapi/SConscript
index 97ebfe6..84a5068 100644
--- a/src/mapi/glapi/SConscript
+++ b/src/mapi/glapi/SConscript
@@ -8,6 +8,8 @@ Import('*')
 
 env = env.Clone()
 
+env.MSVC2013Compat()
+
 env.Append(CPPDEFINES = [
 'MAPI_MODE_UTIL',
 ])
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 62e81ce..d6ff083 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -10,6 +10,8 @@ from sys import executable as python_cmd
 
 env = env.Clone()
 
+env.MSVC2013Compat()
+
 env.Append(CPPPATH = [
 '#/src',
 '#/src/mapi',
diff --git a/src/util/SConscript b/src/util/SConscript
index 84bd7a1..9e4d481 100644
--- a/src/util/SConscript
+++ b/src/util/SConscript
@@ -6,6 +6,8 @@ from sys import executable as python_cmd
 
 env = env.Clone()
 
+env.MSVC2008Compat()
+
 env.Prepend(CPPPATH = [
 '#include',
 '#src',
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] mapi: remove u_compiler.h

2015-03-04 Thread Jose Fonseca


On 04/03/15 04:07, Brian Paul wrote:

Just include c99_compat.h or util/macros.h where needed.
---
  src/mapi/Makefile.sources | 1 -
  src/mapi/entry.h  | 1 -
  src/mapi/glapi/glapi.h| 1 +
  src/mapi/mapi.h   | 2 --
  src/mapi/table.h  | 4 +++-
  src/mapi/u_compiler.h | 7 ---
  src/mapi/u_current.h  | 6 --
  src/mapi/u_execmem.c  | 2 +-
  src/mapi/u_thread.h   | 2 +-
  9 files changed, 10 insertions(+), 16 deletions(-)
  delete mode 100644 src/mapi/u_compiler.h

diff --git a/src/mapi/Makefile.sources b/src/mapi/Makefile.sources
index 41dbb24..a179662 100644
--- a/src/mapi/Makefile.sources
+++ b/src/mapi/Makefile.sources
@@ -15,7 +15,6 @@
  #this mode, compile MAPI_BRIDGE_FILES with MAPI_MODE_BRIDGE defined.

  MAPI_UTIL_FILES = \
-   u_compiler.h \
u_current.c \
u_current.h \
u_execmem.c \
diff --git a/src/mapi/entry.h b/src/mapi/entry.h
index dba1c06..7c8137c 100644
--- a/src/mapi/entry.h
+++ b/src/mapi/entry.h
@@ -28,7 +28,6 @@
  #ifndef _ENTRY_H_
  #define _ENTRY_H_

-#include "u_compiler.h"

  typedef void (*mapi_func)(void);

diff --git a/src/mapi/glapi/glapi.h b/src/mapi/glapi/glapi.h
index e2fa925..e3f76b4 100644
--- a/src/mapi/glapi/glapi.h
+++ b/src/mapi/glapi/glapi.h
@@ -44,6 +44,7 @@
  #ifndef _GLAPI_H
  #define _GLAPI_H

+#include "util/macros.h"
  #include "u_thread.h"


diff --git a/src/mapi/mapi.h b/src/mapi/mapi.h
index 2aa8d9f..9adf8b5 100644
--- a/src/mapi/mapi.h
+++ b/src/mapi/mapi.h
@@ -28,8 +28,6 @@
  #ifndef _MAPI_H_
  #define _MAPI_H_

-#include "u_compiler.h"
-
  #ifdef _WIN32
  #ifdef MAPI_DLL_EXPORTS
  #define MAPI_EXPORT __declspec(dllexport)
diff --git a/src/mapi/table.h b/src/mapi/table.h
index 8180db9..e2d6ef0 100644
--- a/src/mapi/table.h
+++ b/src/mapi/table.h
@@ -28,7 +28,7 @@
  #ifndef _TABLE_H_
  #define _TABLE_H_

-#include "u_compiler.h"
+#include "c99_compat.h"
  #include "entry.h"

  #define MAPI_TMP_TABLE
@@ -37,6 +37,8 @@
  #define MAPI_TABLE_NUM_SLOTS (MAPI_TABLE_NUM_STATIC + MAPI_TABLE_NUM_DYNAMIC)
  #define MAPI_TABLE_SIZE (MAPI_TABLE_NUM_SLOTS * sizeof(mapi_func))

+struct mapi_table;
+
  extern const mapi_func table_noop_array[];

  /**
diff --git a/src/mapi/u_compiler.h b/src/mapi/u_compiler.h
deleted file mode 100644
index cd80f68..000
--- a/src/mapi/u_compiler.h
+++ /dev/null
@@ -1,7 +0,0 @@
-#ifndef _U_COMPILER_H_
-#define _U_COMPILER_H_
-
-#include "c99_compat.h" /* inline, __func__, etc. */
-#include "util/macros.h"
-
-#endif /* _U_COMPILER_H_ */
diff --git a/src/mapi/u_current.h b/src/mapi/u_current.h
index 252e696..ea4f817 100644
--- a/src/mapi/u_current.h
+++ b/src/mapi/u_current.h
@@ -1,6 +1,10 @@
  #ifndef _U_CURRENT_H_
  #define _U_CURRENT_H_

+#include "c99_compat.h"
+#include "util/macros.h"
+
+
  #if defined(MAPI_MODE_UTIL) || defined(MAPI_MODE_GLAPI) || \
  defined(MAPI_MODE_BRIDGE)

@@ -24,8 +28,6 @@

  #else /* MAPI_MODE_UTIL || MAPI_MODE_GLAPI || MAPI_MODE_BRIDGE */

-#include "u_compiler.h"
-
  struct mapi_table;

  #ifdef GLX_USE_TLS
diff --git a/src/mapi/u_execmem.c b/src/mapi/u_execmem.c
index ac1cae0..ad6427b 100644
--- a/src/mapi/u_execmem.c
+++ b/src/mapi/u_execmem.c
@@ -32,7 +32,7 @@
   */


-#include "u_compiler.h"
+#include "c99_compat.h"
  #include "u_thread.h"
  #include "u_execmem.h"

diff --git a/src/mapi/u_thread.h b/src/mapi/u_thread.h
index 3cd07b5..4dd9515 100644
--- a/src/mapi/u_thread.h
+++ b/src/mapi/u_thread.h
@@ -44,7 +44,7 @@

  #include 
  #include 
-#include "u_compiler.h"
+#include "c99_compat.h"

  #include "c11/threads.h"




Series looks good to me.

Reviewed-by: Jose Fonseca 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] softpipe, trace: Set MSVC 2008 compat flags.

2015-03-04 Thread Jose Fonseca

Although we don't deploy these, we need to use them for debugging.
---
 src/gallium/drivers/softpipe/Makefile.am | 3 ++-
 src/gallium/drivers/softpipe/SConscript  | 1 +
 src/gallium/drivers/trace/Makefile.am| 3 ++-
 src/gallium/drivers/trace/SConscript | 2 ++
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/softpipe/Makefile.am 
b/src/gallium/drivers/softpipe/Makefile.am
index 20f11f8..05126a5 100644
--- a/src/gallium/drivers/softpipe/Makefile.am
+++ b/src/gallium/drivers/softpipe/Makefile.am
@@ -24,7 +24,8 @@ include Makefile.sources
 include $(top_srcdir)/src/gallium/Automake.inc
 
 AM_CFLAGS = \
-   $(GALLIUM_DRIVER_CFLAGS)
+   $(GALLIUM_DRIVER_CFLAGS) \
+   $(MSVC2008_COMPAT_CFLAGS)
 
 noinst_LTLIBRARIES = libsoftpipe.la
 
diff --git a/src/gallium/drivers/softpipe/SConscript 
b/src/gallium/drivers/softpipe/SConscript
index 6768cbb..dc3542c 100644
--- a/src/gallium/drivers/softpipe/SConscript
+++ b/src/gallium/drivers/softpipe/SConscript
@@ -2,6 +2,7 @@ Import('*')
 
 env = env.Clone()
 
+env.MSVC2008Compat()
 
 softpipe = env.ConvenienceLibrary(
target = 'softpipe',
diff --git a/src/gallium/drivers/trace/Makefile.am 
b/src/gallium/drivers/trace/Makefile.am
index db7b449..6a8a74a 100644
--- a/src/gallium/drivers/trace/Makefile.am
+++ b/src/gallium/drivers/trace/Makefile.am
@@ -2,7 +2,8 @@ include Makefile.sources
 include $(top_srcdir)/src/gallium/Automake.inc
 
 AM_CFLAGS = \
-   $(GALLIUM_DRIVER_CFLAGS)
+   $(GALLIUM_DRIVER_CFLAGS) \
+   $(MSVC2008_COMPAT_CFLAGS)
 
 noinst_LTLIBRARIES = libtrace.la
 
diff --git a/src/gallium/drivers/trace/SConscript 
b/src/gallium/drivers/trace/SConscript
index 7341d1c..1bbed73 100644
--- a/src/gallium/drivers/trace/SConscript
+++ b/src/gallium/drivers/trace/SConscript
@@ -2,6 +2,8 @@ Import('*')
 
 env = env.Clone()
 
+env.MSVC2008Compat()
+
 trace = env.ConvenienceLibrary(
 target = 'trace',
 source = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4] svga: Set MSVC2013 compat flags.

2015-03-04 Thread Jose Fonseca

---
 src/gallium/drivers/svga/Makefile.am | 3 ++-
 src/gallium/drivers/svga/SConscript  | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/svga/Makefile.am 
b/src/gallium/drivers/svga/Makefile.am
index 50d44cf..e0a8cad 100644
--- a/src/gallium/drivers/svga/Makefile.am
+++ b/src/gallium/drivers/svga/Makefile.am
@@ -26,7 +26,8 @@ include Makefile.sources
 include $(top_srcdir)/src/gallium/Automake.inc
 
 AM_CFLAGS = \
-   $(GALLIUM_DRIVER_CFLAGS)
+   $(GALLIUM_DRIVER_CFLAGS) \
+   $(MSVC2013_COMPAT_CFLAGS)
 
 #On some systems -std= must be added to CFLAGS to be the last -std=
 CFLAGS += -std=gnu99
diff --git a/src/gallium/drivers/svga/SConscript 
b/src/gallium/drivers/svga/SConscript
index 2051a3e..bb4d034 100644
--- a/src/gallium/drivers/svga/SConscript
+++ b/src/gallium/drivers/svga/SConscript
@@ -2,6 +2,8 @@ Import('*')
 
 env = env.Clone()
 
+env.MSVC2013Compat()
+
 if env['suncc']:
print 'warning: not building svga'
Return()
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] i965/skl: Disable SIMD16 when 3-source instructions are used

2015-03-04 Thread Neil Roberts

Stepping C0 of Skylake fails when using SIMD16 with 3-source
instructions (such as MAD). This patch just makes it disable SIMD16 in
that case.

This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
tests.
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 21 +
 src/mesa/drivers/dri/i965/brw_fs.h   |  1 +
 2 files changed, 22 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 533feb4..62f29e5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3729,6 +3729,26 @@ fs_visitor::fixup_3src_null_dest()
}
 }
 
+/**
+ * 3-source instructions don't work on Skylake stepping C0. If the revision
+ * isn't known then it will take the safe option and disable it in case it's
+ * C0. Implements WaDisableSIMD16On3SrcInstr.
+ */
+void
+fs_visitor::disable_simd16_with_3src()
+{
+   if (brw->gen != 9 || (brw->revision != 2 && brw->revision != -1))
+  return;
+
+   foreach_block_and_inst_safe (block, fs_inst, inst, cfg) {
+  if (inst->is_3src()) {
+ no16("SIMD16 doesn't work with 3-source instructions on "
+  "Gen9 stepping C0\n");
+ return;
+  }
+   }
+}
+
 void
 fs_visitor::allocate_registers()
 {
@@ -3910,6 +3930,7 @@ fs_visitor::run_fs()
   assign_urb_setup();
 
   fixup_3src_null_dest();
+  disable_simd16_with_3src();
   allocate_registers();
 
   if (failed)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
b/src/mesa/drivers/dri/i965/brw_fs.h
index 70098d8..7091b9f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -196,6 +196,7 @@ public:
void setup_payload_gen6();
void setup_vs_payload();
void fixup_3src_null_dest();
+   void disable_simd16_with_3src();
void assign_curb_setup();
void calculate_urb_setup();
void assign_urb_setup();
-- 
1.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] i965: Store the GPU revision number in brw_context

2015-03-04 Thread Neil Roberts

brwContextInit now queries the GPU revision number via a new parameter
for DRM_I915_GETPARAM. This new parameter requires a kernel patch and
a patch to libdrm. If the kernel doesn't support it then it will
continue but set the revision number to -1. The intention is to use
this to implement workarounds that are only needed on certain
steppings of the GPU.
---
 configure.ac|  2 +-
 src/mesa/drivers/dri/i965/brw_context.c | 19 +++
 src/mesa/drivers/dri/i965/brw_context.h |  4 
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index c5abbfd..23ac927 100644
--- a/configure.ac
+++ b/configure.ac
@@ -61,7 +61,7 @@ AC_SUBST([OSMESA_VERSION])
 dnl Versions for external dependencies
 LIBDRM_REQUIRED=2.4.38
 LIBDRM_RADEON_REQUIRED=2.4.56
-LIBDRM_INTEL_REQUIRED=2.4.52
+LIBDRM_INTEL_REQUIRED=2.4.59
 LIBDRM_NVVIEUX_REQUIRED=2.4.33
 LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
 LIBDRM_FREEDRENO_REQUIRED=2.4.57
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 786e6f5..18f72d8 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -651,6 +651,24 @@ brw_process_driconf_options(struct brw_context *brw)
   driQueryOptionb(options, "allow_glsl_extension_directive_midshader");
 }
 
+static int
+brw_get_revision(int fd)
+{
+   struct drm_i915_getparam gp;
+   int revision;
+   int ret;
+
+   memset(&gp, 0, sizeof(gp));
+   gp.param = I915_PARAM_REVISION;
+   gp.value = &revision;
+
+   ret = drmCommandWriteRead(fd, DRM_I915_GETPARAM, &gp, sizeof(gp));
+   if (ret)
+  revision = -1;
+
+   return revision;
+}
+
 GLboolean
 brwCreateContext(gl_api api,
 const struct gl_config *mesaVis,
@@ -709,6 +727,7 @@ brwCreateContext(gl_api api,
brw->has_negative_rhw_bug = devinfo->has_negative_rhw_bug;
brw->needs_unlit_centroid_workaround =
   devinfo->needs_unlit_centroid_workaround;
+   brw->revision = brw_get_revision(sPriv->fd);
 
brw->must_use_separate_stencil = screen->hw_must_use_separate_stencil;
brw->has_swizzling = screen->hw_has_swizzling;
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 682fbe9..10e8274 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1064,6 +1064,10 @@ struct brw_context
 
int gen;
int gt;
+   /* GT revision. This will be -1 if the revision couldn't be determined (eg,
+* if the kernel doesn't support the query).
+*/
+   int revision;
 
bool is_g4x;
bool is_baytrail;
-- 
1.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965/skl: Disable SIMD16 when 3-source instructions are used

2015-03-04 Thread Ilia Mirkin

On Wed, Mar 4, 2015 at 9:33 AM, Neil Roberts  wrote:
> Stepping C0 of Skylake fails when using SIMD16 with 3-source
> instructions (such as MAD). This patch just makes it disable SIMD16 in
> that case.
>
> This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
> tests.

Just curious -- is this faster than lowering MAD into MUL + ADD but
staying in SIMD16? (Should be fairly easy to implement as a post-RA
fixup I'd think, although not totally familiar with how the i965
compiler works.)

  -ilia

> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 21 +
>  src/mesa/drivers/dri/i965/brw_fs.h   |  1 +
>  2 files changed, 22 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 533feb4..62f29e5 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -3729,6 +3729,26 @@ fs_visitor::fixup_3src_null_dest()
> }
>  }
>
> +/**
> + * 3-source instructions don't work on Skylake stepping C0. If the revision
> + * isn't known then it will take the safe option and disable it in case it's
> + * C0. Implements WaDisableSIMD16On3SrcInstr.
> + */
> +void
> +fs_visitor::disable_simd16_with_3src()
> +{
> +   if (brw->gen != 9 || (brw->revision != 2 && brw->revision != -1))
> +  return;
> +
> +   foreach_block_and_inst_safe (block, fs_inst, inst, cfg) {
> +  if (inst->is_3src()) {
> + no16("SIMD16 doesn't work with 3-source instructions on "
> +  "Gen9 stepping C0\n");
> + return;
> +  }
> +   }
> +}
> +
>  void
>  fs_visitor::allocate_registers()
>  {
> @@ -3910,6 +3930,7 @@ fs_visitor::run_fs()
>assign_urb_setup();
>
>fixup_3src_null_dest();
> +  disable_simd16_with_3src();
>allocate_registers();
>
>if (failed)
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index 70098d8..7091b9f 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
> @@ -196,6 +196,7 @@ public:
> void setup_payload_gen6();
> void setup_vs_payload();
> void fixup_3src_null_dest();
> +   void disable_simd16_with_3src();
> void assign_curb_setup();
> void calculate_urb_setup();
> void assign_urb_setup();
> --
> 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

Re: [Mesa-dev] [PATCH] configure: ax_check_python_mako_module.m4 sets output variable

2015-03-04 Thread Kai Wasserbäch

Samuel Iglesias Gonsálvez wrote on 04.03.2015 07:54:
> On Tue, 2015-03-03 at 16:50 +0100, Kai Wasserbäch wrote:
>> Samuel Iglesias Gonsalvez wrote on 03.03.2015 08:56:
>>> This output variables gives more flexibility for future changes
>>> in autoconf to detect if it is needed to auto-generate files and
>>> check for the auto-generation dependencies.
>>>
>>> It is still returning error when Python is not installed.
>>>
>>> Signed-off-by: Samuel Iglesias Gonsalvez 
>>> ---
>>>  configure.ac  | 9 -
>>>  m4/ax_check_python_mako_module.m4 | 4 ++--
>>>  2 files changed, 10 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 2ba79ef..ff7d6c9 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -114,7 +114,14 @@ if test "x$INDENT" != "xcat"; then
>>>  fi
>>>  fi
>>>  
>>> -AX_CHECK_PYTHON_MAKO_MODULE(0.3.4)
>>> +PYTHON_MAKO_REQUIRED=0.3.4
>>
>> Can you put that up into the section where all the other minimum versions are
>> defined? That would be more consistent.
>>
> 
> Yeah, I'll do it. Has this patch your R-b with this change?

Sure:
  Reviewed-by: Kai Wasserbäch 

Bonus nit: can we change the subject to something like:
 configure: Introduce new output variable to ax_check_python_mako_module.m4

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: ax_check_python_mako_module.m4 sets output variable

2015-03-04 Thread Samuel Iglesias Gonsálvez

On Wed, 2015-03-04 at 15:35 +0100, Kai Wasserbäch wrote:
> Samuel Iglesias Gonsálvez wrote on 04.03.2015 07:54:
> > On Tue, 2015-03-03 at 16:50 +0100, Kai Wasserbäch wrote:
> >> Samuel Iglesias Gonsalvez wrote on 03.03.2015 08:56:
> >>> This output variables gives more flexibility for future changes
> >>> in autoconf to detect if it is needed to auto-generate files and
> >>> check for the auto-generation dependencies.
> >>>
> >>> It is still returning error when Python is not installed.
> >>>
> >>> Signed-off-by: Samuel Iglesias Gonsalvez 
> >>> ---
> >>>  configure.ac  | 9 -
> >>>  m4/ax_check_python_mako_module.m4 | 4 ++--
> >>>  2 files changed, 10 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/configure.ac b/configure.ac
> >>> index 2ba79ef..ff7d6c9 100644
> >>> --- a/configure.ac
> >>> +++ b/configure.ac
> >>> @@ -114,7 +114,14 @@ if test "x$INDENT" != "xcat"; then
> >>>  fi
> >>>  fi
> >>>  
> >>> -AX_CHECK_PYTHON_MAKO_MODULE(0.3.4)
> >>> +PYTHON_MAKO_REQUIRED=0.3.4
> >>
> >> Can you put that up into the section where all the other minimum versions 
> >> are
> >> defined? That would be more consistent.
> >>
> > 
> > Yeah, I'll do it. Has this patch your R-b with this change?
> 
> Sure:
>   Reviewed-by: Kai Wasserbäch 
> 
> Bonus nit: can we change the subject to something like:
>  configure: Introduce new output variable to ax_check_python_mako_module.m4
> 

OK.

Thanks!

Sam



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/2] i965/skl: Disable SIMD16 when 3-source instructions are used

2015-03-04 Thread Neil Roberts

Ilia Mirkin  writes:

> On Wed, Mar 4, 2015 at 9:33 AM, Neil Roberts  wrote:
>> Stepping C0 of Skylake fails when using SIMD16 with 3-source
>> instructions (such as MAD). This patch just makes it disable SIMD16 in
>> that case.
>>
>> This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
>> tests.
>
> Just curious -- is this faster than lowering MAD into MUL + ADD but
> staying in SIMD16? (Should be fairly easy to implement as a post-RA
> fixup I'd think, although not totally familiar with how the i965
> compiler works.)

I haven't tested it but I think you're right that it would probably be
faster to lower the instruction. However that sounds like more work and
it's only relevant for a limited set of hardware so it doesn't seem
worth doing. I think there are also other 3-source instructions and it
might be more difficult to lower those (although I'm not sure).

Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: init MM = NULL to silence warning

2015-03-04 Thread Brian Paul


On 03/04/2015 07:08 AM, Jose Fonseca wrote:

On 04/03/15 12:58, Jose Fonseca wrote:

On 04/03/15 04:20, Matt Turner wrote:

On Tue, Mar 3, 2015 at 8:07 PM, Brian Paul  wrote:

---
  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index 5210acc..e2578cf 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
@@ -493,7 +493,7 @@
lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
 builder.setMCPU(MCPU);
  #endif

-   ShaderMemoryManager *MM;
+   ShaderMemoryManager *MM = NULL;
 if (useMCJIT) {
  #if HAVE_LLVM > 0x0303
 BaseMemoryManager* JMM =
reinterpret_cast(CMM);
--
1.9.1


I'm guessing it's the 'delete MM;' that generates the warning? If so,
shouldn't you just wrap it in #if HAVE_LLVM > ...?

I think MCJIT is the only option in llvm >= 3.6? The code could
probably be trivially refactored to avoid the assert(0) as well.

 From what I can tell, it seems like adding initializers is nearly
always the wrong thing to do.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=eFrgqffTZg-fVfsgBecewE76PU07pVGCehKDjd2rc2Q&s=NmdJuPH44mfwP-iaquREc8ZPTboVxNFpMQhNXlMv2FY&e=





Yes, this is probably related to
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D89387&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=QY0p_bDuP-f3LPn9v8UCnsJc9MFPxmK5yIA_AQLYfpk&s=QtRiKhT6OE4Vfm-MYI7OR5SNu_iqhBPIOUnOp_5tmTc&e=


But unfortunately I haven't found time to catch up with it.


On closer look, this is a different issue.  As Matt said, the issue is
the delete for older LLVM.

That said, `delete NULL` is safe, hence Brian's patch is good.


I think this is simplest.  Matt, if you look at the rest of the 
neighboring code, MM gets assigned (basically) if (using MCJIT and llvm 
>= 303) or llvm < 306 so it's kind of complex condition.  Just init'int 
to null is the simplest solution.


I'll take Jose's comment as an R-b.

-Brian


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] scons: Use -Werror MSVC compatibility flags per-directory.

2015-03-04 Thread Brian Paul


Series LGTM.  Reviewed-by: Brian Paul 

On 03/04/2015 07:27 AM, Jose Fonseca wrote:

Matching what we already do with autotools builds.
---
  scons/gallium.py| 27 ---
  src/egl/main/SConscript |  2 ++
  src/gallium/auxiliary/SConscript|  4 
  src/gallium/drivers/llvmpipe/SConscript |  2 ++
  src/glsl/SConscript |  2 ++
  src/loader/SConscript   |  2 ++
  src/mapi/glapi/SConscript   |  2 ++
  src/mesa/SConscript |  2 ++
  src/util/SConscript |  2 ++
  9 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/scons/gallium.py b/scons/gallium.py
index c34468f..f839758 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -87,6 +87,25 @@ def createInstallMethods(env):
  env.AddMethod(install_shared_library, 'InstallSharedLibrary')


+def msvc2013_compat(env):
+if env['gcc']:
+env.Append(CCFLAGS = [
+'-Werror=vla',
+'-Werror=pointer-arith',
+])
+
+def msvc2008_compat(env):
+msvc2013_compat(env)
+if env['gcc']:
+env.Append(CFLAGS = [
+'-Werror=declaration-after-statement',
+])
+
+def createMSVCCompatMethods(env):
+env.AddMethod(msvc2013_compat, 'MSVC2013Compat')
+env.AddMethod(msvc2008_compat, 'MSVC2008Compat')
+
+
  def num_jobs():
  try:
  return int(os.environ['NUMBER_OF_PROCESSORS'])
@@ -443,13 +462,6 @@ def generate(env):
  '-Wmissing-prototypes',
  '-std=gnu99',
  ]
-if distutils.version.LooseVersion(ccversion) >= 
distutils.version.LooseVersion('4.2'):
-ccflags += [
-'-Wpointer-arith',
-]
-cflags += [
-'-Wdeclaration-after-statement',
-]
  if icc:
  cflags += [
  '-std=gnu99',
@@ -617,6 +629,7 @@ def generate(env):
  # Custom builders and methods
  env.Tool('custom')
  createInstallMethods(env)
+createMSVCCompatMethods(env)

  env.PkgCheckModules('X11', ['x11', 'xext', 'xdamage', 'xfixes', 'glproto 
>= 1.4.13'])
  env.PkgCheckModules('XCB', ['x11-xcb', 'xcb-glx >= 1.8.1', 'xcb-dri2 >= 
1.8'])
diff --git a/src/egl/main/SConscript b/src/egl/main/SConscript
index 399c020..b4e9b67 100644
--- a/src/egl/main/SConscript
+++ b/src/egl/main/SConscript
@@ -6,6 +6,8 @@ Import('*')

  env = env.Clone()

+env.MSVC2013Compat()
+
  env.Append(CPPDEFINES = [
  '_EGL_DRIVER_SEARCH_DIR=\\"\\"',
  ])
diff --git a/src/gallium/auxiliary/SConscript b/src/gallium/auxiliary/SConscript
index 6cb6b8c..d5fa880 100644
--- a/src/gallium/auxiliary/SConscript
+++ b/src/gallium/auxiliary/SConscript
@@ -8,6 +8,10 @@ env.Append(CPPPATH = [
  'util',
  ])

+env = env.Clone()
+
+env.MSVC2008Compat()
+
  env.CodeGenerate(
  target = 'indices/u_indices_gen.c',
  script = 'indices/u_indices_gen.py',
diff --git a/src/gallium/drivers/llvmpipe/SConscript 
b/src/gallium/drivers/llvmpipe/SConscript
index 1bea611..3a51efc 100644
--- a/src/gallium/drivers/llvmpipe/SConscript
+++ b/src/gallium/drivers/llvmpipe/SConscript
@@ -9,6 +9,8 @@ if not env['llvm']:

  env = env.Clone()

+env.MSVC2008Compat()
+
  llvmpipe = env.ConvenienceLibrary(
target = 'llvmpipe',
source = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
diff --git a/src/glsl/SConscript b/src/glsl/SConscript
index 21c8266..26de455 100644
--- a/src/glsl/SConscript
+++ b/src/glsl/SConscript
@@ -6,6 +6,8 @@ from sys import executable as python_cmd

  env = env.Clone()

+env.MSVC2013Compat()
+
  env.Prepend(CPPPATH = [
  '#include',
  '#src',
diff --git a/src/loader/SConscript b/src/loader/SConscript
index 359fc18..16d1053 100644
--- a/src/loader/SConscript
+++ b/src/loader/SConscript
@@ -2,6 +2,8 @@ Import('*')

  env = env.Clone()

+env.MSVC2013Compat()
+
  env.Prepend(CPPPATH = [
  '#include'
  ])
diff --git a/src/mapi/glapi/SConscript b/src/mapi/glapi/SConscript
index 97ebfe6..84a5068 100644
--- a/src/mapi/glapi/SConscript
+++ b/src/mapi/glapi/SConscript
@@ -8,6 +8,8 @@ Import('*')

  env = env.Clone()

+env.MSVC2013Compat()
+
  env.Append(CPPDEFINES = [
  'MAPI_MODE_UTIL',
  ])
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 62e81ce..d6ff083 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -10,6 +10,8 @@ from sys import executable as python_cmd

  env = env.Clone()

+env.MSVC2013Compat()
+
  env.Append(CPPPATH = [
  '#/src',
  '#/src/mapi',
diff --git a/src/util/SConscript b/src/util/SConscript
index 84bd7a1..9e4d481 100644
--- a/src/util/SConscript
+++ b/src/util/SConscript
@@ -6,6 +6,8 @@ from sys import executable as python_cmd

  env = env.Clone()

+env.MSVC2008Compat()
+
  env.Prepend(CPPPATH = [
  '#include',
  '#src',



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailm

Re: [Mesa-dev] [PATCH 2/6] i965/fs: Silence unused parameter warning

2015-03-04 Thread Ian Romanick

On 03/01/2015 05:19 PM, Jason Ekstrand wrote:
> Not sure why you Cc'd me, but whatever.  Seems obvious enough.

Because b18fd23 was your commit.  Sometimes left over, unused parameters
are the result of a mistake.  I just wanted to be sure.

> Reviewed-by: Jason Ekstrand 
> On 02/27/2015 06:50 PM, Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> Unused since b18fd23.
>>
>> brw_fs.cpp:2878:44: warning: unused parameter 'dispatch_width'
>> [-Wunused-parameter]
>>   clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
>>  ^
>>
>> Signed-off-by: Ian Romanick 
>> Cc: Jason Ekstrand 
>> ---
>>   src/mesa/drivers/dri/i965/brw_fs.cpp | 12 
>>   1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> index 0354f56..126b7d0 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> @@ -2875,8 +2875,7 @@ fs_visitor::remove_duplicate_mrf_writes()
>>   }
>> static void
>> -clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
>> -int first_grf, int grf_len)
>> +clear_deps_for_inst_src(fs_inst *inst, bool *deps, int first_grf, int
>> grf_len)
>>   {
>>  /* Clear the flag for registers that actually got read (as
>> expected). */
>>  for (int i = 0; i < inst->sources; i++) {
>> @@ -2927,8 +2926,7 @@
>> fs_visitor::insert_gen4_pre_send_dependency_workarounds(bblock_t *block,
>>  memset(needs_dep, false, sizeof(needs_dep));
>>  memset(needs_dep, true, write_len);
>>   -   clear_deps_for_inst_src(inst, dispatch_width,
>> -   needs_dep, first_write_grf, write_len);
>> +   clear_deps_for_inst_src(inst, needs_dep, first_write_grf, write_len);
>>/* Walk backwards looking for writes to registers we're writing
>> which
>>   * aren't read since being written.  If we hit the start of the
>> program,
>> @@ -2968,8 +2966,7 @@
>> fs_visitor::insert_gen4_pre_send_dependency_workarounds(bblock_t *block,
>> }
>>   /* Clear the flag for registers that actually got read (as
>> expected). */
>> -  clear_deps_for_inst_src(scan_inst, dispatch_width,
>> -  needs_dep, first_write_grf, write_len);
>> +  clear_deps_for_inst_src(scan_inst, needs_dep, first_write_grf,
>> write_len);
>>   /* Continue the loop only if we haven't resolved all the
>> dependencies */
>> int i;
>> @@ -3014,8 +3011,7 @@
>> fs_visitor::insert_gen4_post_send_dependency_workarounds(bblock_t
>> *block, fs_ins
>> }
>>   /* Clear the flag for registers that actually got read (as
>> expected). */
>> -  clear_deps_for_inst_src(scan_inst, dispatch_width,
>> -  needs_dep, first_write_grf, write_len);
>> +  clear_deps_for_inst_src(scan_inst, needs_dep, first_write_grf,
>> write_len);
>>   /* We insert our reads as late as possible since they're
>> reading the
>>  * result of a SEND, which has massive latency.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/6] i965: Silence unused parameter warning

2015-03-04 Thread Ian Romanick

On 02/28/2015 10:33 AM, Ilia Mirkin wrote:
> On Sat, Feb 28, 2015 at 1:26 PM, Carl Worth  wrote:
>> On Fri, Feb 27 2015, Ian Romanick wrote:
>>> All dd functions take a gl_context as the first parameter.  Instead of
>>> removing it, just silence the warning.
>>
>> For code using gcc, I really prefer the __attribute__((__unused__))
>> style, (though, obviously hidden in a reasonable looking macro). That
>> results in cleaner looking code than these weird unused expressions
>> being cast to void.
> 
> Another clean alternative is to leave the name of the variable out, i.e.
> 
> function(struct gl_context *)
> 
> instead of
> 
> function(struct gl_context *foo)

I use that method a lot because it makes the intention very obvious,
but, as others have mentioned, it's only available in C++.

>> Does MSVC have an equivalent? Or, does it not emit the warning in the
>> first place such that we could just define the macro as empty outside of
>> gcc?
>>
>> So there's room for investigation here. In the meantime:
>>
>> Reviewed-by: Carl Worth 
>>
>> -Carl
>>
>> ___
>> 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] clover: Enable cl_khr_fp64 for devices that support doubles v4

2015-03-04 Thread Tom Stellard

v2:
  - Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE
and CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
  - Only define cl_khr_fp64 if the extension is supported.
  - Remove trailing space from extension string.
  - Rename device query function from cl_khr_fp86() to
has_doubles().

v3:
  - Return 0 for device::doubled_fp_confg() when doubles aren't
supported.

v4:
  - Remove device query for double fp_config.
---
 src/gallium/state_trackers/clover/api/device.cpp  | 21 ++---
 src/gallium/state_trackers/clover/core/device.cpp |  6 ++
 src/gallium/state_trackers/clover/core/device.hpp |  1 +
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index e825468..b1f556f 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -145,7 +145,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE:
-  buf.as_scalar() = 2;
+  buf.as_scalar() = dev.has_doubles() ? 2 : 0;
   break;
 
case CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF:
@@ -205,6 +205,21 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
  CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
   break;
 
+   case CL_DEVICE_DOUBLE_FP_CONFIG:
+  if (dev.has_doubles())
+ // This is the "mandated minimum double precision floating-point
+ // capability"
+ buf.as_scalar() =
+   CL_FP_FMA
+ | CL_FP_ROUND_TO_NEAREST
+ | CL_FP_ROUND_TO_ZERO
+ | CL_FP_ROUND_TO_INF
+ | CL_FP_INF_NAN
+ | CL_FP_DENORM;
+  else
+ buf.as_scalar() = 0;
+  break;
+
case CL_DEVICE_GLOBAL_MEM_CACHE_TYPE:
   buf.as_scalar() = CL_NONE;
   break;
@@ -283,7 +298,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_EXTENSIONS:
-  buf.as_string() = "";
+  buf.as_string() = dev.has_doubles() ? "cl_khr_fp64" : "";
   break;
 
case CL_DEVICE_PLATFORM:
@@ -315,7 +330,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE:
-  buf.as_scalar() = 2;
+  buf.as_scalar() = dev.has_doubles() ? 2 : 0;
   break;
 
case CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF:
diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
b/src/gallium/state_trackers/clover/core/device.cpp
index 688a7dd..c3f3b4e 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -173,6 +173,12 @@ device::image_support() const {
   PIPE_COMPUTE_CAP_IMAGES_SUPPORTED)[0];
 }
 
+bool
+device::has_doubles() const {
+   return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
+ PIPE_SHADER_CAP_DOUBLES);
+}
+
 std::vector
 device::max_block_size() const {
auto v = get_compute_param(pipe, PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE);
diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
b/src/gallium/state_trackers/clover/core/device.hpp
index 2201700..de5fc6b 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -64,6 +64,7 @@ namespace clover {
   cl_uint max_clock_frequency() const;
   cl_uint max_compute_units() const;
   bool image_support() const;
+  bool has_doubles() const;
 
   std::vector max_block_size() const;
   std::string device_name() const;
-- 
2.0.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: init MM = NULL to silence warning

2015-03-04 Thread Mark Janes

Hi Brian,

Did you try to `make check` in mesa with these patches?

I get errors compiling glx-test:

src/glx/glxclient.h:59:25: fatal error: util/macros.h: No such file or
directory

-Mark

Brian Paul  writes:

> ---
>  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp 
> b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> index 5210acc..e2578cf 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> @@ -493,7 +493,7 @@ 
> lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT,
> builder.setMCPU(MCPU);
>  #endif
>  
> -   ShaderMemoryManager *MM;
> +   ShaderMemoryManager *MM = NULL;
> if (useMCJIT) {
>  #if HAVE_LLVM > 0x0303
> BaseMemoryManager* JMM = reinterpret_cast(CMM);
> -- 
> 1.9.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] glx/tests: add -I src/ to fix make check

2015-03-04 Thread Brian Paul

---
 src/glx/tests/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/glx/tests/Makefile.am b/src/glx/tests/Makefile.am
index dd82449..b02a9e3 100644
--- a/src/glx/tests/Makefile.am
+++ b/src/glx/tests/Makefile.am
@@ -2,6 +2,7 @@ if HAVE_SHARED_GLAPI
 AM_CFLAGS = $(PTHREAD_CFLAGS)
 AM_CPPFLAGS = \
-I$(top_srcdir)/src/gtest/include \
+   -I$(top_srcdir)/src \
-I$(top_srcdir)/src/mapi \
-I$(top_srcdir)/src/mesa \
-I$(top_srcdir)/src/glx \
-- 
1.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

1 2 >

1 - 100 of 121 matches

Mail list logo