date:20141211

On 10/12/14 15:54, Victor Rodriguez wrote:
[snip]

 Hi thanks a lot for the help
 
 My Mesa is working more than fine , however  I was wondering if you
 think that could be better to just include the correct *drm.h instead
 on the specific function that requires , ie:
 
 static int
 drm_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
 {
 #include radeon_drm.h
 
 Of course it is not a functional code , I just try to say that with
 this new organization each *drm.h might be included  just on the
 function that is required and the libdrm packages could be more slim
 for each architecture ( why should I have a radeon.h file if I do not
 have a readeon card? )
 
The *drm.h files are shipped by libdrm. The latter of which is a hard
requirement for either one of libdrm_{nouveau,intel,radeon...}.
So slimming it down will, imho, only cause the code to be less
readable/pleasant to look at :)

I think you're worrying over nothing here - do you have a concrete
example where it can cause any issues ?


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

Re: [Mesa-dev] [PATCH v3 01/24] mesa/format_utils: Fix a bug in unorm_to_float helper function

2014-12-11 Thread Michel Dänzer

On 11.12.2014 14:50, Jason Ekstrand wrote:
 
 On Dec 10, 2014 8:13 PM, Michel Dänzer mic...@daenzer.net
 mailto:mic...@daenzer.net wrote:

 On 11.12.2014 01:08, Jason Ekstrand wrote:
 
 
  On Tue, Dec 9, 2014 at 10:53 PM, Michel Dänzer mic...@daenzer.net
 mailto:mic...@daenzer.net
  mailto:mic...@daenzer.net mailto:mic...@daenzer.net wrote:
 
  On 09.12.2014 21:06, Iago Toral Quiroga wrote:
   From: Jason Ekstrand jason.ekstr...@intel.com
 mailto:jason.ekstr...@intel.com mailto:jason.ekstr...@intel.com
 mailto:jason.ekstr...@intel.com
  
   This patch fixes the return of a wrong value when x is lower than
   -MAX_INT(src_bits) as the result would not be between [-1.0 1.0].
  
   v2 by Samuel Iglesias sigles...@igalia.com
 mailto:sigles...@igalia.com mailto:sigles...@igalia.com
 mailto:sigles...@igalia.com:
   - Modify unorm_to_float() to avoid doing the division when
 x == -MAX_INT(src_bits)
  
   Reviewed-by: Ian Romanick ian.d.roman...@intel.com
 mailto:ian.d.roman...@intel.com mailto:ian.d.roman...@intel.com
 mailto:ian.d.roman...@intel.com
   ---
src/mesa/main/format_utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
  
   diff --git a/src/mesa/main/format_utils.c
 b/src/mesa/main/format_utils.c
   index 93a0cea..5dd0848 100644
   --- a/src/mesa/main/format_utils.c
   +++ b/src/mesa/main/format_utils.c
   @@ -152,7 +152,7 @@ unorm_to_float(unsigned x, unsigned src_bits)
static inline float
snorm_to_float(int x, unsigned src_bits)
{
   -   if (x == -MAX_INT(src_bits))
   +   if (x = -MAX_INT(src_bits))
  return -1.0f;
   else
  return x * (1.0f / (float)MAX_INT(src_bits));
  
 
  The commit log talks about unorm_to_float, but the code modifies
  snorm_to_float. Also, I think something like
 
  mesa: Fix clamping to -1.0 in snorm_to_float
 
  would be a more useful shortlog.
 
 
  BTW, don't this function and unorm_to_float also need corresponding
  clamping to 1.0 for values = MAX_INT(src_bits)?
 
 
  Yes and no.  Every place that we use [us]norm_to_*, we assume that the
  value passed in is represented by the given number of bits.  Therefore,
  clamping above should always be useless.  The one edge case is the
  signed value MIN_INT(src_bits) (or, if you prefer, -MAX_INT(src_bits) -
  1) in which is representable in the given number of bits but is actually
  less than -1 according to the formula.  Technically, using an equality
  there was Ok, it's just that I had it equal to the wrong thing.

 So, is returning -1.0 for -MAX_INT(src_bits) correct then, or should the
 test be '== MIN_INT(src_bits)' or '== -MAX_INT(src_bits) - 1' or either
 variant using =?
 
 -MAX_INT(src_bits) will map to -1.0 even without the if statement (just
 look at the formula).  The problem is that, thanks to the clamping
 implicit in the conversion formulas, so should -MAX_INT(src_bits)-1. 
 Therefore, any of  -MAX_INT(src_bits), == -MAX_INT(src_bits) - 1,
 or = -MAX_INT(src_bits) will work.  The best (most clear) would
 probably be  -MAX_INT(src_bits).  If I recall correctly, I decided on
 the other simply because, while we have the branch in there anyway, we
 might as well cut the calculation when we can.

Actually, you had 'x  -MAX_INT(src_bits)' in your original patch, and I
pointed out that 'x = -MAX_INT(src_bits)' would save the calculation in
the == -MAX_INT(src_bits) case. Sorry for coming full circle on this.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: force NaNs to 0

2014-12-11 Thread Michel Dänzer

On 11.12.2014 07:08, Marek Olšák wrote:
 From: Marek Olšák marek.ol...@amd.com
 
 This fixes incorrect rendering in Unreal Engine demos.
 I don't know why it's called dx10 clamp mode. MSDN doesn't mention it.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83510

Assuming this doesn't affect compute shaders,

Reviewed-by: Michel Dänzer michel.daen...@amd.com


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: implement legacy RCP behavior to fix Unreal engine demos

2014-12-11 Thread Michel Dänzer

On 11.12.2014 07:49, Roland Scheidegger wrote:
 Odd indeed. Maybe it was really meant for d3d10level9 shaders or
 something (would allow to share more code compiling d3d9 or d3d10
 shaders that way I guess, you could use all the same instructions and
 just set that bit, and you said newer chips don't have the legacy
 instructions so I guess that bit would help if they still have it).
 d3d10 clearly forbids this (and so does GL 4.1 and up).

So at the latest when we get GL 4.1, we probably need some TGSI shader
attribute to tell drivers not to enable this kind of clamping?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Finishing make distcheck

On 08/12/14 02:57, Matt Turner wrote:
 I've finished fixing up make distcheck.
 
 git://people.freedesktop.org/~mattst88/mesa make-dist
 
 I've seen some (sporadic?) failures of the glcpp/tests/glcpp-test. I
 think it's because it's trying to write out files into the
 distribution directory, which isn't allowed. I'll try to track that
 down.
 
 Other than that, I don't know of any problems. I've diffed the lists
 of files in git vs the distribution tarball and it looks as expected.
 
 It's 79 small (or mechanical, like alphabetizing) patches that aren't
 interesting to read, so I'm not going to send them to the list. I do
 hope Emil will have a little time to give it a once-over.
 
 The only question I really have is what archive formats we want to
 ship? As the branch is now, it generates tar.gz (11 MiB) and tar.xz
 (6.5 MiB). I think bzip2 is pretty useless these days (larger than xz
 and takes longer to decompress). Do we still want zip?
 
 With distcheck working, we should probably start using release.sh from
 git://anongit.freedesktop.org/xorg/util/modular to generate the
 annouce emails and do the uploads like the X.Org projects do. I expect
 I can make that modification unless someone else wants to.
 
You're a star Matt !

I was hoping that you'll fix the breakage mapi but going the whole
nine yards is greatly appreciated.

My ideas on the topic as a whole are:
 * Fix make distcheck.

 * Use a versioning scheme consistent with the rest of X.org.
There was some objections that it's too complex/might break someone's
workflow, yet no-one has some forward with examples. Fwiw only OpenSUSE
and Mageia occasionally use RC tarballs, so it seems that no-one ever
will bother saying a word.

 * Don't ship anything but a tar.xz tarball.
Linux, *BSD and WindowsXP+ have/ship programs that support the format
for more than 5 years.

 * Use release.sh to tidy up the process.


I'll take a look at the branch in a second.

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

[Mesa-dev] Precision of float and trigonometric functions on i965

Hi,

there are a bunch of dEQP tests that check precision of trigonometric
functions and float qualifiers that fail on i965. The way these tests
usually operate is that they define a float (with a lowp, mediump or
highp precision qualifier) and assign the result of a trigonometric
function to it. Then they check if the result is within the limits of
the precision expected for that precision qualifier.

However, reading the GLSL spec I see:

4.5.1 Range and Precision
...
Built-in functions not listed above and not defined as equations of the
above have undefined precision. These include, for example, the
trigonometric functions and determinant.

So according to this I think these tests are wrong: you can't test
precision on the result of a function that has undefined precision... if
the purpose of these tests is to check precision of trigonometric
functions that should be plain wrong, if it is to test the precision of
float qualifiers I understand they should use functions or float
operations that have defined precision expectations according to the
spec.

That said, I also noticed that most of the errors reported are for
fairly big numbers, so I played a bit with some examples and noticed
that trigonometric functions lose more precision as their argument gets
bigger. If I pass arguments of a few thousand radians to sin() or cos()
I usually get results that are off by 0.1 and for many values over
15000 radians I get completely bogus results, off by more than 0.5 of
even 1.0 in some cases. Some examples:

Angle in radians   | sin() result | Expected |  Error   |
13000.0| 0.05308(...) | 0.08947(...) | ~ 0.036  |
14000.0| 0.85559(...) | 0.87388(...) | ~ 0.018  |
15000.0| 0.00018(...) | 0.89324(...) | ~ 0.893  |
16000.0| 0.82698(...) | 0.13100(...) | ~ 0.696  |
24500.0| 0.0(...) | 0.95833(...) | ~ 0.958  |

I suppose this is a known issue, right? Also, considering that sin() is
implemented as a single Math hardware instruction I imagine there is
little that software can do to correct this in any case...

Iago

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

Re: [Mesa-dev] Finishing make distcheck

On 11/12/14 09:02, Emil Velikov wrote:
 On 08/12/14 02:57, Matt Turner wrote:
 I've finished fixing up make distcheck.

 git://people.freedesktop.org/~mattst88/mesa make-dist

 I've seen some (sporadic?) failures of the glcpp/tests/glcpp-test. I
 think it's because it's trying to write out files into the
 distribution directory, which isn't allowed. I'll try to track that
 down.

 Other than that, I don't know of any problems. I've diffed the lists
 of files in git vs the distribution tarball and it looks as expected.

 It's 79 small (or mechanical, like alphabetizing) patches that aren't
 interesting to read, so I'm not going to send them to the list. I do
 hope Emil will have a little time to give it a once-over.

 The only question I really have is what archive formats we want to
 ship? As the branch is now, it generates tar.gz (11 MiB) and tar.xz
 (6.5 MiB). I think bzip2 is pretty useless these days (larger than xz
 and takes longer to decompress). Do we still want zip?

 With distcheck working, we should probably start using release.sh from
 git://anongit.freedesktop.org/xorg/util/modular to generate the
 annouce emails and do the uploads like the X.Org projects do. I expect
 I can make that modification unless someone else wants to.

 You're a star Matt !
 
 I was hoping that you'll fix the breakage mapi but going the whole
 nine yards is greatly appreciated.
 
It seems that it's still broken [1] - for both in and out of three builds.

Either way I've skimmed through the series and apart from the following
two things look good:
 * Do we did not need to explicitly pick the *.sym files via EXTRA_FILES
? They were in the tarball last time I've checked.
 * Let's drop mesa: Remove tarballs/checksum rules. for now. Apart
from the mapi issue, vdpau and xvmc will need the uninstall-hook,
clean-local rules.


Cheers
Emil

P.S. Graduation day tomorrow - hell yeah :-)


[1]
cd ~/development/mesa/
git clean -fxd
./autogen.sh  make dist
...
make[3]: Entering directory '/home/emil/development/mesa/src/mapi/glapi/gen'
  GEN  ../../../../src/mapi/glapi/glapi_mapi_tmp.h
  GEN  ../../../../src/mapi/glapi/glprocs.h
  GEN  ../../../../src/mapi/glapi/glapitemp.h
  GEN  ../../../../src/mapi/glapi/glapitable.h
  GEN  ../../../../src/mapi/glapi/glapi_gentable.c
  GEN  ../../../../src/mapi/glapi/glapi_x86-64.S
  GEN  ../../../../src/mesa/main/enums.c
  GEN  ../../../../src/mesa/main/api_exec.c
  GEN  ../../../../src/mesa/main/dispatch.h
  GEN  ../../../../src/mesa/main/remap_helper.h
  GEN  ../../../../src/glx/indirect.c
  GEN  ../../../../src/glx/indirect.h
  GEN  ../../../../src/glx/indirect_init.c
  GEN  ../../../../src/glx/indirect_size.h
  GEN  ../../../../src/glx/indirect_size.c
  GEN  ../../../../src/mapi/glapi/glapi_x86.S
  GEN  ../../../../src/mapi/glapi/glapi_sparc.S
make[3]: Leaving directory '/home/emil/development/mesa/src/mapi/glapi/gen'
 (cd mapi  make  top_distdir=../../mesa-10.5.0-devel
distdir=../../mesa-10.5.0-devel/src/mapi \
 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)
make[3]: Entering directory '/home/emil/development/mesa/src/mapi'
make[3]: *** No rule to make target 'es1api/glapi_mapi_tmp.h', needed by
'distdir'.  Stop.

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

Re: [Mesa-dev] Precision of float and trigonometric functions on i965

2014-12-11 Thread Petri Latvala


On 12/11/2014 11:59 AM, Iago Toral wrote:

That said, I also noticed that most of the errors reported are for
fairly big numbers, so I played a bit with some examples and noticed
that trigonometric functions lose more precision as their argument gets
bigger. If I pass arguments of a few thousand radians to sin() or cos()
I usually get results that are off by 0.1 and for many values over
15000 radians I get completely bogus results, off by more than 0.5 of
even 1.0 in some cases. Some examples:

Angle in radians   | sin() result | Expected |  Error   |
13000.0| 0.05308(...) | 0.08947(...) | ~ 0.036  |
14000.0| 0.85559(...) | 0.87388(...) | ~ 0.018  |
15000.0| 0.00018(...) | 0.89324(...) | ~ 0.893  |
16000.0| 0.82698(...) | 0.13100(...) | ~ 0.696  |
24500.0| 0.0(...) | 0.95833(...) | ~ 0.958  |

I suppose this is a known issue, right? Also, considering that sin() is
implemented as a single Math hardware instruction I imagine there is
little that software can do to correct this in any case...



According to the hw specs, sin and cos absolute error is = 0.0008, but 
only for the range of +/- 100 * pi.



--
Petri Latvala

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

Re: [Mesa-dev] [PATCH] radeonsi: implement legacy RCP behavior to fix Unreal engine demos

2014-12-11 Thread Roland Scheidegger

Am 11.12.2014 um 09:55 schrieb Michel Dänzer:
 On 11.12.2014 07:49, Roland Scheidegger wrote:
 Odd indeed. Maybe it was really meant for d3d10level9 shaders or
 something (would allow to share more code compiling d3d9 or d3d10
 shaders that way I guess, you could use all the same instructions and
 just set that bit, and you said newer chips don't have the legacy
 instructions so I guess that bit would help if they still have it).
 d3d10 clearly forbids this (and so does GL 4.1 and up).
 
 So at the latest when we get GL 4.1, we probably need some TGSI shader
 attribute to tell drivers not to enable this kind of clamping?
 
 

Maybe. In GL, an app _never_ could have relied on that clamping from
happening in the first place however (which is why it's surprising a
relatively new app would rely on this - I could understand it for
something from a time where hw didn't have NaNs).

Roland

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

Re: [Mesa-dev] [PATCH] util/primconvert: Avoid point arithmetic; apply offset on all cases.

Hi Jose,

jfyi I've picked this fix alongside the commit that introduced the
pointer arithmetic.

-Emil

On 05/12/14 14:16, Jose Fonseca wrote:
 From: José Fonseca jfons...@vmware.com
 
 Matches what u_vbuf_get_minmax_index() does.
 ---
  src/gallium/auxiliary/indices/u_primconvert.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/src/gallium/auxiliary/indices/u_primconvert.c 
 b/src/gallium/auxiliary/indices/u_primconvert.c
 index 4632781..eba1f9e 100644
 --- a/src/gallium/auxiliary/indices/u_primconvert.c
 +++ b/src/gallium/auxiliary/indices/u_primconvert.c
 @@ -137,8 +137,9 @@ util_primconvert_draw_vbo(struct primconvert_context *pc,
src = ib-user_buffer;
if (!src) {
   src = pipe_buffer_map(pc-pipe, ib-buffer,
 -   PIPE_TRANSFER_READ, src_transfer) + 
 ib-offset;
 +   PIPE_TRANSFER_READ, src_transfer);
}
 +  src = (const uint8_t *)src + ib-offset;
 }
 else {
u_index_generator(pc-primtypes_mask,
 

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

Re: [Mesa-dev] [PATCH] mesa/drivers: Add missing mesautil lib to Haiku swrast

Hi Alexander,

For a follow up patches, can you include the Cc: mesa-stable... line
within the commit message. I guess that prefixing the commit with
haiku/swrast: (as your earlier patch) wouldn't be bad either :)

Cheers,
Emil

On 11/12/14 03:38, Alexander von Gluck IV wrote:
 * Resolves missing util_format_linear_to_srgb_8unorm_table symbol.
 ---
  src/mesa/drivers/haiku/swrast/SConscript | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/src/mesa/drivers/haiku/swrast/SConscript 
 b/src/mesa/drivers/haiku/swrast/SConscript
 index 2c25f72..907325e 100644
 --- a/src/mesa/drivers/haiku/swrast/SConscript
 +++ b/src/mesa/drivers/haiku/swrast/SConscript
 @@ -13,6 +13,7 @@ env.Append(CPPPATH = [
  ])
  
  env.Prepend(LIBS = [
 +mesautil,
  glsl,
  mesa,
  ])
 

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

[Mesa-dev] [Bug 84124] Please revert 8449121971ce1db03fea19665d314e523fdc10dd

2014-12-11 Thread bugzilla-daemon

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

--- Comment #7 from Emil Velikov emil.l.veli...@gmail.com ---
commit ac319d94d38cf3145990002c8216426fe297cd28
Author: Marek Olšák marek.ol...@amd.com
Date:   Wed Dec 10 19:59:53 2014 +0100

docs/relnotes: document the removal of GALLIUM_MSAA

Cc: 10.2.10.3 10.4 mesa-sta...@lists.freedesktop.org

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

[Mesa-dev] [PATCH 1/2] util: add missing closing brace for __cplusplus

---
 src/gallium/auxiliary/util/u_prim.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_prim.h 
b/src/gallium/auxiliary/util/u_prim.h
index cf1a18f..b2dd44d 100644
--- a/src/gallium/auxiliary/util/u_prim.h
+++ b/src/gallium/auxiliary/util/u_prim.h
@@ -280,4 +280,10 @@ u_reduced_prims_for_vertices(int primitive, int vertices)
 
 const char *u_prim_name( unsigned pipe_prim );
 
+
+#ifdef __cplusplus
+}
+#endif
+
+
 #endif
-- 
1.9.1

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

[Mesa-dev] [PATCH] it_to_mesa: remove unused 'target' variable

---
 src/mesa/program/ir_to_mesa.cpp | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 68e2597..5196545 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2943,7 +2943,6 @@ _mesa_ir_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
 
 /* Lowering */
 do_mat_op_to_vec(ir);
-GLenum target = 
_mesa_shader_stage_to_program(prog-_LinkedShaders[i]-Stage);
 lower_instructions(ir, (MOD_TO_FRACT | DIV_TO_MUL_RCP | EXP_TO_EXP2
 | LOG_TO_LOG2 | INT_DIV_TO_MUL_RCP
 | ((options-EmitNoPow) ? POW_TO_EXP2 : 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] it_to_mesa: remove unused 'target' variable


I already fixed the it_to_mesa typo locally.

-Brian

On 12/11/2014 08:45 AM, Brian Paul wrote:

---
  src/mesa/program/ir_to_mesa.cpp | 1 -
  1 file changed, 1 deletion(-)

diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 68e2597..5196545 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2943,7 +2943,6 @@ _mesa_ir_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)

 /* Lowering */
 do_mat_op_to_vec(ir);
-GLenum target = 
_mesa_shader_stage_to_program(prog-_LinkedShaders[i]-Stage);
 lower_instructions(ir, (MOD_TO_FRACT | DIV_TO_MUL_RCP | EXP_TO_EXP2
 | LOG_TO_LOG2 | INT_DIV_TO_MUL_RCP
 | ((options-EmitNoPow) ? POW_TO_EXP2 : 0)));



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

Re: [Mesa-dev] Compiling llvm windows name mangled


On 11/12/14 08:40, Emil Velikov wrote:

Hi Jose,
On 10/12/14 14:18, Jose Fonseca wrote:

I never tried, but it doesn't surprise that ?USE_MGL_NAMESPACE doesn't work 
properly on Windows.


At very least the src/mesa/drivers/windows/gdi and 
src/gallium/targets/libgl-gdi targets will fail because the .DEF files there 
explicitly request the non-mangled symbols.


Not sure if src/mesa/drivers/osmesa will produce something useful. You can ask scons to 
only build osmesa by passing scons osmesa ..

?


That said, there's little to zero merit in USE_MGL_NAMESPACE on Windows because 
on Windows it's fine to have different DLLs exporting the same symbols, since 
unlike Unixes, DLLs exports are not dumped into a global namespace.


As you mentioned MGL and *nix in one sentience - did you have any
success building a mangled libgl (under Linux) recently ?


No, never tried.


I've had a few unsuccessful attempts 2+months ago, and it is still
somewhat busted.


If it's unmistakably busted we should consider just removing it.

Even on Unices it's possible to dlopen() shared objects without poluting 
global namespace via RTLD_LOCAL flag, so application shoule be able to 
use osmesa and the system's libGL.so simultanouesly without fearing 
symbol clash.  That is, I'm not aware of any merit in keeping such a 
heavy handed hammer in our code base like mangled symbols...



Jose

___
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 TGSI_SEMANTIC_VERTEXID_ZEROBASE and TGSI_SEMANTIC_BASEVERTEX


Overall I think this is a great cleanup.

Just a remark about the chosen names.

On 10/12/14 21:22, srol...@vmware.com wrote:

From: Roland Scheidegger srol...@vmware.com





Plus a new PIPE_CAP_VERTEXID_NOOFFSET query.


Vertex offset and base vertex are difference concepts, so I'd rather 
not mix them up.


AFAICT, this is about base vertex, not offsets in vertex buffers, hence 
NOOFFSET seems to be a misnomer.  Please pick NOBASE or ZEROBASE 
suffix and stick with it.


Personally, I prefer NOBASE.  As ZEROBASE sounds like that base 
vertex must some how be zero, which is not the case.





Jose

 The idea is that drivers not

supporting vertex ids with base vertex offset applied (so, only support
d3d10-style vertex ids) will get such a d3d10-style vertex id instead -
with the caveat they'll also need to handle the basevertex system value
too (this follows what core mesa already does).
Additionally, this is also useful for other state trackers (for instance
llvmpipe / draw right now implement the d3d10 behavior on purpose, but
with different semantics it can just do both).
Doesn't do anything yet.
And fix up the docs wrt similar values.
---
  src/gallium/auxiliary/tgsi/tgsi_scan.c   |  6 
  src/gallium/auxiliary/tgsi/tgsi_scan.h   |  2 ++
  src/gallium/auxiliary/tgsi/tgsi_strings.c|  2 ++
  src/gallium/docs/source/screen.rst   |  6 
  src/gallium/docs/source/tgsi.rst | 36 
  src/gallium/drivers/freedreno/freedreno_screen.c |  1 +
  src/gallium/drivers/i915/i915_screen.c   |  1 +
  src/gallium/drivers/ilo/ilo_screen.c |  2 ++
  src/gallium/drivers/llvmpipe/lp_screen.c |  2 ++
  src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
  src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
  src/gallium/drivers/r300/r300_screen.c   |  1 +
  src/gallium/drivers/r600/r600_pipe.c |  1 +
  src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
  src/gallium/drivers/softpipe/sp_screen.c |  2 ++
  src/gallium/drivers/svga/svga_screen.c   |  1 +
  src/gallium/drivers/vc4/vc4_screen.c |  1 +
  src/gallium/include/pipe/p_defines.h |  1 +
  src/gallium/include/pipe/p_shader_tokens.h   |  4 ++-
  19 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 649c327..954eb10 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -213,6 +213,12 @@ tgsi_scan_shader(const struct tgsi_token *tokens,
else if (semName == TGSI_SEMANTIC_VERTEXID) {
   info-uses_vertexid = TRUE;
}
+  else if (semName == TGSI_SEMANTIC_VERTEXID_ZEROBASE) {
+ info-uses_vertexid_zerobase = TRUE;
+  }
+  else if (semName == TGSI_SEMANTIC_BASEVERTEX) {
+ info-uses_basevertex = TRUE;
+  }
else if (semName == TGSI_SEMANTIC_PRIMID) {
   info-uses_primid = TRUE;
}
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.h 
b/src/gallium/auxiliary/tgsi/tgsi_scan.h
index 61ce813..b353097 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.h
@@ -74,6 +74,8 @@ struct tgsi_shader_info
 boolean uses_kill;  /** KILL or KILL_IF instruction used? */
 boolean uses_instanceid;
 boolean uses_vertexid;
+   boolean uses_vertexid_zerobase;
+   boolean uses_basevertex;
 boolean uses_primid;
 boolean uses_frontface;
 boolean writes_psize;
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c 
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 01fa5a9..7a45e2d 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -86,6 +86,8 @@ const char *tgsi_semantic_names[TGSI_SEMANTIC_COUNT] =
 SAMPLEPOS,
 SAMPLEMASK,
 INVOCATIONID,
+   VERTEXID_ZEROBASE,
+   BASEVERTEX,
  };

  const char *tgsi_texture_names[TGSI_TEXTURE_COUNT] =
diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index e711ad4..6ccbe5b 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -233,6 +233,12 @@ The integer capabilities:
  * ``PIPE_CAP_CLIP_HALFZ``: Whether the driver supports the
pipe_rasterizer_state::clip_halfz being set to true. This is required
for enabling ARB_clip_control.
+* ``PIPE_CAP_VERTEXID_NOOFFSET``: Whether the driver needs lowering of the
+  vertex id to not include the basevertex offset. If so vertex id will
+  use TGSI_SEMANTIC_VERTEXID_ZEROBASE and TGSI_SEMANTIC_BASEVERTEX instead
+  of TGSI_SEMANTIC_VERTEXID. Only relevant if geometry shaders are supported.
+  (Currently not possible to query availability of these two semantics outside
+  of this).

Re: [Mesa-dev] Finishing make distcheck

2014-12-11 Thread Alan Coopersmith


On 12/11/14 01:02 AM, Emil Velikov wrote:

  * Don't ship anything but a tar.xz tarball.
Linux, *BSD and WindowsXP+ have/ship programs that support the format
for more than 5 years.


Solaris 11 has been shipping xz support for the past 3 years, so that's
fine with us too.


P.S. Graduation day tomorrow - hell yeah


Congratulations!

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
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 TGSI_SEMANTIC_VERTEXID_ZEROBASE and TGSI_SEMANTIC_BASEVERTEX

2014-12-11 Thread Ilia Mirkin

On Thu, Dec 11, 2014 at 11:39 AM, Jose Fonseca jfons...@vmware.com wrote:
 Overall I think this is a great cleanup.

 Just a remark about the chosen names.

 On 10/12/14 21:22, srol...@vmware.com wrote:

 From: Roland Scheidegger srol...@vmware.com




 Plus a new PIPE_CAP_VERTEXID_NOOFFSET query.


 Vertex offset and base vertex are difference concepts, so I'd rather not
 mix them up.

 AFAICT, this is about base vertex, not offsets in vertex buffers, hence
 NOOFFSET seems to be a misnomer.  Please pick NOBASE or ZEROBASE suffix
 and stick with it.

 Personally, I prefer NOBASE.  As ZEROBASE sounds like that base vertex
 must some how be zero, which is not the case.


Is all this really just about the base vertex? The situation on, e.g.,
a3xx is that the vertex id does not include any offset, even the
'start' from glDrawArrays (which makes sense, since they use the same
general logic).

  -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 TGSI_SEMANTIC_VERTEXID_ZEROBASE and TGSI_SEMANTIC_BASEVERTEX

2014-12-11 Thread Roland Scheidegger

Am 11.12.2014 um 17:49 schrieb Ilia Mirkin:
 On Thu, Dec 11, 2014 at 11:39 AM, Jose Fonseca jfons...@vmware.com wrote:
 Overall I think this is a great cleanup.

 Just a remark about the chosen names.

 On 10/12/14 21:22, srol...@vmware.com wrote:

 From: Roland Scheidegger srol...@vmware.com




 Plus a new PIPE_CAP_VERTEXID_NOOFFSET query.


 Vertex offset and base vertex are difference concepts, so I'd rather not
 mix them up.

 AFAICT, this is about base vertex, not offsets in vertex buffers, hence
 NOOFFSET seems to be a misnomer.  Please pick NOBASE or ZEROBASE suffix
 and stick with it.

 Personally, I prefer NOBASE.  As ZEROBASE sounds like that base vertex
 must some how be zero, which is not the case.

 
 Is all this really just about the base vertex? The situation on, e.g.,
 a3xx is that the vertex id does not include any offset, even the
 'start' from glDrawArrays (which makes sense, since they use the same
 general logic).
 
   -ilia
 

Well this is actually kind of unresolved. I thought that gl_BaseVertex
would include first parameter and similar of DrawArrays, so that
really gl_VertexID = gl_BaseVertex + vertex id without basevertex
included as known from d3d10. Always. And not just for DrawElements
calls (which would be a pain - the ARB_shader_draw_parameters extension
sort of implies it could be used to translate between different APIs,
but it's mostly useless if it doesn't work for all kind of draw calls)!

The discussion about this was here:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/065172.html

So, I have no idea if this is right. And you are right BaseVertex is
sort of ambigous there, I guess if it doesn't include drawArrays first
parameter the whole point of lowering is kinda lost. I've written this
under the assumption that gl_Basevertex does include first from
DrawArrays, so the ambigous name wasn't chosen by me in that case then :-).

Roland

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

Re: [Mesa-dev] Precision of float and trigonometric functions on i965

2014-12-11 Thread Chris Forbes

Iago,

This doesn't matter for GL conformance -- but the impression I get is
that dEQP is aiming at something more.

In any case, the usual problem with this is inaccurate range
reduction, which is fixable in software at some performance cost. The
C library does this, for example.

- Chris

On Thu, Dec 11, 2014 at 10:59 PM, Iago Toral ito...@igalia.com wrote:
 Hi,

 there are a bunch of dEQP tests that check precision of trigonometric
 functions and float qualifiers that fail on i965. The way these tests
 usually operate is that they define a float (with a lowp, mediump or
 highp precision qualifier) and assign the result of a trigonometric
 function to it. Then they check if the result is within the limits of
 the precision expected for that precision qualifier.

 However, reading the GLSL spec I see:

 4.5.1 Range and Precision
 ...
 Built-in functions not listed above and not defined as equations of the
 above have undefined precision. These include, for example, the
 trigonometric functions and determinant.

 So according to this I think these tests are wrong: you can't test
 precision on the result of a function that has undefined precision... if
 the purpose of these tests is to check precision of trigonometric
 functions that should be plain wrong, if it is to test the precision of
 float qualifiers I understand they should use functions or float
 operations that have defined precision expectations according to the
 spec.

 That said, I also noticed that most of the errors reported are for
 fairly big numbers, so I played a bit with some examples and noticed
 that trigonometric functions lose more precision as their argument gets
 bigger. If I pass arguments of a few thousand radians to sin() or cos()
 I usually get results that are off by 0.1 and for many values over
 15000 radians I get completely bogus results, off by more than 0.5 of
 even 1.0 in some cases. Some examples:

 Angle in radians   | sin() result | Expected |  Error   |
 13000.0| 0.05308(...) | 0.08947(...) | ~ 0.036  |
 14000.0| 0.85559(...) | 0.87388(...) | ~ 0.018  |
 15000.0| 0.00018(...) | 0.89324(...) | ~ 0.893  |
 16000.0| 0.82698(...) | 0.13100(...) | ~ 0.696  |
 24500.0| 0.0(...) | 0.95833(...) | ~ 0.958  |

 I suppose this is a known issue, right? Also, considering that sin() is
 implemented as a single Math hardware instruction I imagine there is
 little that software can do to correct this in any case...

 Iago

 ___
 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] Precision of float and trigonometric functions on i965

2014-12-11 Thread Ilia Mirkin

On Thu, Dec 11, 2014 at 2:10 PM, Chris Forbes chr...@ijw.co.nz wrote:
 Iago,

 This doesn't matter for GL conformance -- but the impression I get is
 that dEQP is aiming at something more.

 In any case, the usual problem with this is inaccurate range
 reduction, which is fixable in software at some performance cost. The
 C library does this, for example.

Probably related to this:

https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 10/24] main: Add a concept of an array format

On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:

 From: Jason Ekstrand jason.ekstr...@intel.com

 An array format is a 32-bit integer format identifier that can represent
 any format that can be represented as an array of standard GL datatypes.
 Whie the MESA_FORMAT enums provide several of these, they don't account for
 all of them.

 v2 by Iago Toral Quiroga ito...@igalia.com:
  - Implement mesa_array_format as a plain bitfiled uint32_t type instead of
using a struct inside a union to access the various components packed in
it. This is necessary to support bigendian properly, as pointed out by
Ian.
  - Squashed: Make float types normalized
 ---
  src/mesa/main/format_info.py |  16 +
  src/mesa/main/formats.c  |  57 ++
  src/mesa/main/formats.h  | 136
 ++-
  3 files changed, 208 insertions(+), 1 deletion(-)

 diff --git a/src/mesa/main/format_info.py b/src/mesa/main/format_info.py
 index 7424fe0..fe2063d 100644
 --- a/src/mesa/main/format_info.py
 +++ b/src/mesa/main/format_info.py
 @@ -192,6 +192,22 @@ for fmat in formats:
 int(fmat.block_size() / 8))

 print '  {{ {0} }},'.format(', '.join(map(str, fmat.swizzle)))
 +   if fmat.is_array():
 +  chan = fmat.array_element()
 +  norm = chan.norm or chan.type == parser.FLOAT
 +  print '  MESA_ARRAY_FORMAT({0}),'.format(', '.join([
 + str(chan.size / 8),
 + str(int(chan.sign)),
 + str(int(chan.type == parser.FLOAT)),
 + str(int(norm)),
 + str(len(fmat.channels)),
 + str(fmat.swizzle[0]),
 + str(fmat.swizzle[1]),
 + str(fmat.swizzle[2]),
 + str(fmat.swizzle[3]),
 +  ]))
 +   else:
 +  print '  0,'
 print '   },'

  print '};'
 diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
 index 676ac27..1259892 100644
 --- a/src/mesa/main/formats.c
 +++ b/src/mesa/main/formats.c
 @@ -71,6 +71,7 @@ struct gl_format_info
 GLubyte BytesPerBlock;

 uint8_t Swizzle[4];
 +   mesa_array_format ArrayFormat;
  };

  #include format_info.c
 @@ -269,6 +270,62 @@ _mesa_get_format_swizzle(mesa_format format, uint8_t
 swizzle_out[4])
 memcpy(swizzle_out, info-Swizzle, sizeof(info-Swizzle));
  }

 +mesa_array_format
 +_mesa_array_format_flip_channels(mesa_array_format format)
 +{
 +   int num_channels;
 +   uint8_t swizzle[4];
 +
 +   num_channels = _mesa_array_format_get_num_channels(format);
 +   _mesa_array_format_get_swizzle(format, swizzle);
 +
 +   if (num_channels == 1)
 +  return format;
 +
 +   if (num_channels == 2) {
 +  _mesa_array_format_set_swizzle(format, swizzle[1], swizzle[0],
 + swizzle[2], swizzle[3]);
 +  return format;
 +   }
 +
 +   if (num_channels == 4) {
 +  _mesa_array_format_set_swizzle(format, swizzle[3], swizzle[2],
 + swizzle[1], swizzle[0]);
 +  return format;
 +   }
 +
 +   unreachable(Invalid array format);
 +}
 +
 +uint32_t
 +_mesa_format_to_array_format(mesa_format format)
 +{
 +   const struct gl_format_info *info = _mesa_get_format_info(format);
 +   if (_mesa_little_endian())
 +  return info-ArrayFormat;
 +   else
 +  return _mesa_array_format_flip_channels(info-ArrayFormat);
 +}
 +
 +mesa_format
 +_mesa_format_from_array_format(uint32_t array_format)
 +{
 +   mesa_array_format af;
 +   unsigned f;
 +
 +   assert(_mesa_format_is_mesa_array_format(array_format));
 +
 +   if (_mesa_little_endian())
 +  af = array_format;
 +   else
 +  af = _mesa_array_format_flip_channels(array_format);
 +
 +   for (f = 1; f  MESA_FORMAT_COUNT; ++f)
 +  if (_mesa_get_format_info(f)-ArrayFormat == af)
 + return f;
 +
 +   return MESA_FORMAT_NONE;
 +}

  /** Is the given format a compressed format? */
  GLboolean
 diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
 index 213ab56..746a92f 100644
 --- a/src/mesa/main/formats.h
 +++ b/src/mesa/main/formats.h
 @@ -37,7 +37,6 @@
  #include stdbool.h
  #include stdint.h

 -
  #ifdef __cplusplus
  extern C {
  #endif
 @@ -82,6 +81,132 @@ enum {
  };

  /**
 + * An uint32_t that encodes the information necessary to represent an
 + * array format
 + */
 +typedef uint32_t mesa_array_format;
 +
 +/**
 + * Encoding for valid array format data types
 + */
 +enum mesa_array_format_datatype {
 +   MESA_ARRAY_FORMAT_TYPE_UBYTE = 0x0,
 +   MESA_ARRAY_FORMAT_TYPE_USHORT = 0x1,
 +   MESA_ARRAY_FORMAT_TYPE_UINT = 0x2,
 +   MESA_ARRAY_FORMAT_TYPE_BYTE = 0x4,
 +   MESA_ARRAY_FORMAT_TYPE_SHORT = 0x5,
 +   MESA_ARRAY_FORMAT_TYPE_INT = 0x6,
 +   MESA_ARRAY_FORMAT_TYPE_HALF = 0xd,
 +   MESA_ARRAY_FORMAT_TYPE_FLOAT = 0xe,
 +};
 +
 +/**
 + * An enum useful to encode/decode information stored in a
 mesa_array_format
 + */
 +enum {
 +   MESA_ARRAY_FORMAT_TYPE_IS_SIGNED = 0x4,
 +   MESA_ARRAY_FORMAT_TYPE_IS_FLOAT = 0x8,
 +

Re: [Mesa-dev] [PATCH v3 13/24] configure: require python mako module

On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:

 From: Samuel Iglesias Gonsalvez sigles...@igalia.com

 It is now a hard dependency because of the autogeneration of
 format pack and unpack functions.

 Update the documentation to reflect this change.

 v2:
 - Inline python script in m4 file and use PYTHON2

 Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
 ---
  configure.ac  |  2 +
  docs/install.html |  6 ++-
  m4/ax_check_python_mako_module.m4 | 77
 +++
  3 files changed, 84 insertions(+), 1 deletion(-)
  create mode 100644 m4/ax_check_python_mako_module.m4

 diff --git a/configure.ac b/configure.ac
 index 1d9d015..f38acfd 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -76,6 +76,8 @@ if test x$INDENT != xcat; then
  AC_SUBST(INDENT_FLAGS, '-i4 -nut -br -brs -npcs -ce -TGLubyte
 -TGLbyte -TBool')
  fi

 +AC_CHECK_PYTHON_MAKO_MODULE(0.7.3)
 +
  AC_PROG_INSTALL

  dnl We need a POSIX shell for parts of the build. Assume we have one
 diff --git a/docs/install.html b/docs/install.html
 index f12425f..b12e1cb 100644
 --- a/docs/install.html
 +++ b/docs/install.html
 @@ -38,6 +38,10 @@
  Version 2.6.4 or later should work.
  /li
  br
 +lia href=http://www.makotemplates.org/;Python Mako module/a -
 +Python Mako module is required. Version 0.7.3 or later should work.
 +/li
 +/br
  lia href=http://www.scons.org/;SCons/a is required for building on
  Windows and optional for Linux (it's an alternative to autoconf/automake.)
  /li
 @@ -78,7 +82,7 @@ the needed dependencies:
  pre
sudo yum install flex bison imake libtool xorg-x11-proto-devel
 libdrm-devel \
gcc-c++ xorg-x11-server-devel libXi-devel libXmu-devel libXdamage-devel
 git \
 -  expat-devel llvm-devel
 +  expat-devel llvm-devel python-mako
  /pre


 diff --git a/m4/ax_check_python_mako_module.m4
 b/m4/ax_check_python_mako_module.m4
 new file mode 100644
 index 000..f289f26
 --- /dev/null
 +++ b/m4/ax_check_python_mako_module.m4
 @@ -0,0 +1,77 @@
 +#
 ===
 +#
 +# SYNOPSIS
 +#
 +#   AX_CHECK_PYTHON_MAKO_MODULE(MIN_VERSION_NUMBER)
 +#
 +# DESCRIPTION
 +#
 +#   Check whether Python mako module is installed and its version higher
 than
 +#   minimum requested.
 +#
 +#   Example of its use:
 +#
 +#   For example, the minimum mako version would be 0.7.3. Then
 configure.ac
 +#   would contain:
 +#
 +#   AC_CHECK_PYTHON_MAKO_MODULE(0.7.3)
 +#
 +# LICENSE
 +#
 +#   Copyright (c) 2014 Intel Corporation.
 +#
 +#   This program is free software; you can redistribute it and/or modify
 it
 +#   under the terms of the GNU General Public License as published by the
 +#   Free Software Foundation; either version 2 of the License, or (at your
 +#   option) any later version.
 +#
 +#   This program is distributed in the hope that it will be useful, but
 +#   WITHOUT ANY WARRANTY; without even the implied warranty of
 +#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 General
 +#   Public License for more details.
 +#
 +#   You should have received a copy of the GNU General Public License
 along
 +#   with this program. If not, see http://www.gnu.org/licenses/.
 +#
 +#   As a special exception, the respective Autoconf Macro's copyright
 owner
 +#   gives unlimited permission to copy, distribute and modify the
 configure
 +#   scripts that are the output of Autoconf when processing the Macro. You
 +#   need not follow the terms of the GNU General Public License when using
 +#   or distributing such scripts, even though portions of the text of the
 +#   Macro appear in them. The GNU General Public License (GPL) does govern
 +#   all other use of the material that constitutes the Autoconf Macro.
 +#
 +#   This special exception to the GPL applies to versions of the Autoconf
 +#   Macro released by the Autoconf Archive. When you make and distribute a
 +#   modified version of the Autoconf Macro, you may extend this special
 +#   exception to the GPL to apply to your modified version as well.
 +
 +dnl macro that checks for mako module in python
 +AC_DEFUN([AC_CHECK_PYTHON_MAKO_MODULE],
 +[AC_MSG_CHECKING(if module mako in python is installed)
 +echo 
 +try:
 +import sys
 +import mako
 +except ImportError as err:
 +sys.exit(err)
 +else:
 +ver_min_req_str = str('$1');
 +ver_min_req = ver_min_req_str.split('.');


Why are there semicolons?


 +ver_str = mako.__version__
 +ver = ver_str.split('.')
 +
 +for i in range(len(ver)):
 +ver_int = int(ver[[i]])
 +ver_min_req_int = int(ver_min_req[[i]]);
 +if ver_int  ver_min_req_int:
 +sys.exit(1);
 +if ver_int  ver_min_req_int:
 +sys.exit(0);
 +sys.exit(0); | $PYTHON2 -


It would be nice to put the  and the |$PYTHON2 stuff on its own line so we
can see where the inline python ends.


 +if test $? -ne 0 ; then
 +

Re: [Mesa-dev] [PATCH v3 13/24] configure: require python mako module

2014-12-11 Thread Ilia Mirkin

On Tue, Dec 9, 2014 at 7:06 AM, Iago Toral Quiroga ito...@igalia.com wrote:
 From: Samuel Iglesias Gonsalvez sigles...@igalia.com

 It is now a hard dependency because of the autogeneration of
 format pack and unpack functions.

 Update the documentation to reflect this change.

 v2:
 - Inline python script in m4 file and use PYTHON2

 Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
 ---
  configure.ac  |  2 +
  docs/install.html |  6 ++-
  m4/ax_check_python_mako_module.m4 | 77 
 +++
  3 files changed, 84 insertions(+), 1 deletion(-)
  create mode 100644 m4/ax_check_python_mako_module.m4

 diff --git a/configure.ac b/configure.ac
 index 1d9d015..f38acfd 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -76,6 +76,8 @@ if test x$INDENT != xcat; then
  AC_SUBST(INDENT_FLAGS, '-i4 -nut -br -brs -npcs -ce -TGLubyte -TGLbyte 
 -TBool')
  fi

 +AC_CHECK_PYTHON_MAKO_MODULE(0.7.3)
 +
  AC_PROG_INSTALL

  dnl We need a POSIX shell for parts of the build. Assume we have one
 diff --git a/docs/install.html b/docs/install.html
 index f12425f..b12e1cb 100644
 --- a/docs/install.html
 +++ b/docs/install.html
 @@ -38,6 +38,10 @@
  Version 2.6.4 or later should work.
  /li
  br
 +lia href=http://www.makotemplates.org/;Python Mako module/a -
 +Python Mako module is required. Version 0.7.3 or later should work.
 +/li
 +/br
  lia href=http://www.scons.org/;SCons/a is required for building on
  Windows and optional for Linux (it's an alternative to autoconf/automake.)
  /li
 @@ -78,7 +82,7 @@ the needed dependencies:
  pre
sudo yum install flex bison imake libtool xorg-x11-proto-devel 
 libdrm-devel \
gcc-c++ xorg-x11-server-devel libXi-devel libXmu-devel libXdamage-devel 
 git \
 -  expat-devel llvm-devel
 +  expat-devel llvm-devel python-mako
  /pre


 diff --git a/m4/ax_check_python_mako_module.m4 
 b/m4/ax_check_python_mako_module.m4
 new file mode 100644
 index 000..f289f26
 --- /dev/null
 +++ b/m4/ax_check_python_mako_module.m4
 @@ -0,0 +1,77 @@
 +# ===
 +#
 +# SYNOPSIS
 +#
 +#   AX_CHECK_PYTHON_MAKO_MODULE(MIN_VERSION_NUMBER)
 +#
 +# DESCRIPTION
 +#
 +#   Check whether Python mako module is installed and its version higher than
 +#   minimum requested.
 +#
 +#   Example of its use:
 +#
 +#   For example, the minimum mako version would be 0.7.3. Then configure.ac
 +#   would contain:
 +#
 +#   AC_CHECK_PYTHON_MAKO_MODULE(0.7.3)
 +#
 +# LICENSE
 +#
 +#   Copyright (c) 2014 Intel Corporation.
 +#
 +#   This program is free software; you can redistribute it and/or modify it
 +#   under the terms of the GNU General Public License as published by the
 +#   Free Software Foundation; either version 2 of the License, or (at your
 +#   option) any later version.
 +#
 +#   This program is distributed in the hope that it will be useful, but
 +#   WITHOUT ANY WARRANTY; without even the implied warranty of
 +#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
 +#   Public License for more details.
 +#
 +#   You should have received a copy of the GNU General Public License along
 +#   with this program. If not, see http://www.gnu.org/licenses/.
 +#
 +#   As a special exception, the respective Autoconf Macro's copyright owner
 +#   gives unlimited permission to copy, distribute and modify the configure
 +#   scripts that are the output of Autoconf when processing the Macro. You
 +#   need not follow the terms of the GNU General Public License when using
 +#   or distributing such scripts, even though portions of the text of the
 +#   Macro appear in them. The GNU General Public License (GPL) does govern
 +#   all other use of the material that constitutes the Autoconf Macro.
 +#
 +#   This special exception to the GPL applies to versions of the Autoconf
 +#   Macro released by the Autoconf Archive. When you make and distribute a
 +#   modified version of the Autoconf Macro, you may extend this special
 +#   exception to the GPL to apply to your modified version as well.
 +
 +dnl macro that checks for mako module in python
 +AC_DEFUN([AC_CHECK_PYTHON_MAKO_MODULE],
 +[AC_MSG_CHECKING(if module mako in python is installed)
 +echo 
 +try:
 +import sys
 +import mako
 +except ImportError as err:
 +sys.exit(err)
 +else:
 +ver_min_req_str = str('$1');
 +ver_min_req = ver_min_req_str.split('.');
 +ver_str = mako.__version__
 +ver = ver_str.split('.')
 +
 +for i in range(len(ver)):
 +ver_int = int(ver[[i]])
 +ver_min_req_int = int(ver_min_req[[i]]);
 +if ver_int  ver_min_req_int:
 +sys.exit(1);
 +if ver_int  ver_min_req_int:
 +sys.exit(0);

Is this something that you wrote, or is it a standard thing you
copied from somewhere? Seems like it'd be a lot simpler as

  ver_req = map(int, '$1'.split('.'))
  ver_act = map(int, mako.__version__.split('.'))

Re: [Mesa-dev] [PATCH v3 18/24] mesa/format_pack: Add _mesa_pack_int_rgba_row()

On Tue, Dec 9, 2014 at 4:07 AM, Iago Toral Quiroga ito...@igalia.com
wrote:

 From: Samuel Iglesias Gonsalvez sigles...@igalia.com

 This will be used to unify code in pack.c.

 v2:
 - Modify pack_int_*() function generator to use c.datatype() and
   f.datatype()

 Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
 ---
  src/mesa/main/format_pack.h  |   3 ++
  src/mesa/main/format_pack.py | 121
 +++
  2 files changed, 124 insertions(+)

 diff --git a/src/mesa/main/format_pack.h b/src/mesa/main/format_pack.h
 index 1582ad1..6087fc3 100644
 --- a/src/mesa/main/format_pack.h
 +++ b/src/mesa/main/format_pack.h
 @@ -68,6 +68,9 @@ extern gl_pack_ubyte_stencil_func
  _mesa_get_pack_ubyte_stencil_func(mesa_format format);


 +extern void
 +_mesa_pack_int_rgba_row(mesa_format format, GLuint n,
 +  const GLint src[][4], void *dst);

  extern void
  _mesa_pack_float_rgba_row(mesa_format format, GLuint n,
 diff --git a/src/mesa/main/format_pack.py b/src/mesa/main/format_pack.py
 index afb5011..487dc39 100644
 --- a/src/mesa/main/format_pack.py
 +++ b/src/mesa/main/format_pack.py
 @@ -213,6 +213,99 @@ pack_uint_${f.short_name()}(const GLuint src[4], void
 *dst)
  }
  %endfor

 +/* int packing functions */
 +
 +%for f in rgb_formats:
 +   %if f.name in ('MESA_FORMAT_R9G9B9E5_FLOAT',
 'MESA_FORMAT_R11G11B10_FLOAT'):
 +  % continue %
 +   %elif f.is_compressed():
 +  % continue %
 +   %endif
 +
 +static inline void
 +pack_int_${f.short_name()}(const GLint src[4], void *dst)
 +{
 +   %for (i, c) in enumerate(f.channels):
 +  % i = f.swizzle.inverse()[i] %
 +  %if c.type == 'x':
 + % continue %
 +  %endif
 +
 +  ${c.datatype()} ${c.name} =
 +  %if not f.is_normalized():
 + %if c.type == parser.FLOAT and c.size == 32:
 +INT_TO_FLOAT(src[${i}]);
 + %elif c.type == parser.FLOAT and c.size == 16:
 +_mesa_float_to_half(INT_TO_FLOAT(src[${i}]));
 + %else:
 +(${c.datatype()}) src[${i}];
 + %endif
 +  %elif c.type == parser.UNSIGNED:


Any particular reason we're even allowing normalized formats here?  We
don't in the unpack version.


 + %if f.colorspace == 'srgb' and c.name in 'rgb':
 +util_format_linear_to_srgb_8unorm(src[${i}]);
 + %else:
 +CLAMP(src[${i}], 0, MAX_UINT(${c.size}));
 + %endif
 +  %elif c.type == parser.SIGNED:
 + CLAMP(src[${i}], 0,  MAX_UINT(${c.size}));
 +  %elif c.type == parser.FLOAT:
 + %if c.size == 32:
 +_mesa_snorm_to_float(src[${i}], 8);
 + %elif c.size == 16:
 +_mesa_snorm_to_half(src[${i}], 8);
 + %else:
 +% assert False %
 + %endif
 +  %else:
 + % assert False %
 +  %endif
 +   %endfor
 +
 +   %if f.layout == parser.ARRAY:
 +  ${f.datatype()} *d = (${f.datatype()} *)dst;
 +  %for (i, c) in enumerate(f.channels):
 + %if c.type == 'x':
 +% continue %
 + %endif
 + d[${i}] = ${c.name};
 +  %endfor
 +   %elif f.layout == parser.PACKED:
 +  ${f.datatype()} d = 0;
 +  %for (i, c) in enumerate(f.channels):
 + %if c.type == 'x':
 +% continue %
 + %endif
 + d |= PACK(${c.name}, ${c.shift}, ${c.size});
 +  %endfor
 +  (*(${f.datatype()} *)dst) = d;
 +   %else:
 +  % assert False %
 +   %endif
 +}
 +%endfor
 +
 +static inline void
 +pack_int_r9g9b9e5_float(const GLint src[4], void *dst)
 +{
 +   GLuint *d = (GLuint *) dst;
 +   GLfloat rgb[3];
 +   rgb[0] = _mesa_snorm_to_float(src[RCOMP], 8);
 +   rgb[1] = _mesa_snorm_to_float(src[GCOMP], 8);
 +   rgb[2] = _mesa_snorm_to_float(src[BCOMP], 8);
 +   *d = float3_to_rgb9e5(rgb);
 +}
 +
 +static inline void
 +pack_int_r11g11b10_float(const GLint src[4], void *dst)
 +{
 +   GLuint *d = (GLuint *) dst;
 +   GLfloat rgb[3];
 +   rgb[0] = _mesa_snorm_to_float(src[RCOMP], 8);
 +   rgb[1] = _mesa_snorm_to_float(src[GCOMP], 8);
 +   rgb[2] = _mesa_snorm_to_float(src[BCOMP], 8);
 +   *d = float3_to_r11g11b10f(rgb);
 +}
 +
  /* float packing functions */

  %for f in rgb_formats:
 @@ -392,6 +485,34 @@ _mesa_pack_uint_rgba_row(mesa_format format, GLuint n,
  }

  /**
 + * Pack a row of GLint rgba[4] values to the destination.
 + */
 +void
 +_mesa_pack_int_rgba_row(mesa_format format, GLuint n,
 +  const GLint src[][4], void *dst)
 +{
 +   GLuint i;
 +   GLubyte *d = dst;
 +
 +   switch (format) {
 +%for f in rgb_formats:
 +   %if f.is_compressed():
 +  % continue %
 +   %endif
 +
 +   case ${f.name}:
 +  for (i = 0; i  n; ++i) {
 + pack_int_${f.short_name()}(src[i], d);
 + d += ${f.block_size() / 8};
 +  }
 +  break;
 +%endfor
 +   default:
 +  assert(!Invalid format);
 +   }
 +}
 +
 +/**
   * Pack a row of GLfloat rgba[4] values to the destination.
   */
  void
 --
 1.9.1

[Mesa-dev] [PATCH v2] glsl: Prefer unreachable(condition) over assert(!condition)

The unreachable macro has the advantage (for modern compilers) of
hinting to the compiler that this code is actually unreachable. This
allows us to drop things like return statements or assignments that
existed only to quiet compiler warnings.

Also, this version is a bit easier to type correctly and understand
when reading without that seemingly out-of-place logical negation.
---

Thanks for the review, Ian. This second revision of this patch adopts all of
your recommendations: dropping unreachable return and assignments; and putting
two of the unreachable() calls back into assert().

I didn't change any of the strings being passed to unreachable(). If someone
really wants more descriptive strings there, then someone more familiar with
the code than I am should come up with something. But the current strings are
all the same as what was there before, so that shouldn't block this patch I
think.

-Carl

 src/glsl/ast_function.cpp|  5 +-
 src/glsl/ast_to_hir.cpp  |  8 +--
 src/glsl/glcpp/glcpp-parse.y |  2 +-
 src/glsl/glsl_parser_extras.cpp  |  5 +-
 src/glsl/glsl_symbol_table.cpp   |  6 +--
 src/glsl/glsl_types.cpp  | 19 +++
 src/glsl/ir.cpp  | 66 +++-
 src/glsl/ir.h|  2 +-
 src/glsl/ir_clone.cpp|  2 +-
 src/glsl/ir_constant_expression.cpp  |  8 +--
 src/glsl/ir_equals.cpp   |  2 +-
 src/glsl/ir_validate.cpp |  2 +-
 src/glsl/ir_visitor.h|  2 +-
 src/glsl/link_interface_blocks.cpp   |  2 +-
 src/glsl/link_uniform_block_active_visitor.cpp   |  3 +-
 src/glsl/link_uniform_blocks.cpp |  2 +-
 src/glsl/link_uniform_initializers.cpp   |  4 +-
 src/glsl/link_uniforms.cpp   |  2 +-
 src/glsl/link_varyings.cpp   |  3 +-
 src/glsl/loop_analysis.cpp   |  2 +-
 src/glsl/loop_controls.cpp   |  3 +-
 src/glsl/lower_packed_varyings.cpp   |  4 +-
 src/glsl/lower_packing_builtins.cpp  |  2 +-
 src/glsl/lower_ubo_reference.cpp |  8 ++-
 src/glsl/lower_variable_index_to_cond_assign.cpp |  3 +-
 src/glsl/lower_vector.cpp|  2 +-
 src/glsl/opt_constant_propagation.cpp|  4 +-
 src/glsl/opt_minmax.cpp  |  2 +-
 28 files changed, 65 insertions(+), 110 deletions(-)

diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index cbff9d8..8c80a0d 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -661,8 +661,7 @@ dereference_component(ir_rvalue *src, unsigned component)
   return dereference_component(col, r);
}
 
-   assert(!Should not get here.);
-   return NULL;
+   unreachable(Should not get here.);
 }
 
 
@@ -1016,7 +1015,7 @@ emit_inline_vector_constructor(const glsl_type *type,
  data.b[i + base_component] = c-get_bool_component(i);
  break;
   default:
- assert(!Should not get here.);
+ unreachable(Should not get here.);
  break;
   }
}
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 811a955..ae68142 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -1193,7 +1193,7 @@ ast_expression::do_hir(exec_list *instructions,
 
switch (this-oper) {
case ast_aggregate:
-  assert(!ast_aggregate: Should never get here.);
+  unreachable(ast_aggregate: Should never get here.);
   break;
 
case ast_assign: {
@@ -2314,7 +2314,7 @@ validate_explicit_location(const struct 
ast_type_qualifier *qual,
: (qual-location + VARYING_SLOT_VAR0);
 break;
  case MESA_SHADER_COMPUTE:
-assert(!Unexpected shader type);
+unreachable(Unexpected shader type);
 break;
  }
   } else {
@@ -5412,7 +5412,7 @@ ast_interface_block::hir(exec_list *instructions,
} else {
   var_mode = ir_var_auto;
   iface_type_name = UNKNOWN;
-  assert(!interface block layout qualifier not found!);
+  unreachable(interface block layout qualifier not found!);
}
 
enum glsl_matrix_layout matrix_layout = GLSL_MATRIX_LAYOUT_INHERITED;
@@ -6008,7 +6008,7 @@ remove_per_vertex_blocks(exec_list *instructions,
   }
   break;
default:
-  assert(!Unexpected mode);
+  unreachable(Unexpected mode);
   break;
}
 
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index f1119eb..f1c006e 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -1169,7 +1169,7 @@ _token_print (char **out, size_t *len, token_t *token)
/* Nothing to print. */

Re: [Mesa-dev] [PATCH v3 17/24] mesa: Add non-normalized formats support for ubyte packing functions

Let's squash this in to patch 14.

On Tue, Dec 9, 2014 at 4:07 AM, Iago Toral Quiroga ito...@igalia.com
wrote:

 From: Samuel Iglesias Gonsalvez sigles...@igalia.com

 v2:
 - Add clamping for non-normalized integer formats in pack_ubyte*()

 Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
 ---
  src/mesa/main/format_pack.py | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

 diff --git a/src/mesa/main/format_pack.py b/src/mesa/main/format_pack.py
 index a65a614..afb5011 100644
 --- a/src/mesa/main/format_pack.py
 +++ b/src/mesa/main/format_pack.py
 @@ -88,7 +88,13 @@ pack_ubyte_${f.short_name()}(const GLubyte src[4], void
 *dst)
%endif

${c.datatype()} ${c.name} =
 -  %if c.type == parser.UNSIGNED:
 +  %if not f.is_normalized() and f.is_int():
 +  %if c.type == parser.SIGNED:
 +  _mesa_unsigned_to_signed(src[${i}], ${c.size});
 +  %else:
 +  _mesa_unsigned_to_unsigned(src[${i}], ${c.size});
 +  %endif
 +  %elif c.type == parser.UNSIGNED:
   %if f.colorspace == 'srgb' and c.name in 'rgb':
  util_format_linear_to_srgb_8unorm(src[${i}]);
   %else:
 --
 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

Re: [Mesa-dev] [PATCH v3 14/24] mesa: Autogenerate most of format_pack.c

On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:

[snip]


 new file mode 100644
 index 000..5f6809e
 --- /dev/null
 +++ b/src/mesa/main/format_pack.py
 @@ -0,0 +1,907 @@
 +#!/usr/bin/env python
 +
 +from mako.template import Template
 +from sys import argv
 +
 +string = /*
 + * Mesa 3-D graphics library
 + *
 + * Copyright (c) 2011 VMware, Inc.
 + * Copyright (c) 2014 Intel Corporation.
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a
 + * copy of this software and associated documentation files (the
 Software),
 + * to deal in the Software without restriction, including without
 limitation
 + * the rights to use, copy, modify, merge, publish, distribute,
 sublicense,
 + * and/or sell copies of the Software, and to permit persons to whom the
 + * Software is furnished to do so, subject to the following conditions:
 + *
 + * The above copyright notice and this permission notice shall be included
 + * in all copies or substantial portions of the Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
 + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
 SHALL
 + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
 + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
 + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 + * OTHER DEALINGS IN THE SOFTWARE.
 + */
 +
 +
 +/**
 + * Color, depth, stencil packing functions.
 + * Used to pack basic color, depth and stencil formats to specific
 + * hardware formats.
 + *
 + * There are both per-pixel and per-row packing functions:
 + * - The former will be used by swrast to write values to the color,
 depth,
 + *   stencil buffers when drawing points, lines and masked spans.
 + * - The later will be used for image-oriented functions like
 glDrawPixels,
 + *   glAccum, and glTexImage.
 + */
 +
 +#include stdint.h
 +
 +#include colormac.h
 +#include format_pack.h
 +#include format_utils.h
 +#include macros.h
 +#include ../../gallium/auxiliary/util/u_format_rgb9e5.h
 +#include ../../gallium/auxiliary/util/u_format_r11g11b10f.h
 +#include util/format_srgb.h
 +
 +#define UNPACK(SRC, OFFSET, BITS) (((SRC)  (OFFSET))  MAX_UINT(BITS))
 +#define PACK(SRC, OFFSET, BITS) (((SRC)  MAX_UINT(BITS))  (OFFSET))
 +
 +%
 +import format_parser as parser
 +
 +formats = parser.parse(argv[1])
 +
 +rgb_formats = []
 +for f in formats:
 +   if f.name == 'MESA_FORMAT_NONE':
 +  continue
 +   if f.colorspace not in ('rgb', 'srgb'):
 +  continue
 +
 +   rgb_formats.append(f)
 +%
 +
 +/* ubyte packing functions */
 +
 +%for f in rgb_formats:
 +   %if f.name in ('MESA_FORMAT_R9G9B9E5_FLOAT',
 'MESA_FORMAT_R11G11B10_FLOAT'):
 +  % continue %
 +   %elif f.is_compressed():
 +  % continue %
 +   %endif
 +
 +static inline void
 +pack_ubyte_${f.short_name()}(const GLubyte src[4], void *dst)
 +{
 +   %for (i, c) in enumerate(f.channels):
 +  % i = f.swizzle.inverse()[i] %
 +  %if c.type == 'x':
 + % continue %
 +  %endif
 +
 +  ${c.datatype()} ${c.name} =
 +  %if c.type == parser.UNSIGNED:
 + %if f.colorspace == 'srgb' and c.name in 'rgb':
 +util_format_linear_to_srgb_8unorm(src[${i}]);
 + %else:
 +_mesa_unorm_to_unorm(src[${i}], 8, ${c.size});
 + %endif
 +  %elif c.type == parser.SIGNED:
 + _mesa_unorm_to_snorm(src[${i}], 8, ${c.size});
 +  %elif c.type == parser.FLOAT:
 + %if c.size == 32:
 +_mesa_unorm_to_float(src[${i}], 8);
 + %elif c.size == 16:
 +_mesa_unorm_to_half(src[${i}], 8);
 + %else:
 +% assert False %
 + %endif
 +  %else:
 + % assert False %
 +  %endif
 +   %endfor
 +
 +   %if f.layout == parser.ARRAY:
 +  ${f.datatype()} *d = (${f.datatype()} *)dst;
 +  %for (i, c) in enumerate(f.channels):
 + %if c.type == 'x':
 +% continue %
 + %endif
 + d[${i}] = ${c.name};
 +  %endfor
 +   %elif f.layout == parser.PACKED:
 +  ${f.datatype()} d = 0;
 +  %for (i, c) in enumerate(f.channels):
 + %if c.type == 'x':
 +% continue %
 + %endif
 + d |= PACK(${c.name}, ${c.shift}, ${c.size});
 +  %endfor
 +  (*(${f.datatype()} *)dst) = d;
 +   %else:
 +  % assert False %
 +   %endif
 +}
 +%endfor
 +
 +static inline void
 +pack_ubyte_r9g9b9e5_float(const GLubyte src[4], void *dst)
 +{
 +   GLuint *d = (GLuint *) dst;
 +   GLfloat rgb[3];
 +   rgb[0] = _mesa_unorm_to_float(src[RCOMP], 8);
 +   rgb[1] = _mesa_unorm_to_float(src[GCOMP], 8);
 +   rgb[2] = _mesa_unorm_to_float(src[BCOMP], 8);
 +   *d = float3_to_rgb9e5(rgb);
 +}
 +
 +static inline void
 +pack_ubyte_r11g11b10_float(const GLubyte src[4], void *dst)
 +{
 +   GLuint *d = (GLuint *) dst;
 +   GLfloat

[Mesa-dev] [PATCH 1/2] glsl: Add blob.c---a simple interface for serializing data

This new interface allows for writing a series of objects to a chunk
of memory (a blob).. The allocated memory is maintained within the
blob itself, (and re-allocated by doubling when necessary).

There are also functions for reading objects from a blob as well. If
code attempts to read beyond the available memory, the read functions
return 0 values (or its moral equivalent) without reading past the
allocated memory. Once the caller is done with the reads, it can check
blob-overrun to ensure whether any invalid values were previously
returned due to attempts to read too far.
---
 src/glsl/Makefile.sources |   3 +-
 src/glsl/blob.c   | 287 ++
 src/glsl/blob.h   | 263 ++
 3 files changed, 552 insertions(+), 1 deletion(-)
 create mode 100644 src/glsl/blob.c
 create mode 100644 src/glsl/blob.h

diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index 676fa0d..875e4bf 100644
--- a/src/glsl/Makefile.sources
+++ b/src/glsl/Makefile.sources
@@ -105,7 +105,8 @@ LIBGLSL_FILES = \
$(GLSL_SRCDIR)/opt_swizzle_swizzle.cpp \
$(GLSL_SRCDIR)/opt_tree_grafting.cpp \
$(GLSL_SRCDIR)/opt_vectorize.cpp \
-   $(GLSL_SRCDIR)/s_expression.cpp
+   $(GLSL_SRCDIR)/s_expression.cpp \
+   $(GLSL_SRCDIR)/blob.c
 
 # glsl_compiler
 
diff --git a/src/glsl/blob.c b/src/glsl/blob.c
new file mode 100644
index 000..0af71fc
--- /dev/null
+++ b/src/glsl/blob.c
@@ -0,0 +1,287 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include string.h
+
+#include main/macros.h
+#include util/ralloc.h
+#include blob.h
+
+#define BLOB_INITIAL_SIZE 4096
+
+/* Ensure that \blob will be able to fit an additional object of size
+ * \additional.  The growing (if any) will occur by doubling the existing
+ * allocation.
+ */
+static bool
+grow_to_fit (struct blob *blob, size_t additional)
+{
+   size_t to_allocate;
+   uint8_t *new_data;
+
+   if (blob-size + additional = blob-allocated)
+  return true;
+
+   if (blob-allocated == 0)
+  to_allocate = BLOB_INITIAL_SIZE;
+   else
+  to_allocate = blob-allocated * 2;
+
+   new_data = reralloc_size(blob, blob-data, to_allocate);
+   if (new_data == NULL)
+  return false;
+
+   blob-data = new_data;
+   blob-allocated = to_allocate;
+
+   return true;
+}
+
+/* Align the blob-size so that reading or writing a value at (blob-data +
+ * blob-size) will result in an access aligned to a granularity of \alignment
+ * bytes.
+ *
+ * \return True unless allocation fails
+ */
+static bool
+align_blob (struct blob *blob, size_t alignment)
+{
+   size_t new_size;
+
+   new_size = ALIGN(blob-size, alignment);
+
+   if (! grow_to_fit (blob, new_size - blob-size))
+  return false;
+
+   blob-size = new_size;
+
+   return true;
+}
+
+static void
+align_blob_reader (struct blob_reader *blob, size_t alignment)
+{
+   blob-current = blob-data + ALIGN(blob-current - blob-data, alignment);
+}
+
+struct blob *
+blob_create (void *mem_ctx)
+{
+   struct blob *blob;
+
+   blob = ralloc(mem_ctx, struct blob);
+   if (blob == NULL)
+  return NULL;
+
+   blob-data = NULL;
+   blob-allocated = 0;
+   blob-size = 0;
+
+   return blob;
+}
+
+bool
+blob_write_bytes (struct blob *blob, const void *bytes, size_t to_write)
+{
+   if (! grow_to_fit (blob, to_write))
+   return false;
+
+   memcpy (blob-data + blob-size, bytes, to_write);
+   blob-size += to_write;
+
+   return true;
+}
+
+uint8_t *
+blob_reserve_bytes (struct blob *blob, size_t to_write)
+{
+   uint8_t *ret;
+
+   if (! grow_to_fit (blob, to_write))
+  return NULL;
+
+   ret = blob-data + blob-size;
+   blob-size += to_write;
+
+   return ret;
+}
+
+bool
+blob_write_uint32 (struct blob *blob, uint32_t value)
+{
+   align_blob(blob, sizeof(value));
+
+   return blob_write_bytes(blob, value,

[Mesa-dev] glsl: New blob.c (in preparation for shader cache)

Here are two patches that add some functions for serializing and
deserializing simple data structures, (integers of various sizes,
pointers, and strings).

This code will be used by my upcoming shader-cache work. I'm
submitting it here now because it is self-contained and documented, so
it should be ready to be reviewed now.

But it probably makes sense to wait to push this until I actually have
some reviewed code that uses it.

I want to thank Tapani for some similar code he wrote for his IR
serialization work. As attributed in the second patch below, I shared
some ideas directly from one of his patches.

-Carl

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

[Mesa-dev] [PATCH 2/2] glsl: Add blob_overwrite_bytes and blob_overwrite_uint32

From: Tapani Pälli tapani.pa...@intel.com

These functions are useful when serializing an unknown number of items
to a blob. The caller can first save the current offset, write a
placeholder uint32, write out (and count) the items, then use
blob_overwrite_uint32 with the saved offset to replace the placeholder
value.

Then, when deserializing, the reader will first read the count and
know how many subsequent items to expect.

(I wrote this code after reading a very similar patch written by
Tapani when he wrote serialization code for IR. Since I re-used the
idea of his code so directly, I've credited him as the author of this
code. --Carl)
---
 src/glsl/blob.c | 23 +++
 src/glsl/blob.h | 25 +
 2 files changed, 48 insertions(+)

diff --git a/src/glsl/blob.c b/src/glsl/blob.c
index 0af71fc..dbd698a 100644
--- a/src/glsl/blob.c
+++ b/src/glsl/blob.c
@@ -101,6 +101,21 @@ blob_create (void *mem_ctx)
 }
 
 bool
+blob_overwrite_bytes (struct blob *blob,
+  size_t offset,
+  const void *bytes,
+  size_t to_write)
+{
+   /* Detect an attempt to overwrite data out of bounds. */
+   if (offset  0 || blob-size - offset  to_write)
+  return false;
+
+   memcpy (blob-data + offset, bytes, to_write);
+
+   return true;
+}
+
+bool
 blob_write_bytes (struct blob *blob, const void *bytes, size_t to_write)
 {
if (! grow_to_fit (blob, to_write))
@@ -135,6 +150,14 @@ blob_write_uint32 (struct blob *blob, uint32_t value)
 }
 
 bool
+blob_overwrite_uint32 (struct blob *blob,
+   size_t offset,
+   uint32_t value)
+{
+   return blob_overwrite_bytes(blob, offset, value, sizeof(value));
+}
+
+bool
 blob_write_uint64 (struct blob *blob, uint64_t value)
 {
align_blob(blob, sizeof(value));
diff --git a/src/glsl/blob.h b/src/glsl/blob.h
index 374b21e..165de13 100644
--- a/src/glsl/blob.h
+++ b/src/glsl/blob.h
@@ -138,6 +138,31 @@ bool
 blob_write_uint32 (struct blob *blob, uint32_t value);
 
 /**
+ * Overwrite a uint32_t previously written to the blob.
+ *
+ * Writes a uint32_t value to an existing portion of the blob at an offset of
+ * \offset.  This data range must have previously been written to the blob by
+ * one of the blob_write_* calls.
+ *
+ *
+ * The expected usage is something like the following pattern:
+ *
+ * size_t offset;
+ *
+ * offset = blob-size;
+ * blob_write_uint32 (blob, 0); // placeholder
+ * ... various blob write calls, writing N items ...
+ * blob_overwrite_uint32 (blob, offset, N);
+ *
+ * \return True unless the requested position or position+to_write lie outside
+ * the current blob's size.
+ */
+bool
+blob_overwrite_uint32 (struct blob *blob,
+   size_t offset,
+   uint32_t value);
+
+/**
  * Add a uint64_t to a blob.
  *
  * Note: This function will only write to a uint64_t-aligned offset from the
-- 
2.1.1

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

Re: [Mesa-dev] [PATCH v3 24/24] main: remove unused float_to_uint() function

On Tue, Dec 9, 2014 at 4:07 AM, Iago Toral Quiroga ito...@igalia.com
wrote:

 From: Samuel Iglesias Gonsalvez sigles...@igalia.com

 Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
 ---
  src/mesa/main/format_utils.c | 9 -
  1 file changed, 9 deletions(-)

 diff --git a/src/mesa/main/format_utils.c b/src/mesa/main/format_utils.c
 index dc63e1f..201231e 100644
 --- a/src/mesa/main/format_utils.c
 +++ b/src/mesa/main/format_utils.c
 @@ -133,15 +133,6 @@ _mesa_format_to_array(mesa_format format, GLenum
 *type, int *num_components,
  }

  static inline unsigned
 -float_to_uint(float x)
 -{
 -   if (x  0.0f)
 -  return 0;
 -   else
 -  return x;
 -}


As per the comments on patch 14, we probably want a function like this and
it should clamp above as well as below.


 -
 -static inline unsigned
  half_to_uint(uint16_t x)
  {
 if (_mesa_half_is_negative(x))
 --
 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

Re: [Mesa-dev] [PATCH v3 08/24] mesa: Fix _mesa_swizzle_and_convert integer conversions to clamp properly

I may have brought this up before (I'm starting to not remember things) but
shouldn't we also be clamping float-to-integer as well?
--Jason

On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
wrote:

 From: Samuel Iglesias Gonsalvez sigles...@igalia.com

 Fix various conversion paths that involved integer data types of different
 sizes (uint16_t to uint8_t, int16_t to uint8_t, etc) that were not
 being clamped properly.

 Also, one of the paths was incorrectly assigning the value 12, instead of
 1,
 to the constant one.

 v2:
 - Create auxiliary clamping functions and use them in all paths that
   required clamp because of different source and destination sizes
   and signed-unsigned conversions.

 v3:
 - Create MIN_INT macro and use it.

 Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
 ---
  src/mesa/main/format_utils.c | 47
 ++--
  src/mesa/main/format_utils.h | 26 
  2 files changed, 49 insertions(+), 24 deletions(-)

 diff --git a/src/mesa/main/format_utils.c b/src/mesa/main/format_utils.c
 index 41fd043..dc63e1f 100644
 --- a/src/mesa/main/format_utils.c
 +++ b/src/mesa/main/format_utils.c
 @@ -449,7 +449,6 @@ convert_half_float(void *void_dst, int
 num_dst_channels,
 }
  }

 -
  static void
  convert_ubyte(void *void_dst, int num_dst_channels,
const void *void_src, GLenum src_type, int num_src_channels,
 @@ -469,7 +468,7 @@ convert_ubyte(void *void_dst, int num_dst_channels,
if (normalized) {
   SWIZZLE_CONVERT(uint8_t, uint16_t, _mesa_half_to_unorm(src, 8));
} else {
 - SWIZZLE_CONVERT(uint8_t, uint16_t, half_to_uint(src));
 + SWIZZLE_CONVERT(uint8_t, uint16_t,
 _mesa_unsigned_to_unsigned(half_to_uint(src), 8));
}
break;
 case GL_UNSIGNED_BYTE:
 @@ -479,35 +478,35 @@ convert_ubyte(void *void_dst, int num_dst_channels,
if (normalized) {
   SWIZZLE_CONVERT(uint8_t, int8_t, _mesa_snorm_to_unorm(src, 8,
 8));
} else {
 - SWIZZLE_CONVERT(uint8_t, int8_t, (src  0) ? 0 : src);
 + SWIZZLE_CONVERT(uint8_t, int8_t, _mesa_signed_to_unsigned(src,
 8));
}
break;
 case GL_UNSIGNED_SHORT:
if (normalized) {
   SWIZZLE_CONVERT(uint8_t, uint16_t, _mesa_unorm_to_unorm(src, 16,
 8));
} else {
 - SWIZZLE_CONVERT(uint8_t, uint16_t, src);
 + SWIZZLE_CONVERT(uint8_t, uint16_t,
 _mesa_unsigned_to_unsigned(src, 8));
}
break;
 case GL_SHORT:
if (normalized) {
   SWIZZLE_CONVERT(uint8_t, int16_t, _mesa_snorm_to_unorm(src, 16,
 8));
} else {
 - SWIZZLE_CONVERT(uint8_t, int16_t, (src  0) ? 0 : src);
 + SWIZZLE_CONVERT(uint8_t, int16_t, _mesa_signed_to_unsigned(src,
 8));
}
break;
 case GL_UNSIGNED_INT:
if (normalized) {
   SWIZZLE_CONVERT(uint8_t, uint32_t, _mesa_unorm_to_unorm(src, 32,
 8));
} else {
 - SWIZZLE_CONVERT(uint8_t, uint32_t, src);
 + SWIZZLE_CONVERT(uint8_t, uint32_t,
 _mesa_unsigned_to_unsigned(src, 8));
}
break;
 case GL_INT:
if (normalized) {
   SWIZZLE_CONVERT(uint8_t, int32_t, _mesa_snorm_to_unorm(src, 32,
 8));
} else {
 - SWIZZLE_CONVERT(uint8_t, int32_t, (src  0) ? 0 : src);
 + SWIZZLE_CONVERT(uint8_t, int32_t, _mesa_signed_to_unsigned(src,
 8));
}
break;
 default:
 @@ -542,7 +541,7 @@ convert_byte(void *void_dst, int num_dst_channels,
if (normalized) {
   SWIZZLE_CONVERT(int8_t, uint8_t, _mesa_unorm_to_snorm(src, 8,
 8));
} else {
 - SWIZZLE_CONVERT(int8_t, uint8_t, src);
 + SWIZZLE_CONVERT(int8_t, uint8_t, _mesa_unsigned_to_signed(src,
 8));
}
break;
 case GL_BYTE:
 @@ -552,28 +551,28 @@ convert_byte(void *void_dst, int num_dst_channels,
if (normalized) {
   SWIZZLE_CONVERT(int8_t, uint16_t, _mesa_unorm_to_snorm(src, 16,
 8));
} else {
 - SWIZZLE_CONVERT(int8_t, uint16_t, src);
 + SWIZZLE_CONVERT(int8_t, uint16_t, _mesa_unsigned_to_signed(src,
 8));
}
break;
 case GL_SHORT:
if (normalized) {
   SWIZZLE_CONVERT(int8_t, int16_t, _mesa_snorm_to_snorm(src, 16,
 8));
} else {
 - SWIZZLE_CONVERT(int8_t, int16_t, src);
 + SWIZZLE_CONVERT(int8_t, int16_t, _mesa_signed_to_signed(src, 8));
}
break;
 case GL_UNSIGNED_INT:
if (normalized) {
   SWIZZLE_CONVERT(int8_t, uint32_t, _mesa_unorm_to_snorm(src, 32,
 8));
} else {
 - SWIZZLE_CONVERT(int8_t, uint32_t, src);
 + SWIZZLE_CONVERT(int8_t, uint32_t, _mesa_unsigned_to_signed(src,
 8));
}
break;
 case GL_INT:
if (normalized) {
   SWIZZLE_CONVERT(int8_t, int32_t, _mesa_snorm_to_snorm(src, 32,
 8));
} else {
 - SWIZZLE_CONVERT(int8_t,

Re: [Mesa-dev] [PATCH v3 00/24] auto-generate pack/unpack functions

Iago,
These are looking really good.  I had a few comments on 3 or 4 of them but
only one or two major things (float-to-int clampping in a couple of
places).  All of the patches I didn't reply to are
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com

On Tue, Dec 9, 2014 at 4:12 AM, Iago Toral ito...@igalia.com wrote:

 On Tue, 2014-12-09 at 13:06 +0100, Iago Toral Quiroga wrote:
  This is the first of two series that aim to address:
  https://bugs.freedesktop.org/show_bug.cgi?id=84566
 
  A branch with this series is available here:
  https://github.com/Igalia/mesa/tree/itoral-autogen-packing-review-v3

 As with the previous versions this patch was held for moderation due to
 its size:

 [PATCH v3 15/24] mesa: Autogenerate format_unpack.c

 If it does not reach the list in the end it can be reviewed from the
 link above.

 Iago

  Links to previous versions of the series:
  v2:
 http://lists.freedesktop.org/archives/mesa-dev/2014-December/071622.html
  v1:
 http://lists.freedesktop.org/archives/mesa-dev/2014-November/070898.html
 
  Main changes in v3:
- Do not use a union/struct and bitmasks to implement and access
  mesa_array_format, that won't work on big-endian as pointed out by
 Ian.
  The new implementation drops the union/struct and accesses
  mesa_array_format as a uint32_t bitfield only.
- Remove the unused float_to_uint helper (last patch in the series)
 
  Notes:
- Patches 1, 3-7, 9 are already reviewed-by Ian.
 
  Tested on i965, classic swrast and gallium (radeon, nouveau, llvmpipe)
 without
  regressions.
 
  Iago Toral Quiroga (3):
mesa: Fix incorrect assertion in init_teximage_fields_ms
swrast: Remove unused variable.
mesa: Let _mesa_get_format_base_format also handle mesa_array_format.
 
  Jason Ekstrand (9):
mesa/format_utils: Fix a bug in unorm_to_float helper function
mesa: Fix packing/unpacking of MESA_FORMAT_R5G6B5_UNORM
mesa/colormac: Remove an unused macro
mesa: Fix A1R5G5B5 packing/unpacking
mesa/format_utils: Prefix and expose the conversion helper functions
main: Add a concept of an array format
mesa: Add a _mesa_is_format_color_format helper
mesa: Autogenerate most of format_pack.c
mesa: Autogenerate format_unpack.c
 
  Samuel Iglesias Gonsalvez (12):
mesa: Fix get_texbuffer_format().
mesa: Fix _mesa_swizzle_and_convert integer conversions to clamp
  properly
configure: require python mako module
mesa: Add _mesa_pack_uint_rgba_row() format conversion function
mesa: Add non-normalized formats support for ubyte packing functions
mesa/format_pack: Add _mesa_pack_int_rgba_row()
mesa/formats: add new mesa formats and their pack/unpack functions.
mesa: use format conversion functions in swrast
mesa/pack: use autogenerated format_pack functions
mesa/main/pack_tmp.h: Add float conversion support
mesa/pack: refactor _mesa_pack_rgba_span_float()
main: remove unused float_to_uint() function
 
   configure.ac  |2 +
   docs/install.html |6 +-
   m4/ax_check_python_mako_module.m4 |   77 +
   src/mesa/Makefile.am  |   18 +
   src/mesa/Makefile.sources |4 +-
   src/mesa/SConscript   |   14 +
   src/mesa/main/.gitignore  |2 +
   src/mesa/main/colormac.h  |3 -
   src/mesa/main/format_info.py  |   16 +
   src/mesa/main/format_pack.c   | 2994 -
   src/mesa/main/format_pack.h   |6 +
   src/mesa/main/format_pack.py  | 1118 ++
   src/mesa/main/format_parser.py|   47 +
   src/mesa/main/format_unpack.c | 4400
 -
   src/mesa/main/format_unpack.py|  891 
   src/mesa/main/format_utils.c  |  271 +--
   src/mesa/main/format_utils.h  |  131 ++
   src/mesa/main/formats.c   |  271 ++-
   src/mesa/main/formats.csv |   13 +
   src/mesa/main/formats.h   |  156 +-
   src/mesa/main/pack.c  | 2111 +++---
   src/mesa/main/pack_tmp.h  |   76 +-
   src/mesa/main/teximage.c  |6 +-
   src/mesa/main/texstore.c  |2 +-
   src/mesa/swrast/s_drawpix.c   |3 -
   src/mesa/swrast/s_texfetch.c  |   13 +
   src/mesa/swrast/s_texfetch_tmp.h  | 1359 +---
   27 files changed, 3403 insertions(+), 10607 deletions(-)
   create mode 100644 m4/ax_check_python_mako_module.m4
   delete mode 100644 src/mesa/main/format_pack.c
   create mode 100644 src/mesa/main/format_pack.py
   delete mode 100644 src/mesa/main/format_unpack.c
   create mode 100644 src/mesa/main/format_unpack.py
 


 ___
 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/1] util: Silence signed-unsigned comparison warnings

2014-12-11 Thread Jan Vesely

Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
---
 src/util/register_allocate.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c
index 1cfd66f..af7a20c 100644
--- a/src/util/register_allocate.c
+++ b/src/util/register_allocate.c
@@ -79,7 +79,7 @@
 #include main/bitset.h
 #include register_allocate.h
 
-#define NO_REG ~0
+#define NO_REG ~0U
 
 struct ra_reg {
BITSET_WORD *conflicts;
@@ -251,7 +251,7 @@ void
 ra_add_transitive_reg_conflict(struct ra_regs *regs,
   unsigned int base_reg, unsigned int reg)
 {
-   int i;
+   unsigned int i;
 
ra_add_reg_conflict(regs, reg, base_reg);
 
@@ -328,7 +328,7 @@ ra_set_finalize(struct ra_regs *regs, unsigned int 
**q_values)
 
 for (rc = 0; rc  regs-count; rc++) {
int conflicts = 0;
-   int i;
+   unsigned int i;
 
 if (!reg_belongs_to_class(rc, regs-classes[c]))
   continue;
@@ -481,7 +481,7 @@ ra_simplify(struct ra_graph *g)
 }
   }
 
-  if (!progress  best_optimistic_node != ~0) {
+  if (!progress  best_optimistic_node != ~0U) {
 decrement_q(g, best_optimistic_node);
 g-stack[g-stack_count] = best_optimistic_node;
 g-stack_count++;
@@ -501,10 +501,10 @@ ra_simplify(struct ra_graph *g)
 static bool
 ra_select(struct ra_graph *g)
 {
-   int i;
int start_search_reg = 0;
 
while (g-stack_count != 0) {
+  unsigned int i;
   unsigned int ri;
   unsigned int r = -1;
   int n = g-stack[g-stack_count - 1];
@@ -585,7 +585,7 @@ ra_set_node_reg(struct ra_graph *g, unsigned int n, 
unsigned int reg)
 static float
 ra_get_spill_benefit(struct ra_graph *g, unsigned int n)
 {
-   int j;
+   unsigned int j;
float benefit = 0;
int n_class = g-nodes[n].class;
 
-- 
2.1.0

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

[Mesa-dev] [PATCH] i965/gen8+: Remove false perf debug message about MOCS

2014-12-11 Thread Ben Widawsky

We support MOCS on both gen8 and gen9, so the message seems meaningless. Remove
it to avoid confusion.

Trivial.

Cc: Kristian Høgsberg k...@bitplanet.net
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 src/mesa/drivers/dri/i965/gen8_misc_state.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen8_misc_state.c 
b/src/mesa/drivers/dri/i965/gen8_misc_state.c
index f993650..bd1d5cc 100644
--- a/src/mesa/drivers/dri/i965/gen8_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_misc_state.c
@@ -32,9 +32,6 @@
 static void upload_state_base_address(struct brw_context *brw)
 {
uint32_t mocs_wb = brw-gen = 9 ? SKL_MOCS_WB : BDW_MOCS_WB;
-
-   perf_debug(Missing MOCS setup for STATE_BASE_ADDRESS.);
-
int pkt_len = brw-gen = 9 ? 19 : 16;
 
BEGIN_BATCH(pkt_len);
-- 
2.1.3

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

Re: [Mesa-dev] [PATCH] it_to_mesa: remove unused 'target' variable

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

On 12/11/2014 07:45 AM, Brian Paul wrote:
 ---
  src/mesa/program/ir_to_mesa.cpp | 1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
 index 68e2597..5196545 100644
 --- a/src/mesa/program/ir_to_mesa.cpp
 +++ b/src/mesa/program/ir_to_mesa.cpp
 @@ -2943,7 +2943,6 @@ _mesa_ir_link_shader(struct gl_context *ctx, struct 
 gl_shader_program *prog)
  
/* Lowering */
do_mat_op_to_vec(ir);
 -  GLenum target = 
 _mesa_shader_stage_to_program(prog-_LinkedShaders[i]-Stage);
lower_instructions(ir, (MOD_TO_FRACT | DIV_TO_MUL_RCP | EXP_TO_EXP2
| LOG_TO_LOG2 | INT_DIV_TO_MUL_RCP
| ((options-EmitNoPow) ? POW_TO_EXP2 : 0)));
 

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

[Mesa-dev] `extern C { #include foo.h }` is evil


Including system's headers inside extern C { ... } is not safe, as system 
headers may have C++ code in them, and C++ code inside extern C  { .. } 
doesn't work.

This is because putting code inside extern C won't make __plusplus define go 
away, that is, the headers being included thinks is free to use C++ as it sees 
fits.

Including non-system headers inside extern C  is not safe either, because 
non-system headers end up including system headers, hence fall in the above 
case too.

Conclusion, includes inside extern C is simply not portable.


I said this before, but I failed to keep a close watch on this.  And the 
unfortunate thing is that sometimes things appear to work when the above rule 
is not observed, but it's enough to switch to slightly different SDKs / 
standard libraries and build fails miserably...

Yes this happens with MSVC headers which often have C++ on some places, but it 
could happen with any other OS really.


Please help do the right thing here, which is add extern C to headers 
themselves that need to be included from C++ source files.  Thanks.


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

[Mesa-dev] [PATCH] mesa: Add mesa SHA-1 functions

From: Kristian Høgsberg k...@bitplanet.net

The upcoming shader cache uses the SHA-1 algorithm for cryptographic
naming. These new mesa_sha1 functions are implemented with the nettle
library.
---

This patch is another in support of my upcoming shader-cache work. Thanks to
Kritian for coding this piece.

As currently written, this patch introduces a new dependency of Mesa on the
Nettle library to implement SHA-1. I'm open to recommendations if people would 
prefer some other option.

For example, the xserver can be configured to get a SHA-1 implementation from
libmd, libc, CommonCrypto, CryptoAPI, libnettle, libgcrypt, libsha1, or
openssl.

I don't know if it's important to offer as many options as that, which is why
I'm asking for opinions here.

Thanks,

-Carl

 configure.ac  |  7 
 src/util/Makefile.am  |  2 ++
 src/util/Makefile.sources |  2 ++
 src/util/sha1.c   | 81 +++
 src/util/sha1.h   | 22 +
 5 files changed, 114 insertions(+)
 create mode 100644 src/util/sha1.c
 create mode 100644 src/util/sha1.h

diff --git a/configure.ac b/configure.ac
index 1d9d015..bbefd21 100644
--- a/configure.ac
+++ b/configure.ac
@@ -876,6 +876,13 @@ fi
 
 AC_SUBST([MESA_LLVM])
 
+# Require libnettle for SHA-1 calculations
+PKG_CHECK_MODULES([NETTLE], [nettle],
+  [have_nettle=yes], [have_nettle=no])
+if test x$have_nettle = xno; then
+   AC_MSG_ERROR([Cannot find required nettle library (or nettle-dev package)])
+fi
+
 # Check for libdrm
 PKG_CHECK_MODULES([LIBDRM], [libdrm = $LIBDRM_REQUIRED],
   [have_libdrm=yes], [have_libdrm=no])
diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index 8d5f90e..30899de 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -37,6 +37,8 @@ libmesautil_la_SOURCES = \
$(MESA_UTIL_FILES) \
$(MESA_UTIL_GENERATED_FILES)
 
+libmesautil_la_LIBADD = -lnettle
+
 BUILT_SOURCES = $(MESA_UTIL_GENERATED_FILES)
 CLEANFILES = $(BUILT_SOURCES)
 
diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index 9e27424..22c6a22 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -4,6 +4,8 @@ MESA_UTIL_FILES :=  \
register_allocate.c \
register_allocate.h \
rgtc.c \
+   sha1.c \
+   sha1.h \
strtod.cpp
 
 MESA_UTIL_GENERATED_FILES = \
diff --git a/src/util/sha1.c b/src/util/sha1.c
new file mode 100644
index 000..3025df6
--- /dev/null
+++ b/src/util/sha1.c
@@ -0,0 +1,81 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include stdlib.h
+#include nettle/sha.h
+
+#include sha1.h
+
+struct mesa_sha1 *
+_mesa_sha1_init(void)
+{
+struct sha1_ctx *ctx = malloc(sizeof(*ctx));
+
+if (!ctx)
+return NULL;
+sha1_init(ctx);
+
+return (struct mesa_sha1 *) ctx;
+}
+
+int
+_mesa_sha1_update(struct mesa_sha1 *ctx, const void *data, int size)
+{
+   sha1_update((struct sha1_ctx *) ctx, size, data);
+
+   return 1;
+}
+
+int
+_mesa_sha1_final(struct mesa_sha1 *ctx, unsigned char result[20])
+{
+sha1_digest((struct sha1_ctx *) ctx, 20, result);
+free(ctx);
+
+return 1;
+}
+
+void
+_mesa_sha1_compute(const void *data, size_t size, unsigned char result[20])
+{
+   struct sha1_ctx ctx;
+
+   sha1_init(ctx);
+   sha1_update(ctx, size, data);
+   sha1_digest(ctx, 20, result);
+}
+
+char *
+_mesa_sha1_format(char *buf, const unsigned char *sha1)
+{
+   static const char hex_digits[] = 0123456789abcdef;
+   int i;
+
+   for (i = 0; i  40; i += 2) {
+  buf[i] = hex_digits[sha1[i  1]  4];
+  buf[i + 1] = hex_digits[sha1[i  1]  0x0f];
+   }
+   buf[i] = '\0';
+
+   return buf;
+}
diff --git a/src/util/sha1.h b/src/util/sha1.h
new file mode 100644
index 000..1616134
--- /dev/null
+++ b/src/util/sha1.h
@@ -0,0 +1,22 @@
+#ifndef SHA1_H
+#define SHA1_H

Re: [Mesa-dev] [PATCH] mesa: Add mesa SHA-1 functions


On 12/11/2014 02:51 PM, Carl Worth wrote:

From: Kristian Høgsberg k...@bitplanet.net

The upcoming shader cache uses the SHA-1 algorithm for cryptographic
naming. These new mesa_sha1 functions are implemented with the nettle
library.
---

This patch is another in support of my upcoming shader-cache work. Thanks to
Kritian for coding this piece.

As currently written, this patch introduces a new dependency of Mesa on the
Nettle library to implement SHA-1. I'm open to recommendations if people would 
prefer some other option.

For example, the xserver can be configured to get a SHA-1 implementation from
libmd, libc, CommonCrypto, CryptoAPI, libnettle, libgcrypt, libsha1, or
openssl.

I don't know if it's important to offer as many options as that, which is why
I'm asking for opinions here.



We'll need a solution for Windows too.  I don't have time right now to 
do any research into that.


-Brian




Thanks,

-Carl

  configure.ac  |  7 
  src/util/Makefile.am  |  2 ++
  src/util/Makefile.sources |  2 ++
  src/util/sha1.c   | 81 +++
  src/util/sha1.h   | 22 +
  5 files changed, 114 insertions(+)
  create mode 100644 src/util/sha1.c
  create mode 100644 src/util/sha1.h

diff --git a/configure.ac b/configure.ac
index 1d9d015..bbefd21 100644
--- a/configure.ac
+++ b/configure.ac
@@ -876,6 +876,13 @@ fi

  AC_SUBST([MESA_LLVM])

+# Require libnettle for SHA-1 calculations
+PKG_CHECK_MODULES([NETTLE], [nettle],
+  [have_nettle=yes], [have_nettle=no])
+if test x$have_nettle = xno; then
+   AC_MSG_ERROR([Cannot find required nettle library (or nettle-dev package)])
+fi
+
  # Check for libdrm
  PKG_CHECK_MODULES([LIBDRM], [libdrm = $LIBDRM_REQUIRED],
[have_libdrm=yes], [have_libdrm=no])
diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index 8d5f90e..30899de 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -37,6 +37,8 @@ libmesautil_la_SOURCES = \
$(MESA_UTIL_FILES) \
$(MESA_UTIL_GENERATED_FILES)

+libmesautil_la_LIBADD = -lnettle
+
  BUILT_SOURCES = $(MESA_UTIL_GENERATED_FILES)
  CLEANFILES = $(BUILT_SOURCES)

diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index 9e27424..22c6a22 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -4,6 +4,8 @@ MESA_UTIL_FILES :=  \
register_allocate.c \
register_allocate.h \
rgtc.c \
+   sha1.c \
+   sha1.h \
strtod.cpp

  MESA_UTIL_GENERATED_FILES = \
diff --git a/src/util/sha1.c b/src/util/sha1.c
new file mode 100644
index 000..3025df6
--- /dev/null
+++ b/src/util/sha1.c
@@ -0,0 +1,81 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include stdlib.h
+#include nettle/sha.h
+
+#include sha1.h
+
+struct mesa_sha1 *
+_mesa_sha1_init(void)
+{
+struct sha1_ctx *ctx = malloc(sizeof(*ctx));
+
+if (!ctx)
+return NULL;
+sha1_init(ctx);
+
+return (struct mesa_sha1 *) ctx;
+}
+
+int
+_mesa_sha1_update(struct mesa_sha1 *ctx, const void *data, int size)
+{
+   sha1_update((struct sha1_ctx *) ctx, size, data);
+
+   return 1;
+}
+
+int
+_mesa_sha1_final(struct mesa_sha1 *ctx, unsigned char result[20])
+{
+sha1_digest((struct sha1_ctx *) ctx, 20, result);
+free(ctx);
+
+return 1;
+}
+
+void
+_mesa_sha1_compute(const void *data, size_t size, unsigned char result[20])
+{
+   struct sha1_ctx ctx;
+
+   sha1_init(ctx);
+   sha1_update(ctx, size, data);
+   sha1_digest(ctx, 20, result);
+}
+
+char *
+_mesa_sha1_format(char *buf, const unsigned char *sha1)
+{
+   static const char hex_digits[] = 0123456789abcdef;
+   int i;
+
+   for (i = 0; i  40; i += 2) {
+  buf[i] = hex_digits[sha1[i  1]  4];
+  buf[i + 1] = hex_digits[sha1[i  1]  0x0f];
+   }
+   buf[i] = '\0';
+
+   return buf;
+}
diff

Re: [Mesa-dev] `extern C { #include foo.h }` is evil


On 12/11/2014 02:32 PM, Jose Fonseca wrote:


Including system's headers inside extern C { ... } is not safe, as system headers may 
have C++ code in them, and C++ code inside extern C  { .. } doesn't work.

This is because putting code inside extern C won't make __plusplus define go 
away, that is, the headers being included thinks is free to use C++ as it sees fits.

Including non-system headers inside extern C  is not safe either, because 
non-system headers end up including system headers, hence fall in the above case too.

Conclusion, includes inside extern C is simply not portable.


I said this before, but I failed to keep a close watch on this.  And the unfortunate 
thing is that sometimes things appear to work when the above rule is not 
observed, but it's enough to switch to slightly different SDKs / standard libraries and 
build fails miserably...

Yes this happens with MSVC headers which often have C++ on some places, but it 
could happen with any other OS really.


Please help do the right thing here, which is add extern C to headers 
themselves that need to be included from C++ source files.  Thanks.


In particular, the #include util/u_atomic.h in glsl_parser_extras.cpp 
is causing us grief with some versions of MSVC.


I've reverted 9db278d0e2b3bf35b28f00ab7ec3392443aae6b3 locally for now. 
 I'll see if I can work on a proper fix for this tomorrow.


-Brian

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

[Mesa-dev] [PATCH] include: Add helper header to help trap includes inside extern C.

From: José Fonseca jfons...@vmware.com

This is just to help repro and fixing these issues with any C++ compiler --

commiting this will of course wait until all issues are addressed.


$ scons src/glsl/
scons: Reading SConscript files ...
Checking for GCC ...  yes
Checking for Clang ...  no
Checking for X11 (x11 xext xdamage xfixes glproto = 1.4.13)... yes
Checking for XCB (x11-xcb xcb-glx = 1.8.1 xcb-dri2 = 1.8)... yes
Checking for XF86VIDMODE (xxf86vm)... yes
Checking for DRM (libdrm = 2.4.38)... yes
Checking for UDEV (libudev = 151)... yes
warning: LLVM disabled: not building llvmpipe
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: build/linux-x86_64-debug/glsl
  Compiling src/glsl/ast_array_index.cpp ...
  Compiling src/glsl/ast_expr.cpp ...
  Compiling src/glsl/ast_function.cpp ...
  Compiling src/glsl/ast_to_hir.cpp ...
  Compiling src/glsl/ast_type.cpp ...
  Compiling src/glsl/builtin_functions.cpp ...
In file included from include/c99_compat.h:28:0,
 from src/mapi/u_compiler.h:4,
 from src/mapi/u_thread.h:47,
 from src/mapi/glapi/glapi.h:47,
 from src/mesa/main/mtypes.h:42,
 from src/mesa/main/errors.h:47,
 from src/mesa/main/imports.h:41,
 from src/mesa/main/core.h:44,
 from src/glsl/builtin_functions.cpp:58:
include/no_extern_c.h:48:1: error: template with C linkage
 templateclass T class _IncludeInsideExternCNotPortable;
 ^
In file included from include/c99_compat.h:28:0,
 from include/c11/threads.h:38,
 from src/mapi/u_thread.h:49,
 from src/mapi/glapi/glapi.h:47,
 from src/mesa/main/mtypes.h:42,
 from src/mesa/main/errors.h:47,
 from src/mesa/main/imports.h:41,
 from src/mesa/main/core.h:44,
 from src/glsl/builtin_functions.cpp:58:
include/no_extern_c.h:48:1: error: template with C linkage
 templateclass T class _IncludeInsideExternCNotPortable;
 ^
  Compiling src/glsl/builtin_types.cpp ...
  Compiling src/glsl/builtin_variables.cpp ...
scons: *** [build/linux-x86_64-debug/glsl/builtin_functions.os] Error 1
scons: building terminated because of errors.
---
 include/c99_compat.h  |  2 ++
 include/no_extern_c.h | 49 +
 src/util/u_atomic.h   |  3 +++
 3 files changed, 54 insertions(+)
 create mode 100644 include/no_extern_c.h

diff --git a/include/c99_compat.h b/include/c99_compat.h
index 429c601..a8819ac 100644
--- a/include/c99_compat.h
+++ b/include/c99_compat.h
@@ -25,6 +25,8 @@
  *
  **/
 
+#include no_extern_c.h
+
 #ifndef _C99_COMPAT_H_
 #define _C99_COMPAT_H_
 
diff --git a/include/no_extern_c.h b/include/no_extern_c.h
new file mode 100644
index 000..d038a4f
--- /dev/null
+++ b/include/no_extern_c.h
@@ -0,0 +1,49 @@
+/**
+ *
+ * Copyright 2014 VMware, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+
+/*
+ * Including system's headers inside `extern C { ... }` is not safe, as 
system
+ * headers may have C++ code in them, and C++ code inside extern C
+ * leads to syntatically incorrect code.
+ *
+ * This is because putting code inside extern C won't make __cplusplus define
+ * go away, that is, the headers being included thinks is free to use C++ as it
+ * sees fits.
+ *
+ * Including non-system headers inside extern C  is not safe either, because
+ * non-system headers end up including system headers, hence fall in the above
+ * case too.
+ *
+ * Conclusion, includes inside extern C is simply not portable.
+ *
+ *
+ * This header helps surface

Re: [Mesa-dev] `extern C { #include foo.h }` is evil

OK.  I found a way to make it easier to trap this sort of issues going forward, 
regardless of compiler. See patch I just posted.

Jose

From: Brian Paul bri...@vmware.com
Sent: 11 December 2014 22:05
To: mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca
Subject: Re: [Mesa-dev] `extern C { #include foo.h }`  is evil

On 12/11/2014 02:32 PM, Jose Fonseca wrote:

 Including system's headers inside extern C { ... } is not safe, as system 
 headers may have C++ code in them, and C++ code inside extern C  { .. } 
 doesn't work.

 This is because putting code inside extern C won't make __plusplus define 
 go away, that is, the headers being included thinks is free to use C++ as it 
 sees fits.

 Including non-system headers inside extern C  is not safe either, because 
 non-system headers end up including system headers, hence fall in the above 
 case too.

 Conclusion, includes inside extern C is simply not portable.

 I said this before, but I failed to keep a close watch on this.  And the 
 unfortunate thing is that sometimes things appear to work when the above 
 rule is not observed, but it's enough to switch to slightly different SDKs / 
 standard libraries and build fails miserably...

 Yes this happens with MSVC headers which often have C++ on some places, but 
 it could happen with any other OS really.

 Please help do the right thing here, which is add extern C to headers 
 themselves that need to be included from C++ source files.  Thanks.

In particular, the #include util/u_atomic.h in glsl_parser_extras.cpp
is causing us grief with some versions of MSVC.

I've reverted 9db278d0e2b3bf35b28f00ab7ec3392443aae6b3 locally for now.
  I'll see if I can work on a proper fix for this tomorrow.

-Brian

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

[Mesa-dev] [PATCH 00/16] More fixes for dEQP failing tests

Hello,

This is the second series of patches fixing over 90 (unrelated) dEQP failing 
tests.
Again, the test failures were gathered on i965 (gen8) against 10.3.3, but there 
are several driver and version agnostic fixes.

A GIT tree with these patches based on git-ff96537 is available at:
https://github.com/Igalia/mesa/tree/deqp-fixes-batch2-rebased

There are not known piglit regressions with this series.

cheers,
Eduardo Lima


Patch summary:

Eduardo Lima Mitev (9):
  i965: Sets missing vertex shader constant values for HighInt format
  mesa: Check first that draw buffers are valid for glDrawBuffers on
GLES3
  mesa: Clamps the stencil value masks to GLint when queried
  mesa: Allows querying GL_SAMPLER_BINDING on GLES3 profile
  mesa: Returns a GL_INVALID_VALUE error if num of fbos in
glDeleteFramebuffers is negative
  mesa: Returns a GL_INVALID_VALUE error if num of fbos in
glDeleteRenderbuffers is negative
  mesa: Adds check for integer internal formal and num samples in
glRenderbufferStorageMultisample
  mesa: Returns a GL_INVALID_VALUE error if num of texs in
glDeleteTextures is negative
  mesa: Returns correct error values from gl(Get)SamplerParameter*() in
GLES3

Iago Toral Quiroga (3):
  mesa: Depth ans stencil attachments must be the same in OpenGL ES3
  i965: Fix bitcast operations with negate
  mesa: Fix error reporting for some cases of incomplete FBO attachments

Samuel Iglesias Gonsalvez (4):
  glsl: fix assignment of multiple scalar and vecs to matrices.
  main: fix return GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL value
  main: round floating-point value to nearest integer in
glGetTexParameteriv()
  main: round floating-point value to nearest integer in
glGetSamplerParameteriv()

 src/glsl/ast_function.cpp  | 121 ++---
 src/mesa/drivers/dri/i965/brw_context.c|   6 ++
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |  41 -
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  40 ++--
 src/mesa/main/buffers.c|  31 +--
 src/mesa/main/fbobject.c   |  61 -
 src/mesa/main/get.c|  11 ++-
 src/mesa/main/get_hash_params.py   |  11 ++-
 src/mesa/main/samplerobj.c |  80 
 src/mesa/main/texobj.c |   5 +
 src/mesa/main/texparam.c   |  17 +++-
 11 files changed, 324 insertions(+), 100 deletions(-)

-- 
2.1.3

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

[Mesa-dev] [PATCH 01/16] i965: Sets missing vertex shader constant values for HighInt format

The range's min and max, and the precision value are not set correctly for the
vertex shader constants.

Fixes 1 dEQP test: 
dEQP-GLES3.functional.state_query.shader.precision_vertex_highp_int
---
 src/mesa/drivers/dri/i965/brw_context.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 860ee22d..03b4ee3 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -480,6 +480,12 @@ brw_initialize_context_constants(struct brw_context *brw)
ctx-Const.Program[MESA_SHADER_FRAGMENT].HighInt = 
ctx-Const.Program[MESA_SHADER_FRAGMENT].LowInt;
ctx-Const.Program[MESA_SHADER_FRAGMENT].MediumInt = 
ctx-Const.Program[MESA_SHADER_FRAGMENT].LowInt;
 
+   ctx-Const.Program[MESA_SHADER_VERTEX].LowInt.RangeMin = 31;
+   ctx-Const.Program[MESA_SHADER_VERTEX].LowInt.RangeMax = 30;
+   ctx-Const.Program[MESA_SHADER_VERTEX].LowInt.Precision = 0;
+   ctx-Const.Program[MESA_SHADER_VERTEX].HighInt = 
ctx-Const.Program[MESA_SHADER_VERTEX].LowInt;
+   ctx-Const.Program[MESA_SHADER_VERTEX].MediumInt = 
ctx-Const.Program[MESA_SHADER_VERTEX].LowInt;
+
if (brw-gen = 7) {
   ctx-Const.Program[MESA_SHADER_FRAGMENT].MaxAtomicCounters = 
MAX_ATOMIC_COUNTERS;
   ctx-Const.Program[MESA_SHADER_VERTEX].MaxAtomicCounters = 
MAX_ATOMIC_COUNTERS;
-- 
2.1.3

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

[Mesa-dev] [PATCH 00/16] More fixes for dEQP failing tests

Hello,

This is the second series of patches fixing over 90 (unrelated) dEQP failing 
tests.
Again, the test failures were gathered on i965 (gen8) against 10.3.3, but there 
are several driver and version agnostic fixes.

A GIT tree with these patches based on git-ff96537 is available at:
https://github.com/Igalia/mesa/tree/deqp-fixes-batch2-rebased

There are not known piglit regressions with this series.

cheers,
Eduardo Lima


Patch summary:

Eduardo Lima Mitev (9):
  i965: Sets missing vertex shader constant values for HighInt format
  mesa: Check first that draw buffers are valid for glDrawBuffers on
GLES3
  mesa: Clamps the stencil value masks to GLint when queried
  mesa: Allows querying GL_SAMPLER_BINDING on GLES3 profile
  mesa: Returns a GL_INVALID_VALUE error if num of fbos in
glDeleteFramebuffers is negative
  mesa: Returns a GL_INVALID_VALUE error if num of fbos in
glDeleteRenderbuffers is negative
  mesa: Adds check for integer internal formal and num samples in
glRenderbufferStorageMultisample
  mesa: Returns a GL_INVALID_VALUE error if num of texs in
glDeleteTextures is negative
  mesa: Returns correct error values from gl(Get)SamplerParameter*() in
GLES3

Iago Toral Quiroga (3):
  mesa: Depth ans stencil attachments must be the same in OpenGL ES3
  i965: Fix bitcast operations with negate
  mesa: Fix error reporting for some cases of incomplete FBO attachments

Samuel Iglesias Gonsalvez (4):
  glsl: fix assignment of multiple scalar and vecs to matrices.
  main: fix return GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL value
  main: round floating-point value to nearest integer in
glGetTexParameteriv()
  main: round floating-point value to nearest integer in
glGetSamplerParameteriv()

 src/glsl/ast_function.cpp  | 121 ++---
 src/mesa/drivers/dri/i965/brw_context.c|   6 ++
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |  41 -
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  40 ++--
 src/mesa/main/buffers.c|  31 +--
 src/mesa/main/fbobject.c   |  61 -
 src/mesa/main/get.c|  11 ++-
 src/mesa/main/get_hash_params.py   |  11 ++-
 src/mesa/main/samplerobj.c |  80 
 src/mesa/main/texobj.c |   5 +
 src/mesa/main/texparam.c   |  17 +++-
 11 files changed, 324 insertions(+), 100 deletions(-)

-- 
2.1.3

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

[Mesa-dev] [PATCH 06/16] glsl: fix assignment of multiple scalar and vecs to matrices.

From: Samuel Iglesias Gonsalvez sigles...@igalia.com

When a vec has more elements than row components in a matrix, the
code could end up failing an assert inside assign_to_matrix_column().

This patch makes sure that when there is still room in the matrix for
more elements (but in other columns of the matrix), the data is actually
assigned.

This patch fixes the following dEQP test:

  
dEQP-GLES3.functional.shaders.conversions.matrix_combine.float_bvec4_ivec2_bool_to_mat4x2_vertex

No piglit regressions observed

Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
---
 src/glsl/ast_function.cpp | 121 ++
 1 file changed, 68 insertions(+), 53 deletions(-)

diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index cbff9d8..451e3be 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -1334,67 +1334,82 @@ emit_inline_matrix_constructor(const glsl_type *type,
   unsigned row_idx = 0;
 
   foreach_in_list(ir_rvalue, rhs, parameters) {
-const unsigned components_remaining_this_column = rows - row_idx;
+unsigned components_remaining_this_column;
 unsigned rhs_components = rhs-type-components();
 unsigned rhs_base = 0;
 
-/* Since the parameter might be used in the RHS of two assignments,
- * generate a temporary and copy the paramter there.
- */
-ir_variable *rhs_var =
-   new(ctx) ir_variable(rhs-type, mat_ctor_vec, ir_var_temporary);
-instructions-push_tail(rhs_var);
-
-ir_dereference *rhs_var_ref =
-   new(ctx) ir_dereference_variable(rhs_var);
-ir_instruction *inst = new(ctx) ir_assignment(rhs_var_ref, rhs, NULL);
-instructions-push_tail(inst);
-
-/* Assign the current parameter to as many components of the matrix
- * as it will fill.
- *
- * NOTE: A single vector parameter can span two matrix columns.  A
- * single vec4, for example, can completely fill a mat2.
- */
-if (rhs_components = components_remaining_this_column) {
-   const unsigned count = MIN2(rhs_components,
-   components_remaining_this_column);
-
-   rhs_var_ref = new(ctx) ir_dereference_variable(rhs_var);
-
-   ir_instruction *inst = assign_to_matrix_column(var, col_idx,
-  row_idx,
-  rhs_var_ref, 0,
-  count, ctx);
-   instructions-push_tail(inst);
-
-   rhs_base = count;
+ /* Since the parameter might be used in the RHS of two assignments,
+  * generate a temporary and copy the paramter there.
+  */
+ ir_variable *rhs_var =
+new(ctx) ir_variable(rhs-type, mat_ctor_vec, ir_var_temporary);
+ instructions-push_tail(rhs_var);
+
+ ir_dereference *rhs_var_ref =
+new(ctx) ir_dereference_variable(rhs_var);
+ ir_instruction *inst = new(ctx) ir_assignment(rhs_var_ref, rhs, NULL);
+ instructions-push_tail(inst);
+
+ do {
+components_remaining_this_column = rows - row_idx;
+/* Assign the current parameter to as many components of the matrix
+ * as it will fill.
+ *
+ * NOTE: A single vector parameter can span two matrix columns.  A
+ * single vec4, for example, can completely fill a mat2.
+ */
+if (components_remaining_this_column  0 
+(rhs_components - rhs_base) = 
components_remaining_this_column) {
+   const unsigned count = MIN2(rhs_components - rhs_base,
+   components_remaining_this_column);
 
-   col_idx++;
-   row_idx = 0;
-}
+   rhs_var_ref = new(ctx) ir_dereference_variable(rhs_var);
 
-/* If there is data left in the parameter and components left to be
- * set in the destination, emit another assignment.  It is possible
- * that the assignment could be of a vec4 to the last element of the
- * matrix.  In this case col_idx==cols, but there is still data
- * left in the source parameter.  Obviously, don't emit an assignment
- * to data outside the destination matrix.
- */
-if ((col_idx  cols)  (rhs_base  rhs_components)) {
-   const unsigned count = rhs_components - rhs_base;
+   ir_instruction *inst = assign_to_matrix_column(var, col_idx,
+  row_idx,
+  rhs_var_ref, 0,
+  count, ctx);
+   instructions-push_tail(inst);
 
-   rhs_var_ref = new(ctx)

[Mesa-dev] [PATCH 05/16] i965: Fix bitcast operations with negate

From: Iago Toral Quiroga ito...@igalia.com

For code such as this in a vertex or fragment shader:

uniform float in0;
flat out float out0;
...
out0 = ceil(in0)

We generate this IR:

(assign  (x) (var_ref packed:out0)
   (expression int bitcast_f2i
   (expression float ceil (var_ref in0) ) ) )

In i965, this would eventually become:

rndd(8) g141.xF   -g30,4,1.xF
mov(8)  g61.xD-g144,4,1.xD
mov(8)  g1161Dg64,4,1D

which does not produce the expected result.

The problem has to do with the second instruction, that changes the
type to D at the same time it does the negate. For this to work we
need to negate first with the original type, then change the type
to the bitcast destination so we produce code like this instead:

rndd(8) g141.xF   -g30,4,1.xF
mov(8)  g61.xF-g144,4,1.xF
mov(8)  g1161Dg64,4,1D

Fixes the following 42 dEQP tests:
dEQP-GLES3.functional.shaders.builtin_functions.common.ceil.*_vertex
dEQP-GLES3.functional.shaders.builtin_functions.common.ceil.*_fragment
dEQP-GLES3.functional.shaders.builtin_functions.precision.ceil._*vertex.*
dEQP-GLES3.functional.shaders.builtin_functions.precision.ceil._*fragment.*
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   | 41 +++---
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 40 +
 2 files changed, 71 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 399e772..ecd6398 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -909,20 +909,53 @@ fs_visitor::visit(ir_expression *ir)
   break;
 
case ir_unop_bitcast_i2f:
+  if (!op[0].negate) {
+ op[0].type = BRW_REGISTER_TYPE_F;
+ this-result = op[0];
+  } else {
+ this-result.type = BRW_REGISTER_TYPE_D;
+ emit(MOV(this-result, op[0]));
+ this-result.type = BRW_REGISTER_TYPE_F;
+  }
+  break;
case ir_unop_bitcast_u2f:
-  op[0].type = BRW_REGISTER_TYPE_F;
-  this-result = op[0];
+  if (!op[0].negate) {
+ op[0].type = BRW_REGISTER_TYPE_F;
+ this-result = op[0];
+  } else {
+ this-result.type = BRW_REGISTER_TYPE_UD;
+ emit(MOV(this-result, op[0]));
+ this-result.type = BRW_REGISTER_TYPE_F;
+  }
   break;
case ir_unop_i2u:
-   case ir_unop_bitcast_f2u:
   op[0].type = BRW_REGISTER_TYPE_UD;
   this-result = op[0];
   break;
+   case ir_unop_bitcast_f2u:
+  if (!op[0].negate) {
+ op[0].type = BRW_REGISTER_TYPE_UD;
+ this-result = op[0];
+  } else {
+ this-result.type = BRW_REGISTER_TYPE_F;
+ emit(MOV(this-result, op[0]));
+ this-result.type = BRW_REGISTER_TYPE_UD;
+  }
+  break;
case ir_unop_u2i:
-   case ir_unop_bitcast_f2i:
   op[0].type = BRW_REGISTER_TYPE_D;
   this-result = op[0];
   break;
+   case ir_unop_bitcast_f2i:
+  if (!op[0].negate) {
+ op[0].type = BRW_REGISTER_TYPE_D;
+ this-result = op[0];
+  } else {
+ this-result.type = BRW_REGISTER_TYPE_F;
+ emit(MOV(this-result, op[0]));
+ this-result.type = BRW_REGISTER_TYPE_D;
+  }
+  break;
case ir_unop_i2f:
case ir_unop_u2f:
case ir_unop_f2i:
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 7238788..a5e46a2 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1604,19 +1604,47 @@ vec4_visitor::visit(ir_expression *ir)
   break;
 
case ir_unop_bitcast_i2f:
+  if (!op[0].negate) {
+ this-result = op[0];
+ this-result.type = BRW_REGISTER_TYPE_F;
+  } else {
+ result_dst.type = BRW_REGISTER_TYPE_D;
+ emit(MOV(result_dst, op[0]));
+ result_dst.type = BRW_REGISTER_TYPE_F;
+  }
+  break;
+
case ir_unop_bitcast_u2f:
-  this-result = op[0];
-  this-result.type = BRW_REGISTER_TYPE_F;
+  if (!op[0].negate) {
+ this-result = op[0];
+ this-result.type = BRW_REGISTER_TYPE_F;
+  } else {
+ result_dst.type = BRW_REGISTER_TYPE_UD;
+ emit(MOV(result_dst, op[0]));
+ result_dst.type = BRW_REGISTER_TYPE_F;
+  }
   break;
 
case ir_unop_bitcast_f2i:
-  this-result = op[0];
-  this-result.type = BRW_REGISTER_TYPE_D;
+  if (!op[0].negate) {
+ this-result = op[0];
+ this-result.type = BRW_REGISTER_TYPE_D;
+  } else {
+ result_dst.type = BRW_REGISTER_TYPE_F;
+ emit(MOV(result_dst, op[0]));
+ result_dst.type = BRW_REGISTER_TYPE_D;
+  }
   break;
 
case ir_unop_bitcast_f2u:
-  this-result = op[0];
-  this-result.type = BRW_REGISTER_TYPE_UD;
+  if (!op[0].negate) {
+

[Mesa-dev] [PATCH 03/16] mesa: Clamps the stencil value masks to GLint when queried

Stencil value masks values (ctx-Stencil.ValueMask[]) stores GLuint values
which are initialized with max unsigned integer (~0u). When these values
are queried by glGet* (GL_STENCIL_VALUE_MASK or GL_STENCIL_BACK_VALUE_MASK),
they are converted to a signed integer. Currently, these values overflow
and return incorrect result (-1).

This patch clamps these values to max int (0x7FFF) before storing.

Fixes 6 dEQP failing tests:
* dEQP-GLES3.functional.state_query.integers.stencil_value_mask_getfloat
* dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_getfloat
* 
dEQP-GLES3.functional.state_query.integers.stencil_value_mask_separate_getfloat
* 
dEQP-GLES3.functional.state_query.integers.stencil_value_mask_separate_both_getfloat
* 
dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_separate_getfloat
* 
dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_separate_both_getfloat
---
 src/mesa/main/get.c  | 11 ++-
 src/mesa/main/get_hash_params.py |  2 +-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 6091efc..4578a36 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -726,7 +726,16 @@ find_custom_value(struct gl_context *ctx, const struct 
value_desc *d, union valu
   v-value_int = _mesa_get_stencil_ref(ctx, 1);
   break;
case GL_STENCIL_VALUE_MASK:
-  v-value_int = ctx-Stencil.ValueMask[ctx-Stencil.ActiveFace];
+  /* Since stencil value mask is a GLuint, it requires clamping
+   * before storing in a signed int to avoid overflow.
+   * Notice that Stencil.ValueMask values are initialized to ~0u,
+   * so without clamping it will return -1 when assigned to value_int.
+   */
+  v-value_int = ctx-Stencil.ValueMask[ctx-Stencil.ActiveFace]  
0x7FFF;
+  break;
+   case GL_STENCIL_BACK_VALUE_MASK:
+  /* Same as with GL_STENCIL_VALUE_MASK, value requires claming. */
+  v-value_int = ctx-Stencil.ValueMask[1]  0x7FFF;
   break;
case GL_STENCIL_WRITEMASK:
   v-value_int = ctx-Stencil.WriteMask[ctx-Stencil.ActiveFace];
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 09a61ac..a3bf1cb 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -283,7 +283,7 @@ descriptor=[
 
 # OpenGL 2.0
   [ STENCIL_BACK_FUNC, CONTEXT_ENUM(Stencil.Function[1]), NO_EXTRA ],
-  [ STENCIL_BACK_VALUE_MASK, CONTEXT_INT(Stencil.ValueMask[1]), NO_EXTRA ],
+  [ STENCIL_BACK_VALUE_MASK, LOC_CUSTOM, TYPE_INT, NO_OFFSET, NO_EXTRA],
   [ STENCIL_BACK_WRITEMASK, CONTEXT_INT(Stencil.WriteMask[1]), NO_EXTRA ],
   [ STENCIL_BACK_REF, LOC_CUSTOM, TYPE_INT, NO_OFFSET, NO_EXTRA ],
   [ STENCIL_BACK_FAIL, CONTEXT_ENUM(Stencil.FailFunc[1]), NO_EXTRA ],
-- 
2.1.3

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

[Mesa-dev] [PATCH 04/16] mesa: Depth ans stencil attachments must be the same in OpenGL ES3

From: Iago Toral Quiroga ito...@igalia.com

From the OpenGL ES3 spec:

9.4. FRAMEBUFFER COMPLETENESS
 ...
 Depth and stencil attachments, if present, are the same image.
 ...


Notice that this restriction is not included in the OpenGL ES2 spec.

Fixes 18 dEQP tests in:
dEQP-GLES3.functional.fbo.completeness.attachment_combinations.*
---
 src/mesa/main/fbobject.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 4c3c157..db2f43e 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -886,6 +886,8 @@ _mesa_test_framebuffer_completeness(struct gl_context *ctx,
GLuint max_layer_count = 0, att_layer_count;
bool is_layered = false;
GLenum layer_tex_target = 0;
+   bool has_depth_attachment = false;
+   bool has_stencil_attachment = false;
 
assert(_mesa_is_user_fbo(fb));
 
@@ -923,6 +925,8 @@ _mesa_test_framebuffer_completeness(struct gl_context *ctx,
 fb-_Status = GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT;
 fbo_incomplete(ctx, depth attachment incomplete, -1);
 return;
+ } else if (att-Type != GL_NONE) {
+has_depth_attachment = true;
  }
   }
   else if (i == -1) {
@@ -932,6 +936,8 @@ _mesa_test_framebuffer_completeness(struct gl_context *ctx,
 fb-_Status = GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT;
 fbo_incomplete(ctx, stencil attachment incomplete, -1);
 return;
+ } else if (att-Type != GL_NONE) {
+has_stencil_attachment = true;
  }
   }
   else {
@@ -1128,6 +1134,35 @@ _mesa_test_framebuffer_completeness(struct gl_context 
*ctx,
   }
}
 
+   /* The OpenGL ES3 spec, in chapter 9.4. FRAMEBUFFER COMPLETENESS, says:
+*
+*Depth and stencil attachments, if present, are the same image.
+*
+* This restriction is not present in the OpenGL ES2 spec.
+*/
+   if (_mesa_is_gles3(ctx) 
+   has_stencil_attachment  has_depth_attachment) {
+  struct gl_renderbuffer_attachment *att_depth, *att_stencil;
+  att_depth = fb-Attachment[BUFFER_DEPTH];
+  att_stencil = fb-Attachment[BUFFER_STENCIL];
+  if (att_depth-Type != att_stencil-Type) {
+ fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED;
+ fbo_incomplete(ctx, Depth and stencil attachments must be the same 
image, -1);
+ return;
+  }
+  if (att_depth-Type == GL_TEXTURE 
+  att_depth-Texture != att_stencil-Texture) {
+ fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED;
+ fbo_incomplete(ctx, Depth and stencil attachments must be the same 
image, -1);
+ return;
+  } else if (att_depth-Type == GL_RENDERBUFFER 
+ att_depth-Renderbuffer != att_stencil-Renderbuffer) {
+ fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED;
+ fbo_incomplete(ctx, Depth and stencil attachments must be the same 
image, -1);
+ return;
+  }
+   }
+
/* Provisionally set status = COMPLETE ... */
fb-_Status = GL_FRAMEBUFFER_COMPLETE_EXT;
 
-- 
2.1.3

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

[Mesa-dev] [PATCH 12/16] mesa: Returns a GL_INVALID_VALUE error if num of fbos in glDeleteRenderbuffers is negative

Per GLES3 manual for glDeleteRenderbuffers
https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteRenderbuffers.xhtml,
GL_INVALID_VALUE is generated if n is negative.

Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.buffer.delete_renderbuffers
---
 src/mesa/main/fbobject.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index df85b8c..7e1ff1b 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1326,6 +1326,11 @@ _mesa_DeleteRenderbuffers(GLsizei n, const GLuint 
*renderbuffers)
GLint i;
GET_CURRENT_CONTEXT(ctx);
 
+   if (n  0) {
+  _mesa_error(ctx, GL_INVALID_VALUE, glDeleteRenderbuffers(n));
+  return;
+   }
+
FLUSH_VERTICES(ctx, _NEW_BUFFERS);
 
for (i = 0; i  n; i++) {
-- 
2.1.3

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

[Mesa-dev] [PATCH 08/16] main: round floating-point value to nearest integer in glGetTexParameteriv()

From: Samuel Iglesias Gonsalvez sigles...@igalia.com

Previously, a cast was done to convert from float to int but there
were rounding errors.

The spec specificies in Data Conversion chapter that Floating-point values are
rounded to the nearest integer.

This patch fixes the following 8 dEQP tests:

dEQP-GLES3.functional.state_query.texture.texture_2d_texture_min_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_2d_texture_max_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_3d_texture_min_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_3d_texture_max_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_2d_array_texture_min_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_2d_array_texture_max_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_cube_map_texture_min_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_cube_map_texture_max_lod_gettexparameteri

Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
---
 src/mesa/main/texparam.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index e40fb24..2d5a9b7 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -1658,14 +1658,18 @@ _mesa_GetTexParameteriv( GLenum target, GLenum pname, 
GLint *params )
   case GL_TEXTURE_MIN_LOD:
  if (!_mesa_is_desktop_gl(ctx)  !_mesa_is_gles3(ctx))
 goto invalid_pname;
-
- *params = (GLint) obj-Sampler.MinLod;
+ /* GL spec 'Data Conversions' section specifies that floating-point
+  * value in integer Get function is rounded to nearest integer
+  */
+ *params = IROUND(obj-Sampler.MinLod);
  break;
   case GL_TEXTURE_MAX_LOD:
  if (!_mesa_is_desktop_gl(ctx)  !_mesa_is_gles3(ctx))
 goto invalid_pname;
-
- *params = (GLint) obj-Sampler.MaxLod;
+ /* GL spec 'Data Conversions' section specifies that floating-point
+  * value in integer Get function is rounded to nearest integer
+  */
+ *params = IROUND(obj-Sampler.MaxLod);
  break;
   case GL_TEXTURE_BASE_LEVEL:
  if (!_mesa_is_desktop_gl(ctx)  !_mesa_is_gles3(ctx))
@@ -1679,7 +1683,10 @@ _mesa_GetTexParameteriv( GLenum target, GLenum pname, 
GLint *params )
   case GL_TEXTURE_MAX_ANISOTROPY_EXT:
  if (!ctx-Extensions.EXT_texture_filter_anisotropic)
 goto invalid_pname;
- *params = (GLint) obj-Sampler.MaxAnisotropy;
+ /* GL spec 'Data Conversions' section specifies that floating-point
+  * value in integer Get function is rounded to nearest integer
+  */
+ *params = IROUND(obj-Sampler.MaxAnisotropy);
  break;
   case GL_GENERATE_MIPMAP_SGIS:
  if (ctx-API != API_OPENGL_COMPAT  ctx-API != API_OPENGLES)
-- 
2.1.3

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

[Mesa-dev] [PATCH 15/16] mesa: Fix error reporting for some cases of incomplete FBO attachments

From: Iago Toral Quiroga ito...@igalia.com

According to the OpenGL and OpenGL ES specs (sections
FRAMEBUFFER COMPLETENESS and Whole Framebuffer Completeness),
the image for color, depth or stencil attachments must be renderable,
otherwise the attachment is considered incomplete and we should report
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT. Currently, we detect this
situation properly but report a different error.

This fixes the following 3 piglit tests:
dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb_unsigned_int_2_10_10_10_rev
dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgba_unsigned_int_2_10_10_10_rev
dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb16f
---
 src/mesa/main/fbobject.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index a18f11c..28ba45f 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -966,7 +966,7 @@ _mesa_test_framebuffer_completeness(struct gl_context *ctx,
  if (!is_format_color_renderable(ctx, attFormat,
  texImg-InternalFormat) 
  !is_legal_depth_format(ctx, f)) {
-fb-_Status = GL_FRAMEBUFFER_INCOMPLETE_FORMATS_EXT;
+fb-_Status = GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT;
 fbo_incomplete(ctx, texture attachment incomplete, -1);
 return;
  }
-- 
2.1.3

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

[Mesa-dev] [PATCH 09/16] main: round floating-point value to nearest integer in glGetSamplerParameteriv()

From: Samuel Iglesias Gonsalvez sigles...@igalia.com

Previously, a cast was done to convert from float to int but there
were rounding errors.

The spec specificies in Data Conversion chapter that Floating-point values are
rounded to the nearest integer.

This patch fixes the following 2 dEQP tests:

dEQP-GLES3.functional.state_query.sampler.sampler_texture_min_lod_getsamplerparameteri
dEQP-GLES3.functional.state_query.sampler.sampler_texture_max_lod_getsamplerparameteri

Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
---
 src/mesa/main/samplerobj.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c
index 18a14d8..cadc9cc 100644
--- a/src/mesa/main/samplerobj.c
+++ b/src/mesa/main/samplerobj.c
@@ -1271,13 +1271,22 @@ _mesa_GetSamplerParameteriv(GLuint sampler, GLenum 
pname, GLint *params)
   *params = sampObj-MagFilter;
   break;
case GL_TEXTURE_MIN_LOD:
-  *params = (GLint) sampObj-MinLod;
+  /* GL spec 'Data Conversions' section specifies that floating-point
+   * value in integer Get function is rounded to nearest integer
+   */
+  *params = IROUND(sampObj-MinLod);
   break;
case GL_TEXTURE_MAX_LOD:
-  *params = (GLint) sampObj-MaxLod;
+  /* GL spec 'Data Conversions' section specifies that floating-point
+   * value in integer Get function is rounded to nearest integer
+   */
+  *params = IROUND(sampObj-MaxLod);
   break;
case GL_TEXTURE_LOD_BIAS:
-  *params = (GLint) sampObj-LodBias;
+  /* GL spec 'Data Conversions' section specifies that floating-point
+   * value in integer Get function is rounded to nearest integer
+   */
+  *params = IROUND(sampObj-LodBias);
   break;
case GL_TEXTURE_COMPARE_MODE:
   if (!ctx-Extensions.ARB_shadow)
@@ -1290,7 +1299,10 @@ _mesa_GetSamplerParameteriv(GLuint sampler, GLenum 
pname, GLint *params)
   *params = sampObj-CompareFunc;
   break;
case GL_TEXTURE_MAX_ANISOTROPY_EXT:
-  *params = (GLint) sampObj-MaxAnisotropy;
+  /* GL spec 'Data Conversions' section specifies that floating-point
+   * value in integer Get function is rounded to nearest integer
+   */
+  *params = IROUND(sampObj-MaxAnisotropy);
   break;
case GL_TEXTURE_BORDER_COLOR:
   params[0] = FLOAT_TO_INT(sampObj-BorderColor.f[0]);
-- 
2.1.3

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

[Mesa-dev] [PATCH 07/16] main: fix return GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL value

From: Samuel Iglesias Gonsalvez sigles...@igalia.com

Return the proper value for two-dimensional array texture and three-dimensional
textures.

From OpenGL ES 3.0 spec, chapter 6.1.13 Framebuffer Object Queries,
page 234:

If pname is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER and the texture
object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is a layer of a
three-dimensional texture or a two-dimensional array texture, then params
will contain the number of the texture layer which contains the attached im-
age. Otherwise params will contain the value zero.

Furthermore, FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is an alias of
FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT.

This patch fixes dEQP test:

dEQP-GLES3.functional.state_query.fbo.framebuffer_attachment_texture_layer

Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
---
 src/mesa/main/fbobject.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index db2f43e..c3f01c9 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2904,7 +2904,10 @@ _mesa_GetFramebufferAttachmentParameteriv(GLenum target, 
GLenum attachment,
  _mesa_error(ctx, err,
  glGetFramebufferAttachmentParameteriv(pname));
   } else if (att-Type == GL_TEXTURE) {
- if (att-Texture  att-Texture-Target == GL_TEXTURE_3D) {
+ if (att-Texture  (att-Texture-Target == GL_TEXTURE_3D ||
+ att-Texture-Target == GL_TEXTURE_3D_EXT ||
+ att-Texture-Target == GL_TEXTURE_2D_ARRAY ||
+ att-Texture-Target == GL_TEXTURE_2D_ARRAY_EXT)) {
 *params = att-Zoffset;
  }
  else {
-- 
2.1.3

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

[Mesa-dev] [PATCH 13/16] mesa: Adds check for integer internal formal and num samples in glRenderbufferStorageMultisample

Per GLES3 specification, section 4.4 Framebuffer objects page 198, If
internalformat is a signed or unsigned integer format and samples is greater
than zero, then the error INVALID_OPERATION is generated..

Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.buffer.renderbuffer_storage_multisample
---
 src/mesa/main/fbobject.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 7e1ff1b..a18f11c 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1814,6 +1814,15 @@ renderbuffer_storage(GLenum target, GLenum 
internalFormat,
   samples = 0;
}
else {
+  if (_mesa_is_gles3(ctx)  _mesa_is_enum_format_integer(internalFormat)) 
{
+ /* Per GLES3 specification, section 4.4 Framebuffer objects page 198, 
If
+  * internalformat is a signed or unsigned integer format and samples 
is greater
+  * than zero, then the error INVALID_OPERATION is generated..
+  */
+ _mesa_error(ctx, GL_INVALID_OPERATION, %s(samples), func);
+ return;
+  }
+
   /* check the sample count;
* note: driver may choose to use more samples than what's requested
*/
-- 
2.1.3

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

[Mesa-dev] [PATCH 02/16] mesa: Check first that draw buffers are valid for glDrawBuffers on GLES3

Fixes 1 dEQP test: dEQP-GLES3.functional.negative_api.buffer.draw_buffers
---
 src/mesa/main/buffers.c | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 1ee2009..0f40739 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -323,14 +323,29 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
supportedMask = supported_buffer_bitmask(ctx, ctx-DrawBuffer);
usedBufferMask = 0x0;
 
-   /* From the ES 3.0 specification, page 180:
-* If the GL is bound to the default framebuffer, then n must be 1
-*  and the constant must be BACK or NONE.
-*/
-   if (_mesa_is_gles3(ctx)  _mesa_is_winsys_fbo(ctx-DrawBuffer) 
-   (n != 1 || (buffers[0] != GL_NONE  buffers[0] != GL_BACK))) {
-  _mesa_error(ctx, GL_INVALID_OPERATION, glDrawBuffers(buffer));
-  return;
+   if (_mesa_is_gles3(ctx)) {
+  /* From the ES 3.0 specification, page 179:
+   * Each buffer listed in bufs must be BACK, NONE, or one of the values
+   * from table 4.3 (NONE, COLOR_ATTACHMENTi)
+   */
+  for (output = 0; output  n; output++) {
+ if (buffers[output] != GL_NONE  buffers[output] != GL_BACK 
+ (buffers[output]  GL_COLOR_ATTACHMENT0 ||
+  buffers[output] = GL_COLOR_ATTACHMENT0 + 
ctx-Const.MaxColorAttachments)) {
+_mesa_error(ctx, GL_INVALID_ENUM, glDrawBuffers(buffer));
+return;
+ }
+  }
+
+  /* From the ES 3.0 specification, page 180:
+   * If the GL is bound to the default framebuffer, then n must be 1
+   *  and the constant must be BACK or NONE.
+   */
+  if (_mesa_is_winsys_fbo(ctx-DrawBuffer) 
+  (n != 1 || (buffers[0] != GL_NONE  buffers[0] != GL_BACK))) {
+ _mesa_error(ctx, GL_INVALID_OPERATION, glDrawBuffers(buffer));
+ return;
+  }
}
 
/* complicated error checking... */
-- 
2.1.3

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

[Mesa-dev] [PATCH 10/16] mesa: Allows querying GL_SAMPLER_BINDING on GLES3 profile

From GLES3 specification (page 123), The currently bound sampler may be
queried by calling GetIntegerv with pname set to
SAMPLER_BINDINGGL_SAMPLER_BINDING.

Fixes 4 dEQP tests:
* dEQP-GLES3.functional.state_query.integers.sampler_binding_getboolean
* dEQP-GLES3.functional.state_query.integers.sampler_binding_getinteger
* dEQP-GLES3.functional.state_query.integers.sampler_binding_getinteger64
* dEQP-GLES3.functional.state_query.integers.sampler_binding_getfloat
---
 src/mesa/main/get_hash_params.py | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index a3bf1cb..c70ed04 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -403,6 +403,11 @@ descriptor=[
   [ TEXTURE_EXTERNAL_OES, LOC_CUSTOM, TYPE_BOOLEAN, 0, 
extra_OES_EGL_image_external ],
 ]},
 
+{ apis: [GL, GL_CORE, GLES3], params: [
+# GL_ARB_sampler_objects / GL 3.3 / GLES 3.0
+  [ SAMPLER_BINDING, LOC_CUSTOM, TYPE_INT, GL_SAMPLER_BINDING, NO_EXTRA ],
+]},
+
 # Remaining enums are only in OpenGL
 { apis: [GL, GL_CORE], params: [
   [ ACCUM_RED_BITS, BUFFER_INT(Visual.accumRedBits), NO_EXTRA ],
@@ -695,10 +700,6 @@ descriptor=[
   [ SAMPLE_MASK, CONTEXT_BOOL(Multisample.SampleMask), 
extra_ARB_texture_multisample ],
   [ MAX_SAMPLE_MASK_WORDS, CONST(1), extra_ARB_texture_multisample ],
 
-
-# GL_ARB_sampler_objects / GL 3.3
-  [ SAMPLER_BINDING, LOC_CUSTOM, TYPE_INT, GL_SAMPLER_BINDING, NO_EXTRA ],
-
 # GL 3.0
   [ CONTEXT_FLAGS, CONTEXT_INT(Const.ContextFlags), extra_version_30 ],
 
-- 
2.1.3

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

[Mesa-dev] [PATCH 11/16] mesa: Returns a GL_INVALID_VALUE error if num of fbos in glDeleteFramebuffers is negative

Per GLES3 manual for glDeleteFramebuffers
https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteFramebuffers.xhtml,
GL_INVALID_VALUE is generated if n is negative.

Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.buffer.delete_framebuffers
---
 src/mesa/main/fbobject.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index c3f01c9..df85b8c 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2218,6 +2218,11 @@ _mesa_DeleteFramebuffers(GLsizei n, const GLuint 
*framebuffers)
GLint i;
GET_CURRENT_CONTEXT(ctx);
 
+   if (n  0) {
+  _mesa_error(ctx, GL_INVALID_VALUE, glDeleteFramebuffers(n));
+  return;
+   }
+
FLUSH_VERTICES(ctx, _NEW_BUFFERS);
 
for (i = 0; i  n; i++) {
-- 
2.1.3

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

[Mesa-dev] [PATCH 14/16] mesa: Returns a GL_INVALID_VALUE error if num of texs in glDeleteTextures is negative

Per GLES3 manual for glDeleteTextures
https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteTextures.xhtml,
GL_INVALID_VALUE is generated if n is negative.

Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.texture.deletetextures
---
 src/mesa/main/texobj.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index 923cf60..f24bccb 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -1201,6 +1201,11 @@ _mesa_DeleteTextures( GLsizei n, const GLuint *textures)
if (MESA_VERBOSE  (VERBOSE_API|VERBOSE_TEXTURE))
   _mesa_debug(ctx, glDeleteTextures %d\n, n);
 
+   if (n  0) {
+  _mesa_error(ctx, GL_INVALID_VALUE, glDeleteTextures(n));
+  return;
+   }
+
FLUSH_VERTICES(ctx, 0); /* too complex */
 
if (!textures)
-- 
2.1.3

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

[Mesa-dev] [PATCH 16/16] mesa: Returns correct error values from gl(Get)SamplerParameter*() in GLES3

Per GLES specification, the family of functions glGetSamplerParameter(iv/fv)
and glSamplerParameter(i/f/iv/fv) return an INVALID_OPERATION error if
sampler is not the name of a sampler object previously returned from a call
to GenSamplers.
In desktop GL, an GL_INVALID_VALUE is returned instead.

Fixes 6 dEQP failing tests:
* dEQP-GLES3.functional.negative_api.shader.get_sampler_parameteriv
* dEQP-GLES3.functional.negative_api.shader.get_sampler_parameterfv
* dEQP-GLES3.functional.negative_api.shader.sampler_parameteri
* dEQP-GLES3.functional.negative_api.shader.sampler_parameteriv
* dEQP-GLES3.functional.negative_api.shader.sampler_parameterf
* dEQP-GLES3.functional.negative_api.shader.sampler_parameterfv
---
 src/mesa/main/samplerobj.c | 60 --
 1 file changed, 48 insertions(+), 12 deletions(-)

diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c
index cadc9cc..c4e9bdc 100644
--- a/src/mesa/main/samplerobj.c
+++ b/src/mesa/main/samplerobj.c
@@ -732,8 +732,14 @@ _mesa_SamplerParameteri(GLuint sampler, GLenum pname, 
GLint param)
 
sampObj = _mesa_lookup_samplerobj(ctx, sampler);
if (!sampObj) {
-  _mesa_error(ctx, GL_INVALID_VALUE, glSamplerParameteri(sampler %u),
-  sampler);
+  /* Per GLES specification, An INVALID_OPERATION error is generated if
+   * sampler is not the name of a sampler object previously returned from 
a call
+   * to GenSamplers.
+   * In desktop GL, an GL_INVALID_VALUE is returned instead.
+   */
+  _mesa_error(ctx, (_mesa_is_gles(ctx) ?
+GL_INVALID_OPERATION : GL_INVALID_VALUE),
+  glSamplerParameteri(sampler %u), sampler);
   return;
}
 
@@ -817,8 +823,14 @@ _mesa_SamplerParameterf(GLuint sampler, GLenum pname, 
GLfloat param)
 
sampObj = _mesa_lookup_samplerobj(ctx, sampler);
if (!sampObj) {
-  _mesa_error(ctx, GL_INVALID_VALUE, glSamplerParameterf(sampler %u),
-  sampler);
+  /* Per GLES specification, An INVALID_OPERATION error is generated if
+   * sampler is not the name of a sampler object previously returned from 
a call
+   * to GenSamplers.
+   * In desktop GL, an GL_INVALID_VALUE is returned instead.
+   */
+  _mesa_error(ctx, (_mesa_is_gles(ctx) ?
+GL_INVALID_OPERATION : GL_INVALID_VALUE),
+  glSamplerParameterf(sampler %u), sampler);
   return;
}
 
@@ -901,8 +913,14 @@ _mesa_SamplerParameteriv(GLuint sampler, GLenum pname, 
const GLint *params)
 
sampObj = _mesa_lookup_samplerobj(ctx, sampler);
if (!sampObj) {
-  _mesa_error(ctx, GL_INVALID_VALUE, glSamplerParameteriv(sampler %u),
-  sampler);
+  /* Per GLES specification, An INVALID_OPERATION error is generated if
+   * sampler is not the name of a sampler object previously returned from 
a call
+   * to GenSamplers.
+   * In desktop GL, an GL_INVALID_VALUE is returned instead.
+   */
+  _mesa_error(ctx, (_mesa_is_gles(ctx) ?
+GL_INVALID_OPERATION : GL_INVALID_VALUE),
+  glSamplerParameteriv(sampler %u), sampler);
   return;
}
 
@@ -993,8 +1011,14 @@ _mesa_SamplerParameterfv(GLuint sampler, GLenum pname, 
const GLfloat *params)
 
sampObj = _mesa_lookup_samplerobj(ctx, sampler);
if (!sampObj) {
-  _mesa_error(ctx, GL_INVALID_VALUE, glSamplerParameterfv(sampler %u),
-  sampler);
+  /* Per GLES specification, An INVALID_OPERATION error is generated if
+   * sampler is not the name of a sampler object previously returned from 
a call
+   * to GenSamplers.
+   * In desktop GL, an GL_INVALID_VALUE is returned instead.
+   */
+  _mesa_error(ctx, (_mesa_is_gles(ctx) ?
+GL_INVALID_OPERATION : GL_INVALID_VALUE),
+  glSamplerParameterfv(sampler %u), sampler);
   return;
}
 
@@ -1249,8 +1273,14 @@ _mesa_GetSamplerParameteriv(GLuint sampler, GLenum 
pname, GLint *params)
 
sampObj = _mesa_lookup_samplerobj(ctx, sampler);
if (!sampObj) {
-  _mesa_error(ctx, GL_INVALID_VALUE, glGetSamplerParameteriv(sampler %u),
-  sampler);
+  /* Per GLES specification, An INVALID_OPERATION error is generated if
+   * sampler is not the name of a sampler object previously returned from 
a call
+   * to GenSamplers.
+   * In desktop GL, an GL_INVALID_VALUE is returned instead.
+   */
+  _mesa_error(ctx, (_mesa_is_gles(ctx) ?
+GL_INVALID_OPERATION : GL_INVALID_VALUE),
+  glGetSamplerParameteriv(sampler %u), sampler);
   return;
}
 
@@ -1339,8 +1369,14 @@ _mesa_GetSamplerParameterfv(GLuint sampler, GLenum 
pname, GLfloat *params)
 
sampObj = _mesa_lookup_samplerobj(ctx, sampler);
if (!sampObj) {
-  _mesa_error(ctx, GL_INVALID_VALUE, glGetSamplerParameterfv(sampler %u),
-

Re: [Mesa-dev] [PATCH] mesa: Add mesa SHA-1 functions

On Thu, Dec 11 2014, Brian Paul wrote:
 We'll need a solution for Windows too.  I don't have time right now to 
 do any research into that.

The code from xserver seems to cover that. I'll follow up with a
(largely untested) patch that I ported over from xserver.

If people can give some high-level feedback on that, that will be
great. I'll then actually test all the parts I can on my Linux box, (but
won't be able to test the Windows pieces directly).

-Carl


pgpQ4HeTmTYWy.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] mesa: Add mesa SHA-1 functions

From: Kristian Høgsberg k...@bitplanet.net

The upcoming shader cache uses the SHA-1 algorithm for cryptographic
naming. These new mesa_sha1 functions are implemented with the nettle
library.
---
 configure.ac  | 119 +++
 src/util/Makefile.am  |   3 +
 src/util/Makefile.sources |   2 +
 src/util/sha1.c   | 291 ++
 src/util/sha1.h   |  53 +
 5 files changed, 468 insertions(+)
 create mode 100644 src/util/sha1.c
 create mode 100644 src/util/sha1.h

diff --git a/configure.ac b/configure.ac
index a11190c..3932efd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -9,6 +9,7 @@ dnl Copyright © 2009-2014 Jon TURNEY
 dnl Copyright © 2011-2012 Benjamin Franzke
 dnl Copyright © 2008-2014 David Airlie
 dnl Copyright © 2009-2013 Brian Paul
+dnl Copyright © 2003-2007 Keith Packard, Daniel Stone
 dnl
 dnl Permission is hereby granted, free of charge, to any person obtaining a
 dnl copy of this software and associated documentation files (the Software),
@@ -907,6 +908,124 @@ fi
 
 AC_SUBST([MESA_LLVM])
 
+# SHA1 hashing
+AC_ARG_WITH([sha1],
+
[AS_HELP_STRING([--with-sha1=libc|libmd|libnettle|libgcrypt|libcrypto|libsha1|CommonCrypto|CryptoAPI],
+[choose SHA1 implementation])])
+AC_CHECK_FUNC([SHA1Init], [HAVE_SHA1_IN_LIBC=yes])
+if test x$with_sha1 = x  test x$HAVE_SHA1_IN_LIBC = xyes; then
+   with_sha1=libc
+fi
+if test x$with_sha1 = xlibc  test x$HAVE_SHA1_IN_LIBC != xyes; then
+   AC_MSG_ERROR([libc requested but not found])
+fi
+if test x$with_sha1 = xlibc; then
+   AC_DEFINE([HAVE_SHA1_IN_LIBC], [1],
+   [Use libc SHA1 functions])
+   SHA1_LIBS=
+fi
+AC_CHECK_FUNC([CC_SHA1_Init], [HAVE_SHA1_IN_COMMONCRYPTO=yes])
+if test x$with_sha1 = x  test x$HAVE_SHA1_IN_COMMONCRYPTO = xyes; then
+   with_sha1=CommonCrypto
+fi
+if test x$with_sha1 = xCommonCrypto  test x$HAVE_SHA1_IN_COMMONCRYPTO != 
xyes; then
+   AC_MSG_ERROR([CommonCrypto requested but not found])
+fi
+if test x$with_sha1 = xCommonCrypto; then
+   AC_DEFINE([HAVE_SHA1_IN_COMMONCRYPTO], [1],
+   [Use CommonCrypto SHA1 functions])
+   SHA1_LIBS=
+fi
+dnl stdcall functions cannot be tested with AC_CHECK_LIB
+AC_CHECK_HEADER([wincrypt.h], [HAVE_SHA1_IN_CRYPTOAPI=yes], [], [#include 
windows.h])
+if test x$with_sha1 = x  test x$HAVE_SHA1_IN_CRYPTOAPI = xyes; then
+   with_sha1=CryptoAPI
+fi
+if test x$with_sha1 = xCryptoAPI  test x$HAVE_SHA1_IN_CRYPTOAPI != xyes; 
then
+   AC_MSG_ERROR([CryptoAPI requested but not found])
+fi
+if test x$with_sha1 = xCryptoAPI; then
+   AC_DEFINE([HAVE_SHA1_IN_CRYPTOAPI], [1],
+   [Use CryptoAPI SHA1 functions])
+   SHA1_LIBS=
+fi
+AC_CHECK_LIB([md], [SHA1Init], [HAVE_LIBMD=yes])
+if test x$with_sha1 = x  test x$HAVE_LIBMD = xyes; then
+   with_sha1=libmd
+fi
+if test x$with_sha1 = xlibmd  test x$HAVE_LIBMD != xyes; then
+   AC_MSG_ERROR([libmd requested but not found])
+fi
+if test x$with_sha1 = xlibmd; then
+   AC_DEFINE([HAVE_SHA1_IN_LIBMD], [1],
+ [Use libmd SHA1 functions])
+   SHA1_LIBS=-lmd
+fi
+PKG_CHECK_MODULES([LIBSHA1], [libsha1], [HAVE_LIBSHA1=yes], [HAVE_LIBSHA1=no])
+if test x$with_sha1 = x  test x$HAVE_LIBSHA1 = xyes; then
+   with_sha1=libsha1
+fi
+if test x$with_sha1 = xlibsha1  test x$HAVE_LIBSHA1 != xyes; then
+   AC_MSG_ERROR([libsha1 requested but not found])
+fi
+if test x$with_sha1 = xlibsha1; then
+   AC_DEFINE([HAVE_SHA1_IN_LIBSHA1], [1],
+ [Use libsha1 for SHA1])
+   SHA1_LIBS=-lsha1
+fi
+AC_CHECK_LIB([nettle], [nettle_sha1_init], [HAVE_LIBNETTLE=yes])
+if test x$with_sha1 = x  test x$HAVE_LIBNETTLE = xyes; then
+   with_sha1=libnettle
+fi
+if test x$with_sha1 = xlibnettle  test x$HAVE_LIBNETTLE != xyes; then
+   AC_MSG_ERROR([libnettle requested but not found])
+fi
+if test x$with_sha1 = xlibnettle; then
+   AC_DEFINE([HAVE_SHA1_IN_LIBNETTLE], [1],
+ [Use libnettle SHA1 functions])
+   SHA1_LIBS=-lnettle
+fi
+AC_CHECK_LIB([gcrypt], [gcry_md_open], [HAVE_LIBGCRYPT=yes])
+if test x$with_sha1 = x  test x$HAVE_LIBGCRYPT = xyes; then
+   with_sha1=libgcrypt
+fi
+if test x$with_sha1 = xlibgcrypt  test x$HAVE_LIBGCRYPT != xyes; then
+   AC_MSG_ERROR([libgcrypt requested but not found])
+fi
+if test x$with_sha1 = xlibgcrypt; then
+   AC_DEFINE([HAVE_SHA1_IN_LIBGCRYPT], [1],
+ [Use libgcrypt SHA1 functions])
+   SHA1_LIBS=-lgcrypt
+fi
+# We don't need all of the OpenSSL libraries, just libcrypto
+AC_CHECK_LIB([crypto], [SHA1_Init], [HAVE_LIBCRYPTO=yes])
+PKG_CHECK_MODULES([OPENSSL], [openssl], [HAVE_OPENSSL_PKC=yes],
+  [HAVE_OPENSSL_PKC=no])
+if test x$HAVE_LIBCRYPTO = xyes || test x$HAVE_OPENSSL_PKC = xyes; then
+   if test x$with_sha1 = x; then
+   with_sha1=libcrypto
+   fi
+else
+   if test x$with_sha1 = xlibcrypto; then
+

[Mesa-dev] [PATCH 1/2] configure: Add copyright and license block to configure.ac

Prior to copying in code from the xserver configure.ac file, it makes
sense to have the license of this file clearly marked, (to show that
it's licensed identically to the configure.ac file from the xserver
repository).

And since the text of the license refers to the above copyright
notice it also makes sense to have an actual copyright attribution in
place.

I generated this list of names by looking at the output of:

git shortlog -n --format=%aD -- configure.ac

(and arbitrarily stopping for contributors with fewer than 15
commits). Then for each name, I looked for existing Copyright
attributions in the mesa source tree with the same name, (and using
Intel Corporation as the copyright holder where I knew that was
appropriate).
---
 configure.ac | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/configure.ac b/configure.ac
index 1d9d015..a11190c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,3 +1,34 @@
+dnl Copyright © 2011-2014 Intel Corporation
+dnl Copyright © 2011-2014 Emil Velikov emil.l.veli...@gmail.com
+dnl Copyright © 2007-2010 Dan Nicholson
+dnl Copyright © 2010-2014 Marek Olšák mar...@gmail.com
+dnl Copyright © 2010-2014 Christian König
+dnl Copyright © 2012-2014 Tom Stellard tstel...@gmail.com
+dnl Copyright © 2009-2012 Jakob Bornecrantz
+dnl Copyright © 2009-2014 Jon TURNEY
+dnl Copyright © 2011-2012 Benjamin Franzke
+dnl Copyright © 2008-2014 David Airlie
+dnl Copyright © 2009-2013 Brian Paul
+dnl
+dnl Permission is hereby granted, free of charge, to any person obtaining a
+dnl copy of this software and associated documentation files (the Software),
+dnl to deal in the Software without restriction, including without limitation
+dnl the rights to use, copy, modify, merge, publish, distribute, sublicense,
+dnl and/or sell copies of the Software, and to permit persons to whom the
+dnl Software is furnished to do so, subject to the following conditions:
+dnl
+dnl The above copyright notice and this permission notice (including the next
+dnl paragraph) shall be included in all copies or substantial portions of the
+dnl Software.
+dnl
+dnl THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+dnl IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+dnl FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+dnl THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+dnl LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+dnl FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+dnl DEALINGS IN THE SOFTWARE.
+dnl
 dnl Process this file with autoconf to create configure.
 
 AC_PREREQ([2.60])
-- 
2.1.1

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

Re: [Mesa-dev] [PATCH] i965/gen8+: Remove false perf debug message about MOCS

2014-12-11 Thread Kenneth Graunke

On Thursday, December 11, 2014 12:42:08 PM Ben Widawsky wrote:
 We support MOCS on both gen8 and gen9, so the message seems meaningless. 
 Remove
 it to avoid confusion.
 
 Trivial.
 
 Cc: Kristian Høgsberg k...@bitplanet.net
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  src/mesa/drivers/dri/i965/gen8_misc_state.c | 3 ---
  1 file changed, 3 deletions(-)
 
 diff --git a/src/mesa/drivers/dri/i965/gen8_misc_state.c 
 b/src/mesa/drivers/dri/i965/gen8_misc_state.c
 index f993650..bd1d5cc 100644
 --- a/src/mesa/drivers/dri/i965/gen8_misc_state.c
 +++ b/src/mesa/drivers/dri/i965/gen8_misc_state.c
 @@ -32,9 +32,6 @@
  static void upload_state_base_address(struct brw_context *brw)
  {
 uint32_t mocs_wb = brw-gen = 9 ? SKL_MOCS_WB : BDW_MOCS_WB;
 -
 -   perf_debug(Missing MOCS setup for STATE_BASE_ADDRESS.);
 -
 int pkt_len = brw-gen = 9 ? 19 : 16;
  
 BEGIN_BATCH(pkt_len);
 

Heh, I thought I killed this a while ago.  Must've forgotten to send it out or 
push it.

Thanks :)

Reviewed-by: Kenneth Graunke kenn...@whitecape.org

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 01/16] i965: Sets missing vertex shader constant values for HighInt format

2014-12-11 Thread Kenneth Graunke

On Thursday, December 11, 2014 11:33:52 PM Eduardo Lima Mitev wrote:
 The range's min and max, and the precision value are not set correctly for the
 vertex shader constants.
 
 Fixes 1 dEQP test: 
 dEQP-GLES3.functional.state_query.shader.precision_vertex_highp_int
 ---
  src/mesa/drivers/dri/i965/brw_context.c | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
 b/src/mesa/drivers/dri/i965/brw_context.c
 index 860ee22d..03b4ee3 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.c
 +++ b/src/mesa/drivers/dri/i965/brw_context.c
 @@ -480,6 +480,12 @@ brw_initialize_context_constants(struct brw_context *brw)
 ctx-Const.Program[MESA_SHADER_FRAGMENT].HighInt = 
 ctx-Const.Program[MESA_SHADER_FRAGMENT].LowInt;
 ctx-Const.Program[MESA_SHADER_FRAGMENT].MediumInt = 
 ctx-Const.Program[MESA_SHADER_FRAGMENT].LowInt;
  
 +   ctx-Const.Program[MESA_SHADER_VERTEX].LowInt.RangeMin = 31;
 +   ctx-Const.Program[MESA_SHADER_VERTEX].LowInt.RangeMax = 30;
 +   ctx-Const.Program[MESA_SHADER_VERTEX].LowInt.Precision = 0;
 +   ctx-Const.Program[MESA_SHADER_VERTEX].HighInt = 
 ctx-Const.Program[MESA_SHADER_VERTEX].LowInt;
 +   ctx-Const.Program[MESA_SHADER_VERTEX].MediumInt = 
 ctx-Const.Program[MESA_SHADER_VERTEX].LowInt;
 +
 if (brw-gen = 7) {
ctx-Const.Program[MESA_SHADER_FRAGMENT].MaxAtomicCounters = 
 MAX_ATOMIC_COUNTERS;
ctx-Const.Program[MESA_SHADER_VERTEX].MaxAtomicCounters = 
 MAX_ATOMIC_COUNTERS;
 

We should set these as default values in src/mesa/main somewhere - that way,
all drivers advertise 32-bit integer support by default.  Currently, it looks
like basically all drivers forget to do this.

The few (if any?) drivers that want something else can set their own values.

--Ken

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 05/16] i965: Fix bitcast operations with negate

2014-12-11 Thread Kenneth Graunke

On Thursday, December 11, 2014 11:34:11 PM Eduardo Lima Mitev wrote:
 From: Iago Toral Quiroga ito...@igalia.com
 
 For code such as this in a vertex or fragment shader:
 
 uniform float in0;
 flat out float out0;
 ...
 out0 = ceil(in0)
 
 We generate this IR:
 
 (assign  (x) (var_ref packed:out0)
(expression int bitcast_f2i
(expression float ceil (var_ref in0) ) ) )
 
 In i965, this would eventually become:
 
 rndd(8) g141.xF   -g30,4,1.xF
 mov(8)  g61.xD-g144,4,1.xD
 mov(8)  g1161Dg64,4,1D

Weird...it does indeed use RNDD.  Shouldn't it use RNDU instead?

--Ken

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] FOSDEM15: Graphics DevRoom: call for speakers.

2014-12-11 Thread Jesse Barnes

On Tue, 9 Dec 2014 15:39:26 +0100
Luc Verhaegen l...@skynet.be wrote:

 On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote:
  Hi,
  
  At FOSDEM on the 31st of january and the 1st of February 2015, there 
  will be another graphics DevRoom. URL: https://fosdem.org/2015/
 
  Slots will be handed out on a first come, first serve basis. The best 
  slots will go to those who apply the earliest. The amount of slots is 
  currently not known yet, but i expect there to be around 16 available (8 
  on each day), so act quickly.
 
  As for deadlines, i hope to have a pretty much complete schedule between 
  christmas and the new year. The rockhard printed schedule deadline is 
  probably January 9th, after that you will not be featured in the booklet 
  and you will have a lot less visitors. I will hopefully be able to lock 
  down entries and descriptions after that date.
 
 It's been more than 2 months since the original email, it's less than 
 two months away from the event, and one month away from what usually is 
 the deadline for the booklet. File your talk now, while there are still 
 some useful slots available.
 
 Also, for those who have filed already but who have left their abstracts 
 open, please get those filed in ASAP. Your talk will be only be ordered 
 in when at least the basics are provided.

Hey Luc, thanks for the reminder.  I just submitted a talk myself;
hopefully there's still room on the schedule! :)

-- 
Jesse Barnes, 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 04/16] mesa: Depth ans stencil attachments must be the same in OpenGL ES3

On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 From: Iago Toral Quiroga ito...@igalia.com
 
 From the OpenGL ES3 spec:
 
 9.4. FRAMEBUFFER COMPLETENESS
  ...
  Depth and stencil attachments, if present, are the same image.
  ...
 
 
 Notice that this restriction is not included in the OpenGL ES2 spec.
 
 Fixes 18 dEQP tests in:
 dEQP-GLES3.functional.fbo.completeness.attachment_combinations.*
 ---
  src/mesa/main/fbobject.c | 35 +++
  1 file changed, 35 insertions(+)
 
 diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
 index 4c3c157..db2f43e 100644
 --- a/src/mesa/main/fbobject.c
 +++ b/src/mesa/main/fbobject.c
 @@ -886,6 +886,8 @@ _mesa_test_framebuffer_completeness(struct gl_context 
 *ctx,
 GLuint max_layer_count = 0, att_layer_count;
 bool is_layered = false;
 GLenum layer_tex_target = 0;
 +   bool has_depth_attachment = false;
 +   bool has_stencil_attachment = false;
  
 assert(_mesa_is_user_fbo(fb));
  
 @@ -923,6 +925,8 @@ _mesa_test_framebuffer_completeness(struct gl_context 
 *ctx,
  fb-_Status = GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT;
  fbo_incomplete(ctx, depth attachment incomplete, -1);
  return;
 + } else if (att-Type != GL_NONE) {
 +has_depth_attachment = true;
   }
}
else if (i == -1) {
 @@ -932,6 +936,8 @@ _mesa_test_framebuffer_completeness(struct gl_context 
 *ctx,
  fb-_Status = GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT;
  fbo_incomplete(ctx, stencil attachment incomplete, -1);
  return;
 + } else if (att-Type != GL_NONE) {
 +has_stencil_attachment = true;
   }
}
else {
 @@ -1128,6 +1134,35 @@ _mesa_test_framebuffer_completeness(struct gl_context 
 *ctx,
}
 }
  
 +   /* The OpenGL ES3 spec, in chapter 9.4. FRAMEBUFFER COMPLETENESS, says:
 +*
 +*Depth and stencil attachments, if present, are the same image.
 +*
 +* This restriction is not present in the OpenGL ES2 spec.
 +*/
 +   if (_mesa_is_gles3(ctx) 
 +   has_stencil_attachment  has_depth_attachment) {
 +  struct gl_renderbuffer_attachment *att_depth, *att_stencil;
 +  att_depth = fb-Attachment[BUFFER_DEPTH];
 +  att_stencil = fb-Attachment[BUFFER_STENCIL];
 +  if (att_depth-Type != att_stencil-Type) {
 + fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED;
 + fbo_incomplete(ctx, Depth and stencil attachments must be the same 
 image, -1);
 + return;
 +  }
 +  if (att_depth-Type == GL_TEXTURE 
 +  att_depth-Texture != att_stencil-Texture) {
 + fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED;
 + fbo_incomplete(ctx, Depth and stencil attachments must be the same 
 image, -1);
 + return;
 +  } else if (att_depth-Type == GL_RENDERBUFFER 
 + att_depth-Renderbuffer != att_stencil-Renderbuffer) {
 + fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED;
 + fbo_incomplete(ctx, Depth and stencil attachments must be the same 
 image, -1);
 + return;
 +  }

I think this would be better as a single if-statement, and you can use
_mesa_has_depthstencil_combined.

 +   }
 +
 /* Provisionally set status = COMPLETE ... */
 fb-_Status = GL_FRAMEBUFFER_COMPLETE_EXT;
  
 

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

Re: [Mesa-dev] [PATCH 07/16] main: fix return GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL value

On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 From: Samuel Iglesias Gonsalvez sigles...@igalia.com
 
 Return the proper value for two-dimensional array texture and 
 three-dimensional
 textures.
 
 From OpenGL ES 3.0 spec, chapter 6.1.13 Framebuffer Object Queries,
 page 234:
 
 If pname is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER and the texture
 object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is a layer of a
 three-dimensional texture or a two-dimensional array texture, then params
 will contain the number of the texture layer which contains the attached im-
 age. Otherwise params will contain the value zero.
 
 Furthermore, FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is an alias of
 FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT.
 
 This patch fixes dEQP test:
 
 dEQP-GLES3.functional.state_query.fbo.framebuffer_attachment_texture_layer
 
 Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
 ---
  src/mesa/main/fbobject.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
 index db2f43e..c3f01c9 100644
 --- a/src/mesa/main/fbobject.c
 +++ b/src/mesa/main/fbobject.c
 @@ -2904,7 +2904,10 @@ _mesa_GetFramebufferAttachmentParameteriv(GLenum 
 target, GLenum attachment,
   _mesa_error(ctx, err,
   glGetFramebufferAttachmentParameteriv(pname));
} else if (att-Type == GL_TEXTURE) {
 - if (att-Texture  att-Texture-Target == GL_TEXTURE_3D) {
 + if (att-Texture  (att-Texture-Target == GL_TEXTURE_3D ||
 + att-Texture-Target == GL_TEXTURE_3D_EXT ||
 + att-Texture-Target == GL_TEXTURE_2D_ARRAY ||
 + att-Texture-Target == GL_TEXTURE_2D_ARRAY_EXT)) {

GL_TEXTURE_3D == GL_TEXTURE_3D_EXT, and GL_TEXTURE_2D_ARRAY ==
GL_TEXTURE_2D_ARRAY_EXT

  *params = att-Zoffset;
   }
   else {
 

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

Re: [Mesa-dev] [PATCH 08/16] main: round floating-point value to nearest integer in glGetTexParameteriv()

This patch is

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 From: Samuel Iglesias Gonsalvez sigles...@igalia.com
 
 Previously, a cast was done to convert from float to int but there
 were rounding errors.
 
 The spec specificies in Data Conversion chapter that Floating-point values are
 rounded to the nearest integer.
 
 This patch fixes the following 8 dEQP tests:
 
 dEQP-GLES3.functional.state_query.texture.texture_2d_texture_min_lod_gettexparameteri
 dEQP-GLES3.functional.state_query.texture.texture_2d_texture_max_lod_gettexparameteri
 dEQP-GLES3.functional.state_query.texture.texture_3d_texture_min_lod_gettexparameteri
 dEQP-GLES3.functional.state_query.texture.texture_3d_texture_max_lod_gettexparameteri
 dEQP-GLES3.functional.state_query.texture.texture_2d_array_texture_min_lod_gettexparameteri
 dEQP-GLES3.functional.state_query.texture.texture_2d_array_texture_max_lod_gettexparameteri
 dEQP-GLES3.functional.state_query.texture.texture_cube_map_texture_min_lod_gettexparameteri
 dEQP-GLES3.functional.state_query.texture.texture_cube_map_texture_max_lod_gettexparameteri
 
 Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
 ---
  src/mesa/main/texparam.c | 17 -
  1 file changed, 12 insertions(+), 5 deletions(-)
 
 diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
 index e40fb24..2d5a9b7 100644
 --- a/src/mesa/main/texparam.c
 +++ b/src/mesa/main/texparam.c
 @@ -1658,14 +1658,18 @@ _mesa_GetTexParameteriv( GLenum target, GLenum pname, 
 GLint *params )
case GL_TEXTURE_MIN_LOD:
   if (!_mesa_is_desktop_gl(ctx)  !_mesa_is_gles3(ctx))
  goto invalid_pname;
 -
 - *params = (GLint) obj-Sampler.MinLod;
 + /* GL spec 'Data Conversions' section specifies that floating-point
 +  * value in integer Get function is rounded to nearest integer
 +  */
 + *params = IROUND(obj-Sampler.MinLod);
   break;
case GL_TEXTURE_MAX_LOD:
   if (!_mesa_is_desktop_gl(ctx)  !_mesa_is_gles3(ctx))
  goto invalid_pname;
 -
 - *params = (GLint) obj-Sampler.MaxLod;
 + /* GL spec 'Data Conversions' section specifies that floating-point
 +  * value in integer Get function is rounded to nearest integer
 +  */
 + *params = IROUND(obj-Sampler.MaxLod);
   break;
case GL_TEXTURE_BASE_LEVEL:
   if (!_mesa_is_desktop_gl(ctx)  !_mesa_is_gles3(ctx))
 @@ -1679,7 +1683,10 @@ _mesa_GetTexParameteriv( GLenum target, GLenum pname, 
 GLint *params )
case GL_TEXTURE_MAX_ANISOTROPY_EXT:
   if (!ctx-Extensions.EXT_texture_filter_anisotropic)
  goto invalid_pname;
 - *params = (GLint) obj-Sampler.MaxAnisotropy;
 + /* GL spec 'Data Conversions' section specifies that floating-point
 +  * value in integer Get function is rounded to nearest integer
 +  */
 + *params = IROUND(obj-Sampler.MaxAnisotropy);
   break;
case GL_GENERATE_MIPMAP_SGIS:
   if (ctx-API != API_OPENGL_COMPAT  ctx-API != API_OPENGLES)
 

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

Re: [Mesa-dev] [PATCH 09/16] main: round floating-point value to nearest integer in glGetSamplerParameteriv()

This patch is

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

It seems like we could use some refactoring so there isn't so much
duplicated code between GetSamplerParameter* and GetTexParameter*.

On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 From: Samuel Iglesias Gonsalvez sigles...@igalia.com
 
 Previously, a cast was done to convert from float to int but there
 were rounding errors.
 
 The spec specificies in Data Conversion chapter that Floating-point values are
 rounded to the nearest integer.
 
 This patch fixes the following 2 dEQP tests:
 
 dEQP-GLES3.functional.state_query.sampler.sampler_texture_min_lod_getsamplerparameteri
 dEQP-GLES3.functional.state_query.sampler.sampler_texture_max_lod_getsamplerparameteri
 
 Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
 ---
  src/mesa/main/samplerobj.c | 20 
  1 file changed, 16 insertions(+), 4 deletions(-)
 
 diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c
 index 18a14d8..cadc9cc 100644
 --- a/src/mesa/main/samplerobj.c
 +++ b/src/mesa/main/samplerobj.c
 @@ -1271,13 +1271,22 @@ _mesa_GetSamplerParameteriv(GLuint sampler, GLenum 
 pname, GLint *params)
*params = sampObj-MagFilter;
break;
 case GL_TEXTURE_MIN_LOD:
 -  *params = (GLint) sampObj-MinLod;
 +  /* GL spec 'Data Conversions' section specifies that floating-point
 +   * value in integer Get function is rounded to nearest integer
 +   */
 +  *params = IROUND(sampObj-MinLod);
break;
 case GL_TEXTURE_MAX_LOD:
 -  *params = (GLint) sampObj-MaxLod;
 +  /* GL spec 'Data Conversions' section specifies that floating-point
 +   * value in integer Get function is rounded to nearest integer
 +   */
 +  *params = IROUND(sampObj-MaxLod);
break;
 case GL_TEXTURE_LOD_BIAS:
 -  *params = (GLint) sampObj-LodBias;
 +  /* GL spec 'Data Conversions' section specifies that floating-point
 +   * value in integer Get function is rounded to nearest integer
 +   */
 +  *params = IROUND(sampObj-LodBias);
break;
 case GL_TEXTURE_COMPARE_MODE:
if (!ctx-Extensions.ARB_shadow)
 @@ -1290,7 +1299,10 @@ _mesa_GetSamplerParameteriv(GLuint sampler, GLenum 
 pname, GLint *params)
*params = sampObj-CompareFunc;
break;
 case GL_TEXTURE_MAX_ANISOTROPY_EXT:
 -  *params = (GLint) sampObj-MaxAnisotropy;
 +  /* GL spec 'Data Conversions' section specifies that floating-point
 +   * value in integer Get function is rounded to nearest integer
 +   */
 +  *params = IROUND(sampObj-MaxAnisotropy);
break;
 case GL_TEXTURE_BORDER_COLOR:
params[0] = FLOAT_TO_INT(sampObj-BorderColor.f[0]);
 

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

Re: [Mesa-dev] [PATCH 10/16] mesa: Allows querying GL_SAMPLER_BINDING on GLES3 profile

This patch is

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 From GLES3 specification (page 123), The currently bound sampler may be
 queried by calling GetIntegerv with pname set to
 SAMPLER_BINDINGGL_SAMPLER_BINDING.
 
 Fixes 4 dEQP tests:
 * dEQP-GLES3.functional.state_query.integers.sampler_binding_getboolean
 * dEQP-GLES3.functional.state_query.integers.sampler_binding_getinteger
 * dEQP-GLES3.functional.state_query.integers.sampler_binding_getinteger64
 * dEQP-GLES3.functional.state_query.integers.sampler_binding_getfloat
 ---
  src/mesa/main/get_hash_params.py | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)
 
 diff --git a/src/mesa/main/get_hash_params.py 
 b/src/mesa/main/get_hash_params.py
 index a3bf1cb..c70ed04 100644
 --- a/src/mesa/main/get_hash_params.py
 +++ b/src/mesa/main/get_hash_params.py
 @@ -403,6 +403,11 @@ descriptor=[
[ TEXTURE_EXTERNAL_OES, LOC_CUSTOM, TYPE_BOOLEAN, 0, 
 extra_OES_EGL_image_external ],
  ]},
  
 +{ apis: [GL, GL_CORE, GLES3], params: [
 +# GL_ARB_sampler_objects / GL 3.3 / GLES 3.0
 +  [ SAMPLER_BINDING, LOC_CUSTOM, TYPE_INT, GL_SAMPLER_BINDING, NO_EXTRA 
 ],
 +]},
 +
  # Remaining enums are only in OpenGL
  { apis: [GL, GL_CORE], params: [
[ ACCUM_RED_BITS, BUFFER_INT(Visual.accumRedBits), NO_EXTRA ],
 @@ -695,10 +700,6 @@ descriptor=[
[ SAMPLE_MASK, CONTEXT_BOOL(Multisample.SampleMask), 
 extra_ARB_texture_multisample ],
[ MAX_SAMPLE_MASK_WORDS, CONST(1), extra_ARB_texture_multisample ],
  
 -
 -# GL_ARB_sampler_objects / GL 3.3
 -  [ SAMPLER_BINDING, LOC_CUSTOM, TYPE_INT, GL_SAMPLER_BINDING, NO_EXTRA 
 ],
 -
  # GL 3.0
[ CONTEXT_FLAGS, CONTEXT_INT(Const.ContextFlags), extra_version_30 ],
  
 

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

Re: [Mesa-dev] [PATCH 01/16] i965: Sets missing vertex shader constant values for HighInt format

This patch is

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 The range's min and max, and the precision value are not set correctly for the
 vertex shader constants.
 
 Fixes 1 dEQP test: 
 dEQP-GLES3.functional.state_query.shader.precision_vertex_highp_int
 ---
  src/mesa/drivers/dri/i965/brw_context.c | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
 b/src/mesa/drivers/dri/i965/brw_context.c
 index 860ee22d..03b4ee3 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.c
 +++ b/src/mesa/drivers/dri/i965/brw_context.c
 @@ -480,6 +480,12 @@ brw_initialize_context_constants(struct brw_context *brw)
 ctx-Const.Program[MESA_SHADER_FRAGMENT].HighInt = 
 ctx-Const.Program[MESA_SHADER_FRAGMENT].LowInt;
 ctx-Const.Program[MESA_SHADER_FRAGMENT].MediumInt = 
 ctx-Const.Program[MESA_SHADER_FRAGMENT].LowInt;
  
 +   ctx-Const.Program[MESA_SHADER_VERTEX].LowInt.RangeMin = 31;
 +   ctx-Const.Program[MESA_SHADER_VERTEX].LowInt.RangeMax = 30;
 +   ctx-Const.Program[MESA_SHADER_VERTEX].LowInt.Precision = 0;
 +   ctx-Const.Program[MESA_SHADER_VERTEX].HighInt = 
 ctx-Const.Program[MESA_SHADER_VERTEX].LowInt;
 +   ctx-Const.Program[MESA_SHADER_VERTEX].MediumInt = 
 ctx-Const.Program[MESA_SHADER_VERTEX].LowInt;
 +
 if (brw-gen = 7) {
ctx-Const.Program[MESA_SHADER_FRAGMENT].MaxAtomicCounters = 
 MAX_ATOMIC_COUNTERS;
ctx-Const.Program[MESA_SHADER_VERTEX].MaxAtomicCounters = 
 MAX_ATOMIC_COUNTERS;
 

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

Re: [Mesa-dev] [PATCH 03/16] mesa: Clamps the stencil value masks to GLint when queried

On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 Stencil value masks values (ctx-Stencil.ValueMask[]) stores GLuint values
 which are initialized with max unsigned integer (~0u). When these values
 are queried by glGet* (GL_STENCIL_VALUE_MASK or GL_STENCIL_BACK_VALUE_MASK),
 they are converted to a signed integer. Currently, these values overflow
 and return incorrect result (-1).
 
 This patch clamps these values to max int (0x7FFF) before storing.

This feels wrong.  Is there some justification in the spec for this
behavior?

 Fixes 6 dEQP failing tests:
 * dEQP-GLES3.functional.state_query.integers.stencil_value_mask_getfloat
 * dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_getfloat
 * 
 dEQP-GLES3.functional.state_query.integers.stencil_value_mask_separate_getfloat
 * 
 dEQP-GLES3.functional.state_query.integers.stencil_value_mask_separate_both_getfloat
 * 
 dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_separate_getfloat
 * 
 dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_separate_both_getfloat
 ---
  src/mesa/main/get.c  | 11 ++-
  src/mesa/main/get_hash_params.py |  2 +-
  2 files changed, 11 insertions(+), 2 deletions(-)
 
 diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
 index 6091efc..4578a36 100644
 --- a/src/mesa/main/get.c
 +++ b/src/mesa/main/get.c
 @@ -726,7 +726,16 @@ find_custom_value(struct gl_context *ctx, const struct 
 value_desc *d, union valu
v-value_int = _mesa_get_stencil_ref(ctx, 1);
break;
 case GL_STENCIL_VALUE_MASK:
 -  v-value_int = ctx-Stencil.ValueMask[ctx-Stencil.ActiveFace];
 +  /* Since stencil value mask is a GLuint, it requires clamping
 +   * before storing in a signed int to avoid overflow.
 +   * Notice that Stencil.ValueMask values are initialized to ~0u,
 +   * so without clamping it will return -1 when assigned to value_int.
 +   */
 +  v-value_int = ctx-Stencil.ValueMask[ctx-Stencil.ActiveFace]  
 0x7FFF;
 +  break;
 +   case GL_STENCIL_BACK_VALUE_MASK:
 +  /* Same as with GL_STENCIL_VALUE_MASK, value requires claming. */
 +  v-value_int = ctx-Stencil.ValueMask[1]  0x7FFF;
break;
 case GL_STENCIL_WRITEMASK:
v-value_int = ctx-Stencil.WriteMask[ctx-Stencil.ActiveFace];
 diff --git a/src/mesa/main/get_hash_params.py 
 b/src/mesa/main/get_hash_params.py
 index 09a61ac..a3bf1cb 100644
 --- a/src/mesa/main/get_hash_params.py
 +++ b/src/mesa/main/get_hash_params.py
 @@ -283,7 +283,7 @@ descriptor=[
  
  # OpenGL 2.0
[ STENCIL_BACK_FUNC, CONTEXT_ENUM(Stencil.Function[1]), NO_EXTRA ],
 -  [ STENCIL_BACK_VALUE_MASK, CONTEXT_INT(Stencil.ValueMask[1]), NO_EXTRA 
 ],
 +  [ STENCIL_BACK_VALUE_MASK, LOC_CUSTOM, TYPE_INT, NO_OFFSET, NO_EXTRA],
[ STENCIL_BACK_WRITEMASK, CONTEXT_INT(Stencil.WriteMask[1]), NO_EXTRA 
 ],
[ STENCIL_BACK_REF, LOC_CUSTOM, TYPE_INT, NO_OFFSET, NO_EXTRA ],
[ STENCIL_BACK_FAIL, CONTEXT_ENUM(Stencil.FailFunc[1]), NO_EXTRA ],
 

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

Re: [Mesa-dev] [PATCH 11/16] mesa: Returns a GL_INVALID_VALUE error if num of fbos in glDeleteFramebuffers is negative

This patch and patch 12 are

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

Are there other 'delete' functions that should generate this same error
(but don't)?

On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 Per GLES3 manual for glDeleteFramebuffers
 https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteFramebuffers.xhtml,
 GL_INVALID_VALUE is generated if n is negative.
 
 Fixes 1 dEQP test:
 * dEQP-GLES3.functional.negative_api.buffer.delete_framebuffers
 ---
  src/mesa/main/fbobject.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
 index c3f01c9..df85b8c 100644
 --- a/src/mesa/main/fbobject.c
 +++ b/src/mesa/main/fbobject.c
 @@ -2218,6 +2218,11 @@ _mesa_DeleteFramebuffers(GLsizei n, const GLuint 
 *framebuffers)
 GLint i;
 GET_CURRENT_CONTEXT(ctx);
  
 +   if (n  0) {
 +  _mesa_error(ctx, GL_INVALID_VALUE, glDeleteFramebuffers(n));
 +  return;
 +   }
 +
 FLUSH_VERTICES(ctx, _NEW_BUFFERS);
  
 for (i = 0; i  n; i++) {
 

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

Re: [Mesa-dev] [PATCH 11/16] mesa: Returns a GL_INVALID_VALUE error if num of fbos in glDeleteFramebuffers is negative

On 12/11/2014 06:21 PM, Ian Romanick wrote:
 This patch and patch 12 are
 
 Reviewed-by: Ian Romanick ian.d.roman...@intel.com
 
 Are there other 'delete' functions that should generate this same error
 (but don't)?

I see patch 14 now. :)

One other comment...

 
 On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 Per GLES3 manual for glDeleteFramebuffers
 https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteFramebuffers.xhtml,
 GL_INVALID_VALUE is generated if n is negative.

 Fixes 1 dEQP test:
 * dEQP-GLES3.functional.negative_api.buffer.delete_framebuffers
 ---
  src/mesa/main/fbobject.c | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
 index c3f01c9..df85b8c 100644
 --- a/src/mesa/main/fbobject.c
 +++ b/src/mesa/main/fbobject.c
 @@ -2218,6 +2218,11 @@ _mesa_DeleteFramebuffers(GLsizei n, const GLuint 
 *framebuffers)
 GLint i;
 GET_CURRENT_CONTEXT(ctx);
  
 +   if (n  0) {
 +  _mesa_error(ctx, GL_INVALID_VALUE, glDeleteFramebuffers(n));

Maybe say glDeleteFramebuffers(n  0).

 +  return;
 +   }
 +
 FLUSH_VERTICES(ctx, _NEW_BUFFERS);
  
 for (i = 0; i  n; i++) {

 

___
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 TGSI_SEMANTIC_VERTEXID_ZEROBASE and TGSI_SEMANTIC_BASEVERTEX

2014-12-11 Thread Roland Scheidegger

Am 11.12.2014 um 23:51 schrieb Marek Olšák:
What radeonsi does is:

basevertex = info-indexed ? info-index_bias : info-start;

This is also what the hardware does for indirect draws and we cannot
change it. The basevertex shader system value must contain start,
because it's used to fetch vertices in vertex shaders.

Ok then I'll stick with that I was hoping this would be the case. It
would be GREAT if the GL spec could clarify that somewhere (probably in
ARB_shader_draw_parameters unless it already does so somewhere else...).

Roland

Marek

On Thu, Dec 11, 2014 at 7:50 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 11.12.2014 um 17:49 schrieb Ilia Mirkin:
On Thu, Dec 11, 2014 at 11:39 AM, Jose Fonseca jfons...@vmware.com wrote:
Overall I think this is a great cleanup.

Just a remark about the chosen names.

On 10/12/14 21:22, srol...@vmware.com wrote:

From: Roland Scheidegger srol...@vmware.com

Plus a new PIPE_CAP_VERTEXID_NOOFFSET query.

Vertex offset and base vertex are difference concepts, so I'd rather
not
mix them up.

AFAICT, this is about base vertex, not offsets in vertex buffers, hence
NOOFFSET seems to be a misnomer. Please pick NOBASE or ZEROBASE suffix
and stick with it.

Personally, I prefer NOBASE. As ZEROBASE sounds like that base vertex
must some how be zero, which is not the case.

Is all this really just about the base vertex? The situation on, e.g.,
a3xx is that the vertex id does not include any offset, even the
'start' from glDrawArrays (which makes sense, since they use the same
general logic).

-ilia

Well this is actually kind of unresolved. I thought that gl_BaseVertex
would include first parameter and similar of DrawArrays, so that
really gl_VertexID = gl_BaseVertex + vertex id without basevertex
included as known from d3d10. Always. And not just for DrawElements
calls (which would be a pain - the ARB_shader_draw_parameters extension
sort of implies it could be used to translate between different APIs,
but it's mostly useless if it doesn't work for all kind of draw calls)!

The discussion about this was here:
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_mesa-2Ddev_2014-2DAugust_065172.htmld=AAIBaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_Im=yvAzSgghgk7I0SyY4IpQp17eF3KbGdo6vAUDzUp0WcAs=DCH0a8trKArcjz7_D68a9m9ew5Bq-Bzlzv0y5Er9dGMe=

So, I have no idea if this is right. And you are right BaseVertex is
sort of ambigous there, I guess if it doesn't include drawArrays first
parameter the whole point of lowering is kinda lost. I've written this
under the assumption that gl_Basevertex does include first from
DrawArrays, so the ambigous name wasn't chosen by me in that case then :-).

Roland

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddevd=AAIBaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_Im=yvAzSgghgk7I0SyY4IpQp17eF3KbGdo6vAUDzUp0WcAs=tXRzMLhFIZCBb261uxvBO-GgsAU8kYr5ncU-s7aEDQMe=

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

Re: [Mesa-dev] [PATCH 13/16] mesa: Adds check for integer internal formal and num samples in glRenderbufferStorageMultisample

On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 Per GLES3 specification, section 4.4 Framebuffer objects page 198, If
 internalformat is a signed or unsigned integer format and samples is greater
 than zero, then the error INVALID_OPERATION is generated..
 
 Fixes 1 dEQP test:
 * dEQP-GLES3.functional.negative_api.buffer.renderbuffer_storage_multisample
 ---
  src/mesa/main/fbobject.c | 9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
 index 7e1ff1b..a18f11c 100644
 --- a/src/mesa/main/fbobject.c
 +++ b/src/mesa/main/fbobject.c
 @@ -1814,6 +1814,15 @@ renderbuffer_storage(GLenum target, GLenum 
 internalFormat,
samples = 0;
 }
 else {
 +  if (_mesa_is_gles3(ctx)  
 _mesa_is_enum_format_integer(internalFormat)) {
 + /* Per GLES3 specification, section 4.4 Framebuffer objects page 
 198, If
 +  * internalformat is a signed or unsigned integer format and 
 samples is greater
 +  * than zero, then the error INVALID_OPERATION is generated..
 +  */

Please use the canonical spec quotation format:

 /* Section 4.4 (Framebuffer objects) of the OpenGL 3.0 specification 
says:
  *
  * If internalformat is a signed or unsigned integer format and 
samples
  * is greater than zero, then the error INVALID_OPERATION is 
generated.
  */

It also seems like this check belongs in _mesa_check_sample_count.  I
expect textures have the same limitation.

 + _mesa_error(ctx, GL_INVALID_OPERATION, %s(samples), func);
 + return;
 +  }
 +
/* check the sample count;
 * note: driver may choose to use more samples than what's requested
 */
 

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

Re: [Mesa-dev] [PATCH 15/16] mesa: Fix error reporting for some cases of incomplete FBO attachments

On 12/11/2014 02:34 PM, Eduardo Lima Mitev wrote:
 From: Iago Toral Quiroga ito...@igalia.com
 
 According to the OpenGL and OpenGL ES specs (sections
 FRAMEBUFFER COMPLETENESS and Whole Framebuffer Completeness),
 the image for color, depth or stencil attachments must be renderable,
 otherwise the attachment is considered incomplete and we should report
 GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT. Currently, we detect this
 situation properly but report a different error.
 
 This fixes the following 3 piglit tests:
 dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb_unsigned_int_2_10_10_10_rev
 dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgba_unsigned_int_2_10_10_10_rev
 dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb16f
 ---
  src/mesa/main/fbobject.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
 index a18f11c..28ba45f 100644
 --- a/src/mesa/main/fbobject.c
 +++ b/src/mesa/main/fbobject.c
 @@ -966,7 +966,7 @@ _mesa_test_framebuffer_completeness(struct gl_context 
 *ctx,
   if (!is_format_color_renderable(ctx, attFormat,
   texImg-InternalFormat) 
   !is_legal_depth_format(ctx, f)) {
 -fb-_Status = GL_FRAMEBUFFER_INCOMPLETE_FORMATS_EXT;
 +fb-_Status = GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT;

If we're going to change the enum, use the non-_EXT version.  With that
fixed, this patch is

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

  fbo_incomplete(ctx, texture attachment incomplete, -1);
  return;
   }
 

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

[Mesa-dev] [PATCH] gallium: add TGSI_SEMANTIC_VERTEXID_NOBASE and TGSI_SEMANTIC_BASEVERTEX

2014-12-11 Thread sroland

From: Roland Scheidegger srol...@vmware.com

Plus a new PIPE_CAP_VERTEXID_NOBASE query. The idea is that drivers not
supporting vertex ids with base vertex offset applied (so, only support
d3d10-style vertex ids) will get such a d3d10-style vertex id instead -
with the caveat they'll also need to handle the basevertex system value
too (this follows what core mesa already does).
Additionally, this is also useful for other state trackers (for instance
llvmpipe / draw right now implement the d3d10 behavior on purpose, but
with different semantics it can just do both).
Doesn't do anything yet.
And fix up the docs wrt similar values.

v2: incorporate feedback from Brian and others, better names, better docs.
---
 src/gallium/auxiliary/tgsi/tgsi_scan.c   |  6 +++
 src/gallium/auxiliary/tgsi/tgsi_scan.h   |  2 +
 src/gallium/auxiliary/tgsi/tgsi_strings.c|  2 +
 src/gallium/docs/source/screen.rst   |  8 
 src/gallium/docs/source/tgsi.rst | 53 +---
 src/gallium/drivers/freedreno/freedreno_screen.c |  1 +
 src/gallium/drivers/i915/i915_screen.c   |  1 +
 src/gallium/drivers/ilo/ilo_screen.c |  2 +
 src/gallium/drivers/llvmpipe/lp_screen.c |  2 +
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
 src/gallium/drivers/r300/r300_screen.c   |  1 +
 src/gallium/drivers/r600/r600_pipe.c |  1 +
 src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
 src/gallium/drivers/softpipe/sp_screen.c |  2 +
 src/gallium/drivers/svga/svga_screen.c   |  1 +
 src/gallium/drivers/vc4/vc4_screen.c |  1 +
 src/gallium/include/pipe/p_defines.h |  1 +
 src/gallium/include/pipe/p_shader_tokens.h   |  4 +-
 19 files changed, 85 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 649c327..eb313e4 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -213,6 +213,12 @@ tgsi_scan_shader(const struct tgsi_token *tokens,
   else if (semName == TGSI_SEMANTIC_VERTEXID) {
  info-uses_vertexid = TRUE;
   }
+  else if (semName == TGSI_SEMANTIC_VERTEXID_NOBASE) {
+ info-uses_vertexid_nobase = TRUE;
+  }
+  else if (semName == TGSI_SEMANTIC_BASEVERTEX) {
+ info-uses_basevertex = TRUE;
+  }
   else if (semName == TGSI_SEMANTIC_PRIMID) {
  info-uses_primid = TRUE;
   }
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.h 
b/src/gallium/auxiliary/tgsi/tgsi_scan.h
index 61ce813..375f75a 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.h
@@ -74,6 +74,8 @@ struct tgsi_shader_info
boolean uses_kill;  /** KILL or KILL_IF instruction used? */
boolean uses_instanceid;
boolean uses_vertexid;
+   boolean uses_vertexid_nobase;
+   boolean uses_basevertex;
boolean uses_primid;
boolean uses_frontface;
boolean writes_psize;
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c 
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 01fa5a9..bd97544 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -86,6 +86,8 @@ const char *tgsi_semantic_names[TGSI_SEMANTIC_COUNT] =
SAMPLEPOS,
SAMPLEMASK,
INVOCATIONID,
+   VERTEXID_NOBASE,
+   BASEVERTEX,
 };
 
 const char *tgsi_texture_names[TGSI_TEXTURE_COUNT] =
diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index e711ad4..55d114c 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -233,6 +233,14 @@ The integer capabilities:
 * ``PIPE_CAP_CLIP_HALFZ``: Whether the driver supports the
   pipe_rasterizer_state::clip_halfz being set to true. This is required
   for enabling ARB_clip_control.
+* ``PIPE_CAP_VERTEXID_NOBASE``: If true, the driver only supports
+  TGSI_SEMANTIC_VERTEXID_NOBASE (and not TGSI_SEMANTIC_VERTEXID). This means
+  state trackers for APIs whose vertexIDs are offset by basevertex (such as GL)
+  will need to lower TGSI_SEMANTIC_VERTEXID to TGSI_SEMANTIC_VERTEXID_NOBASE
+  and TGSI_SEMANTIC_BASEVERTEX, so drivers setting this must handle both these
+  semantics. Only relevant if geometry shaders are supported.
+  (Currently not possible to query availability of these two semantics outside
+  this, at least BASEVERTEX should be exposed separately too).
 
 
 .. _pipe_capf:
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index cbb8f74..a2a240d 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -2651,7 +2651,7 @@ TGSI_SEMANTIC_VIEWPORT_INDEX
 
 For geometry shaders, this semantic label

Re: [Mesa-dev] [PATCH] r600: fix FMASK allocation on r600/700

2014-12-11 Thread Dave Airlie

On 11 December 2014 at 06:45, Marek Olšák mar...@gmail.com wrote:
 It uses the libdrm surface allocator and FMASK is 2D tiled. Maybe the
 rounding of bpp affects the pitch in a bad way.


I found this sentence hidden in tcore fmask allocator.

// Note that pitch_tile_max is shared with the color surface and must be padded

That reads to me that the fmask pitch needs to align with the color
surface pitch,

Maybe you guys can dig me out some more info on where this applies.

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

Re: [Mesa-dev] [PATCH 1/2] glsl: Add blob.c---a simple interface for serializing data

Hey Carl,
Yeah, this looks nifty.  I've got some comments on the implementation
though.

On Dec 11, 2014 11:55 AM, Carl Worth cwo...@cworth.org wrote:

 This new interface allows for writing a series of objects to a chunk
 of memory (a blob).. The allocated memory is maintained within the
 blob itself, (and re-allocated by doubling when necessary).

 There are also functions for reading objects from a blob as well. If
 code attempts to read beyond the available memory, the read functions
 return 0 values (or its moral equivalent) without reading past the
 allocated memory. Once the caller is done with the reads, it can check
 blob-overrun to ensure whether any invalid values were previously
 returned due to attempts to read too far.
 ---
  src/glsl/Makefile.sources |   3 +-
  src/glsl/blob.c   | 287
++
  src/glsl/blob.h   | 263
++
  3 files changed, 552 insertions(+), 1 deletion(-)
  create mode 100644 src/glsl/blob.c
  create mode 100644 src/glsl/blob.h

 diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
 index 676fa0d..875e4bf 100644
 --- a/src/glsl/Makefile.sources
 +++ b/src/glsl/Makefile.sources
 @@ -105,7 +105,8 @@ LIBGLSL_FILES = \
 $(GLSL_SRCDIR)/opt_swizzle_swizzle.cpp \
 $(GLSL_SRCDIR)/opt_tree_grafting.cpp \
 $(GLSL_SRCDIR)/opt_vectorize.cpp \
 -   $(GLSL_SRCDIR)/s_expression.cpp
 +   $(GLSL_SRCDIR)/s_expression.cpp \
 +   $(GLSL_SRCDIR)/blob.c

  # glsl_compiler

 diff --git a/src/glsl/blob.c b/src/glsl/blob.c
 new file mode 100644
 index 000..0af71fc
 --- /dev/null
 +++ b/src/glsl/blob.c
 @@ -0,0 +1,287 @@
 +/*
 + * Copyright © 2014 Intel Corporation
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining
a
 + * copy of this software and associated documentation files (the
Software),
 + * to deal in the Software without restriction, including without
limitation
 + * the rights to use, copy, modify, merge, publish, distribute,
sublicense,
 + * and/or sell copies of the Software, and to permit persons to whom the
 + * Software is furnished to do so, subject to the following conditions:
 + *
 + * The above copyright notice and this permission notice (including the
next
 + * paragraph) shall be included in all copies or substantial portions of
the
 + * Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
 + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
SHALL
 + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
 + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING
 + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
 + * IN THE SOFTWARE.
 + */
 +
 +#include string.h
 +
 +#include main/macros.h
 +#include util/ralloc.h
 +#include blob.h
 +
 +#define BLOB_INITIAL_SIZE 4096
 +
 +/* Ensure that \blob will be able to fit an additional object of size
 + * \additional.  The growing (if any) will occur by doubling the existing
 + * allocation.
 + */
 +static bool
 +grow_to_fit (struct blob *blob, size_t additional)
 +{
 +   size_t to_allocate;
 +   uint8_t *new_data;
 +
 +   if (blob-size + additional = blob-allocated)
 +  return true;
 +
 +   if (blob-allocated == 0)
 +  to_allocate = BLOB_INITIAL_SIZE;
 +   else
 +  to_allocate = blob-allocated * 2;

What happens if additional is bigger than blob-size?  Maybe iterate (if
you want to keep power-of-two) or take a max here.

 +
 +   new_data = reralloc_size(blob, blob-data, to_allocate);
 +   if (new_data == NULL)
 +  return false;
 +
 +   blob-data = new_data;
 +   blob-allocated = to_allocate;
 +
 +   return true;
 +}
 +
 +/* Align the blob-size so that reading or writing a value at
(blob-data +
 + * blob-size) will result in an access aligned to a granularity of
\alignment
 + * bytes.
 + *
 + * \return True unless allocation fails
 + */
 +static bool
 +align_blob (struct blob *blob, size_t alignment)
 +{
 +   size_t new_size;
 +
 +   new_size = ALIGN(blob-size, alignment);

Do we what to align the pointer or the size?  Aligning the size only makes
sense if the pointer is already aligned.  At the very least, we should
assert that the requested alignment is less than or equal to the known
pointer alignment for the start of the blob.

 +
 +   if (! grow_to_fit (blob, new_size - blob-size))
 +  return false;
 +
 +   blob-size = new_size;
 +
 +   return true;
 +}
 +
 +static void
 +align_blob_reader (struct blob_reader *blob, size_t alignment)
 +{
 +   blob-current = blob-data + ALIGN(blob-current - blob-data,
alignment);

Again, pointer or size?  Also, why is this way up here when the other
reader stuff comes later.

 +}
 +
 +struct blob *
 +blob_create (void *mem_ctx)
 +{
 +   struct blob *blob;
 +
 +   blob = ralloc(mem_ctx, struct blob);
 +

Re: [Mesa-dev] [PATCH 2/2] glsl: Add blob_overwrite_bytes and blob_overwrite_uint32

On Dec 11, 2014 11:55 AM, Carl Worth cwo...@cworth.org wrote:

 From: Tapani Pälli tapani.pa...@intel.com

 These functions are useful when serializing an unknown number of items
 to a blob. The caller can first save the current offset, write a
 placeholder uint32, write out (and count) the items, then use
 blob_overwrite_uint32 with the saved offset to replace the placeholder
 value.

 Then, when deserializing, the reader will first read the count and
 know how many subsequent items to expect.

 (I wrote this code after reading a very similar patch written by
 Tapani when he wrote serialization code for IR. Since I re-used the
 idea of his code so directly, I've credited him as the author of this
 code. --Carl)
 ---
  src/glsl/blob.c | 23 +++
  src/glsl/blob.h | 25 +
  2 files changed, 48 insertions(+)

 diff --git a/src/glsl/blob.c b/src/glsl/blob.c
 index 0af71fc..dbd698a 100644
 --- a/src/glsl/blob.c
 +++ b/src/glsl/blob.c
 @@ -101,6 +101,21 @@ blob_create (void *mem_ctx)
  }

  bool
 +blob_overwrite_bytes (struct blob *blob,
 +  size_t offset,
 +  const void *bytes,
 +  size_t to_write)
 +{
 +   /* Detect an attempt to overwrite data out of bounds. */
 +   if (offset  0 || blob-size - offset  to_write)
 +  return false;
 +
 +   memcpy (blob-data + offset, bytes, to_write);
 +
 +   return true;
 +}
 +
 +bool
  blob_write_bytes (struct blob *blob, const void *bytes, size_t to_write)
  {
 if (! grow_to_fit (blob, to_write))
 @@ -135,6 +150,14 @@ blob_write_uint32 (struct blob *blob, uint32_t value)
  }

  bool
 +blob_overwrite_uint32 (struct blob *blob,
 +   size_t offset,
 +   uint32_t value)
 +{
 +   return blob_overwrite_bytes(blob, offset, value, sizeof(value));
 +}
 +
 +bool
  blob_write_uint64 (struct blob *blob, uint64_t value)
  {
 align_blob(blob, sizeof(value));
 diff --git a/src/glsl/blob.h b/src/glsl/blob.h
 index 374b21e..165de13 100644
 --- a/src/glsl/blob.h
 +++ b/src/glsl/blob.h
 @@ -138,6 +138,31 @@ bool
  blob_write_uint32 (struct blob *blob, uint32_t value);

The header entry for overwrite_bytes should go in this patch rather than
the first one.


  /**
 + * Overwrite a uint32_t previously written to the blob.
 + *
 + * Writes a uint32_t value to an existing portion of the blob at an
offset of
 + * \offset.  This data range must have previously been written to the
blob by
 + * one of the blob_write_* calls.
 + *
 + *
 + * The expected usage is something like the following pattern:
 + *
 + * size_t offset;
 + *
 + * offset = blob-size;
 + * blob_write_uint32 (blob, 0); // placeholder
 + * ... various blob write calls, writing N items ...
 + * blob_overwrite_uint32 (blob, offset, N);
 + *
 + * \return True unless the requested position or position+to_write lie
outside
 + * the current blob's size.
 + */
 +bool
 +blob_overwrite_uint32 (struct blob *blob,
 +   size_t offset,
 +   uint32_t value);
 +
 +/**
   * Add a uint64_t to a blob.
   *
   * Note: This function will only write to a uint64_t-aligned offset from
the
 --
 2.1.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] Precision of float and trigonometric functions on i965

On Dec 11, 2014 11:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote:

 On Thu, Dec 11, 2014 at 2:10 PM, Chris Forbes chr...@ijw.co.nz wrote:
  Iago,
 
  This doesn't matter for GL conformance -- but the impression I get is
  that dEQP is aiming at something more.
 
  In any case, the usual problem with this is inaccurate range
  reduction, which is fixable in software at some performance cost. The
  C library does this, for example.

 Probably related to this:


https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/

That's a fun article, but beside the point for what we probably care
about.  No one cares about precisely computing sin(pi) to hundreds of
decimal places on a GPU.

If we really want to fix the issue, we can do range reduction at the cost
of probably a couple extra instructions.  That said, I doubt this will be
an issue in real life as x % pi begins to get fairly imprecise at those
magnitudes.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/16] i965: Fix bitcast operations with negate

On Thu, 2014-12-11 at 16:52 -0800, Kenneth Graunke wrote:
 On Thursday, December 11, 2014 11:34:11 PM Eduardo Lima Mitev wrote:
  From: Iago Toral Quiroga ito...@igalia.com
  
  For code such as this in a vertex or fragment shader:
  
  uniform float in0;
  flat out float out0;
  ...
  out0 = ceil(in0)
  
  We generate this IR:
  
  (assign  (x) (var_ref packed:out0)
 (expression int bitcast_f2i
 (expression float ceil (var_ref in0) ) ) )
  
  In i965, this would eventually become:
  
  rndd(8) g141.xF   -g30,4,1.xF
  mov(8)  g61.xD-g144,4,1.xD
  mov(8)  g1161Dg64,4,1D
 
 Weird...it does indeed use RNDD.  Shouldn't it use RNDU instead?

Right, that is what I thought too but then I realized that RNDU isn't
even defined in brw_fs.h so I figured that maybe there was a reason for
that. The implementation with RNDD does work though...

Iago

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

Re: [Mesa-dev] [PATCH v3 10/24] main: Add a concept of an array format

On Thu, 2014-12-11 at 11:24 -0800, Jason Ekstrand wrote:
 
 
 On Tue, Dec 9, 2014 at 4:06 AM, Iago Toral Quiroga ito...@igalia.com
 wrote:
 From: Jason Ekstrand jason.ekstr...@intel.com
 
 An array format is a 32-bit integer format identifier that can
 represent
 any format that can be represented as an array of standard GL
 datatypes.
 Whie the MESA_FORMAT enums provide several of these, they
 don't account for
 all of them.
 
 v2 by Iago Toral Quiroga ito...@igalia.com:
  - Implement mesa_array_format as a plain bitfiled uint32_t
 type instead of
using a struct inside a union to access the various
 components packed in
it. This is necessary to support bigendian properly, as
 pointed out by
Ian.
  - Squashed: Make float types normalized
 ---
  src/mesa/main/format_info.py |  16 +
  src/mesa/main/formats.c  |  57 ++
  src/mesa/main/formats.h  | 136
 ++-
  3 files changed, 208 insertions(+), 1 deletion(-)
 
 diff --git a/src/mesa/main/format_info.py
 b/src/mesa/main/format_info.py
 index 7424fe0..fe2063d 100644
 --- a/src/mesa/main/format_info.py
 +++ b/src/mesa/main/format_info.py
 @@ -192,6 +192,22 @@ for fmat in formats:
 
 int(fmat.block_size() / 8))
 
 print '  {{ {0} }},'.format(', '.join(map(str,
 fmat.swizzle)))
 +   if fmat.is_array():
 +  chan = fmat.array_element()
 +  norm = chan.norm or chan.type == parser.FLOAT
 +  print '  MESA_ARRAY_FORMAT({0}),'.format(',
 '.join([
 + str(chan.size / 8),
 + str(int(chan.sign)),
 + str(int(chan.type == parser.FLOAT)),
 + str(int(norm)),
 + str(len(fmat.channels)),
 + str(fmat.swizzle[0]),
 + str(fmat.swizzle[1]),
 + str(fmat.swizzle[2]),
 + str(fmat.swizzle[3]),
 +  ]))
 +   else:
 +  print '  0,'
 print '   },'
 
  print '};'
 diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
 index 676ac27..1259892 100644
 --- a/src/mesa/main/formats.c
 +++ b/src/mesa/main/formats.c
 @@ -71,6 +71,7 @@ struct gl_format_info
 GLubyte BytesPerBlock;
 
 uint8_t Swizzle[4];
 +   mesa_array_format ArrayFormat;
  };
 
  #include format_info.c
 @@ -269,6 +270,62 @@ _mesa_get_format_swizzle(mesa_format
 format, uint8_t swizzle_out[4])
 memcpy(swizzle_out, info-Swizzle, sizeof(info-Swizzle));
  }
 
 +mesa_array_format
 +_mesa_array_format_flip_channels(mesa_array_format format)
 +{
 +   int num_channels;
 +   uint8_t swizzle[4];
 +
 +   num_channels =
 _mesa_array_format_get_num_channels(format);
 +   _mesa_array_format_get_swizzle(format, swizzle);
 +
 +   if (num_channels == 1)
 +  return format;
 +
 +   if (num_channels == 2) {
 +  _mesa_array_format_set_swizzle(format, swizzle[1],
 swizzle[0],
 + swizzle[2], swizzle[3]);
 +  return format;
 +   }
 +
 +   if (num_channels == 4) {
 +  _mesa_array_format_set_swizzle(format, swizzle[3],
 swizzle[2],
 + swizzle[1], swizzle[0]);
 +  return format;
 +   }
 +
 +   unreachable(Invalid array format);
 +}
 +
 +uint32_t
 +_mesa_format_to_array_format(mesa_format format)
 +{
 +   const struct gl_format_info *info =
 _mesa_get_format_info(format);
 +   if (_mesa_little_endian())
 +  return info-ArrayFormat;
 +   else
 +  return
 _mesa_array_format_flip_channels(info-ArrayFormat);
 +}
 +
 +mesa_format
 +_mesa_format_from_array_format(uint32_t array_format)
 +{
 +   mesa_array_format af;
 +   unsigned f;
 +
 +   assert(_mesa_format_is_mesa_array_format(array_format));
 +
 +   if (_mesa_little_endian())
 +  af = array_format;
 +   else
 +  af = _mesa_array_format_flip_channels(array_format);
 +
 +   for (f = 1; f  MESA_FORMAT_COUNT; ++f)
 +  if (_mesa_get_format_info(f)-ArrayFormat == af)
 + return f;
 +
 +   return MESA_FORMAT_NONE;
 +}

Re: [Mesa-dev] [PATCH v3 10/24] main: Add a concept of an array format