Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Francisco Jerez]

Tom Stellard  writes:

> On Mon, Jan 13, 2014 at 06:44:15PM +, Dorrington, Albert wrote:
>> Tom,
>> 
>> Thanks for your response. I am very interested in implementing this, so any 
>> pointers you can provide would be greatly appreciated.
>
> I'm cc'ing Fransisco since he may also have some feedback.
>
> The first step is to build a clover::module object from the binary code.
> When we compile OpenCL C, we use the build_module_llvm() function in
> llvm/invocation.cpp to do this.  This function takes LLVM IR as input
> (stored in the LLVM:Module object) and produces a clover::module as
> output.
>
> With clCreateProgramFromBinary() we build a clover::module by deserializing 
> the
> binary code using the module::deserialize function declared in module.cpp.
> This function expects the binary code to use a specific format, the code that
> is output from Clang/LLVM is not in the expected format which is probably why
> this is crashing for you.
>
> I don't think this format is documented anywhere, but you should
> be able to deduce it by looking through the code in core/module.cpp.
> The challenge is to get Clang/LLVM to produce code in the correct format.
>
> I think the correct way to do this would be to add a new triple,
> something like r600-clover-unknown, and then have the code emitter
> produce clover formatted code when it is passed this triple.  However,
> I would recommend not worrying about the triple for now and just change
> the code emitter to emit clover's format.  Once this is working, then
> we can go back and add the new triple.
>
> Once LLVM is producing the correct format, you will need to find a way
> for clover to communicate to the drivers that the code being
> passed is binary and not whatever its preferred IR is.  One way to do
> this is to add the
>
> enum pipe_shader_ir ir_type;
>
> field to struct pipe_compute_state and use this to tell the drivers what
> kind of IR it has.  You will also need to add the PIPE_SHADER_IR_BINARY
> type to enum pipe_hsader_ir.
>
> Then you will need to implement support for PIPE_SHADER_IR_BINARY in r600g.
> The code for doing this is already their you will just need to add a code
> path which skips over all of the LLVM compilation stages.
>
> Hopefully, this will help get you started.
>

Hi Tom,

I'm not sure if this makes sense to me.  Ideally programs created from
source code and from binary would share the same driver path.  If
there's a way to invoke clang that gets us a native GPU binary in the
clover::module format we should always invoke it that way -- also when
the program is specified using clCreateProgramWithSource().  If we want
to stick to the two-stage compilation approach r600g uses now with a
half-baked LLVM representation, we should expect the input of
clCreateProgramFromBinary() to be in the same format.  Mixing two
program representations depending on the way the program is created
sounds like a recipe for headache to me...

Albert, have you tried creating your binary using a CL client that calls
clBuildProgram() and then extracts the generated code with
clGetProgramInfo(CL_PROGRAM_BINARIES)?  That's the only portable way to
generate a binary for a given CL device, invoking clang manually is not
-- and as you've already realized it's not supposed to work right now.

Thanks.

> When it comes to generating a binary from clang and llvm.  Here is the clang
> invocation I use:
>
> clang -o test.o -target r600-unknown-unknown -mcpu=redwood -integrated-as -c 
> test.cl
>
> Note that this will work only if you uses non-vector types and don't
> use any builtin functions.  To cover all use cases you can use the attached
> shell script to compile the code.
>
> -Tom
>
>> I don't have access to IRC at work (at least I doubt I do) due to firewalls 
>> - but I can use the mailing list.
>> 
>> I wasn't entirely sure about the proper clang command line, so I wrote 
>> another program which does the online compile, then saves the output away.
>> I think I can produce an appropriate binary now.
>> 
>> I am currently using a Radeon 6670; so I assume it will be: -mcpu=turks
>> 
>> It looks like the LLVM output from clang is identical with either 
>> -mcpu=turks or -mcpu=r600.
>> I can't seem to make clang output a binary file. (I figure I'm not using 
>> clang correctly)
>> Since I can capture the binary with another C program (I think) I'm not too 
>> worried about using clang/llvm directly yet.
>> 
>
>
>
>
>> Thanks!
>> -Al
>>  
>> -Original Message-
>> From: Tom Stellard [mailto:t...@stellard.net] 
>> Sent: Monday, January 13, 2014 1:12 PM
>> To: Dorrington, Albert
>> Cc: mesa-dev@lists.freedesktop.org
>> Subject: EXTERNAL: Re: [Mesa-dev] OpenCL Clang/Clover Offline Compilation 
>> issue
>> 
>> On Thu, Jan 09, 2014 at 12:49:51PM +, Dorrington, Albert wrote:
>> > I am not sure if this is the appropriate list on which to ask this 
>> > question, if not hopefully someone can suggest an alternative.
>> > 
>> > Under Linux, I am attempting to 

[Mesa-dev] [PATCH] configure: Enable large file support for the 32-bit platforms

[Lauri Kasanen]

32-bit use is on the increase due to Steam; avoid any surprises
and make Mesa LFS-aware.

CC: "10.0" 
Signed-off-by: Lauri Kasanen 
---
 configure.ac | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure.ac b/configure.ac
index 4da6c51..f9a4154 100644
--- a/configure.ac
+++ b/configure.ac
@@ -50,6 +50,7 @@ AC_CHECK_PROGS([PYTHON2], [python2 python])
 AX_PYTHON_MODULE([libxml2], [needed])
 AC_PROG_SED
 AC_PROG_MKDIR_P
+AC_SYS_LARGEFILE
 
 LT_PREREQ([2.2])
 LT_INIT([disable-static])
-- 
1.8.3.1

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

Re: [Mesa-dev] [wip 1/9] glsl: memory_writer helper class for data serialization

[Tapani Pälli]

On 01/13/2014 08:27 PM, Paul Berry wrote:
On 2 January 2014 03:58, Tapani Pälli > wrote:


Class will be used by the shader binary cache implementation.

Signed-off-by: Tapani Pälli mailto:tapani.pa...@intel.com>>
---
 src/glsl/memory_writer.h | 147
+++
 1 file changed, 147 insertions(+)
 create mode 100644 src/glsl/memory_writer.h

diff --git a/src/glsl/memory_writer.h b/src/glsl/memory_writer.h
new file mode 100644
index 000..a6c6b55
--- /dev/null
+++ b/src/glsl/memory_writer.h
@@ -0,0 +1,147 @@
+/* -*- c++ -*- */
+/*
+ * Copyright © 2013 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.
+ */
+
+#pragma once
+#ifndef MEMORY_WRITER_H
+#define MEMORY_WRITER_H
+
+#include 
+#include 
+#include 
+
+#ifdef __cplusplus
+/**
+ * Helper class for writing data to memory
+ *
+ * This class maintains a dynamically-sized memory buffer and allows
+ * for data to be efficiently appended to it with automatic resizing.
+ */
+class memory_writer
+{
+public:
+   memory_writer() :
+  memory(NULL),
+  curr_size(0),
+  pos(0) {}
+
+   ~memory_writer()
+   {
+  free(memory);
+   }
+
+   /* user wants to claim the memory */
+   char *release_memory(size_t *size)
+   {
+  /* final realloc to free allocated but unused memory */
+  char *result = (char *) realloc(memory, pos);
+  *size = pos;
+  memory = NULL;
+  curr_size = 0;
+  pos = 0;
+  return result;
+   }
+
+/**
+ * write functions per type
+ */
+#define DECL_WRITER(type) int write_ ##type (const type data) {\
+   return write(&data, sizeof(type));\
+}
+
+   DECL_WRITER(int32_t);
+   DECL_WRITER(int64_t);
+   DECL_WRITER(uint8_t);
+   DECL_WRITER(uint32_t);
+
+   int write_bool(bool data)
+   {
+  uint8_t val = data;
+  return write_uint8_t(val);
+   }
+
+   /* write function that reallocates more memory if required */
+   int write(const void *data, int32_t size)
+   {
+  if (!memory || pos > (int32_t)(curr_size - size))
+ if (grow(size))
+return -1;
+
+  memcpy(memory + pos, data, size);
+
+  pos += size;
+  return 0;
+   }
+
+   int overwrite(const void *data, int32_t size, int32_t offset)
+   {
+  if (offset < 0 || offset + size > pos)
+ return -1;
+  memcpy(memory + offset, data, size);
+  return 0;
+   }
+
+   int write_string(const char *str)
+   {
+  if (!str)
+ return -1;
+  char terminator = '\0';
+  write(str, strlen(str));
+  write(&terminator, 1);


C strings include a terminator, so there's no reason to write out the 
string contents and the terminator separtely.  You can just do:


write(str, strlen(str) + 1);

Also, don't forget to propagate the return code to the caller:

return write(str, strlen(str) + 1);


Ah right, will do. It could be that this needs to be modified back to 
how it was though (to write to length of the string too). I think it is 
otherwise impossible for the reader side to know if terminator really 
exists and it might continue to read forever (or call strlen for 
unterminated string).



+  return 0;
+   }
+
+   inline int32_t position() { return pos; }
+
+
+private:
+
+   /* reallocate more memory */
+   int grow(int32_t size)
+   {
+  int32_t new_size = 2 

Re: [Mesa-dev] [PATCH] nouveau: add framebuffer validation callback

[Francisco Jerez]

Ilia Mirkin  writes:

> Fixes assertions when trying to attach textures to fbs with formats not
> supported by the render engines.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=73459
>
> Signed-off-by: Ilia Mirkin 
> ---

Hi Ilia,

>
> In a perfect world I'd have separate callbacks for depth and color, but given
> the list of supported values, I don't think this matters. Also I used
> st_validate_framebuffer as a template, but I don't know if there can actually
> be many attachments. Should MaxColorAttachments be set to 1? I think it's set
> to 8 right now.
>
Yes, we should probably set that to one, and that will make the loop in
your nouveau_framebuffer_validate() code unnecessary.

> And there's also an odd nouveau_validate_framebuffer thing in
> nouveau_context.c, but I think that's related to actually
> rendering/invalidating the fb displayed to the screen.
>
That's called before any rendering happens to check if we need to renew
any of the render buffers, e.g. in case the window was resized or
SwapBuffers() was called.  It's rather unfortunate that the name of your
new function is just a permutation of the old one, how about
'nouveau_check_framebuffer_completeness'?

>  src/mesa/drivers/dri/nouveau/nouveau_driver.h |  1 +
>  src/mesa/drivers/dri/nouveau/nouveau_fbo.c| 38 
> +++
>  src/mesa/drivers/dri/nouveau/nv04_context.c   | 14 ++
>  src/mesa/drivers/dri/nouveau/nv10_context.c   | 16 +++
>  src/mesa/drivers/dri/nouveau/nv20_context.c   | 16 +++
>  5 files changed, 85 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_driver.h 
> b/src/mesa/drivers/dri/nouveau/nouveau_driver.h
> index e03b2c1..84953da 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_driver.h
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_driver.h
> @@ -60,6 +60,7 @@ struct nouveau_driver {
>struct nouveau_surface *dst,
>unsigned mask, unsigned value,
>int dx, int dy, int w, int h);
> + bool (*is_rt_format_supported)(gl_format format);
>  
>   nouveau_state_func *emit;
>   int num_emit;
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c 
> b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> index 25543e4..fba0d52 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> @@ -268,6 +268,43 @@ nouveau_finish_render_texture(struct gl_context *ctx,
>   texture_dirty(rb->TexImage->TexObject);
>  }
>  
> +static void
> +nouveau_framebuffer_validate(struct gl_context *ctx,
> +  struct gl_framebuffer *fb)
> +{
> + const struct nouveau_driver *drv = context_drv(ctx);
> + int i, count = 0;
> +
> + for (i = 0; i < ctx->Const.MaxColorAttachments; i++) {
> + struct gl_renderbuffer_attachment *rba =
> + &fb->Attachment[BUFFER_COLOR0 + i];
> + if (rba->Type == GL_NONE)
> + continue;
> +
> + count++;
> + if (rba->Type != GL_TEXTURE)
> + continue;
> +
> + if (!drv->is_rt_format_supported(
> + rba->Renderbuffer->TexImage->TexFormat))
> + goto err;
> + }
> + if (count > 1)
> + goto err;
> +
> + if (fb->Attachment[BUFFER_DEPTH].Type == GL_TEXTURE) {
> + struct gl_texture_image *ti =
> + fb->Attachment[BUFFER_DEPTH].Renderbuffer->TexImage;
> + if (!drv->is_rt_format_supported(ti->TexFormat))
> + goto err;
> + }
> +
> + return;
> +err:
> + fb->_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
> + return;
> +}
> +
>  void
>  nouveau_fbo_functions_init(struct dd_function_table *functions)
>  {
> @@ -279,4 +316,5 @@ nouveau_fbo_functions_init(struct dd_function_table 
> *functions)
>   functions->FramebufferRenderbuffer = nouveau_framebuffer_renderbuffer;
>   functions->RenderTexture = nouveau_render_texture;
>   functions->FinishRenderTexture = nouveau_finish_render_texture;
> + functions->ValidateFramebuffer = nouveau_framebuffer_validate;
>  }
> diff --git a/src/mesa/drivers/dri/nouveau/nv04_context.c 
> b/src/mesa/drivers/dri/nouveau/nv04_context.c
> index c198c03..665cadd 100644
> --- a/src/mesa/drivers/dri/nouveau/nv04_context.c
> +++ b/src/mesa/drivers/dri/nouveau/nv04_context.c
> @@ -199,11 +199,25 @@ fail:
>   return NULL;
>  }
>  
> +static bool
> +nv04_is_rt_format_supported(gl_format format)
> +{
> + switch (format) {
> + case MESA_FORMAT_XRGB:
> + case MESA_FORMAT_ARGB:
> + case MESA_FORMAT_RGB565:
> + return true;
> + default:
> + return false;
> + }
> +}
> +

You're missing the depth/stencil formats here.  nv04 is kind of annoying
because the depth and color buffers have to be of the same bpp, so if
the color buffer is 32bpp we should only acce

Re: [Mesa-dev] [wip 2/9] glsl: serialize methods for IR instructions

[Tapani Pälli]

On 01/13/2014 11:58 PM, Paul Berry wrote:
On 2 January 2014 03:58, Tapani Pälli > wrote:


diff --git a/src/glsl/ir_serialize.cpp b/src/glsl/ir_serialize.cpp
new file mode 100644
index 000..30ca018
--- /dev/null
+++ b/src/glsl/ir_serialize.cpp
@@ -0,0 +1,392 @@
+/* -*- c++ -*- */
+/*
+ * Copyright © 2013 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 "ir_serialize.h"
+
+
+/**
+ * Wraps serialization of an ir instruction, writes ir_type
+ * and length of each instruction package as a header for it
+ */
+void
+ir_instruction::serialize(memory_writer &mem)
+{
+   uint32_t data_len = 0;
+   uint8_t ir_type = this->ir_type;
+   mem.write_uint8_t(ir_type);
+
+   int32_t start_pos = mem.position();
+   mem.write_uint32_t(data_len);
+
+   this->serialize_data(mem);
+
+   data_len = mem.position() - start_pos - sizeof(data_len);
+   mem.overwrite(&data_len, sizeof(data_len), start_pos);


This function isn't checking the return values from mem.write_*(), so 
there's no way for it to detect failure.  Also, since this function 
returns void, there's no way for it to notify the caller of failure.  
A similar comment applies to all of the other serialize*() functions 
in this patch.  (Of course, considering our previous discussion about 
potentially removing these int return values, this issue may be moot).


I left error checking away from serialization but I left it there in the 
memory_writer class to be available if some other possible user would 
want it but it can be removed.



+}
+
+
+
+
+static void
+serialize_glsl_type(const glsl_type *type, memory_writer &mem)


The last time I reviewed this series, I mentioned the idea of making a 
hashtable that maps each glsl_type to a small integer, so that we 
could serialize each type just once (see 
http://lists.freedesktop.org/archives/mesa-dev/2013-November/047740.html). 
At the time, it sounded like you liked that idea.  Have you made that 
change?  It looks to me like you've stopped serializing the built-in 
types, but user-defined types are still serialized each time they occur.




I liked the idea but I did not manage to come up with a good solution to 
iterate through builtin types at that time except hardcoding. One 
possible way would be to extend glsl_symbol_table so that one could 
iterate through types and come up with method to recognize that type is 
a builtin type, I will try to get it working from there. Currently only 
samplers are skipped, I took the check against name away as you 
mentioned that interfaces might have same exact name but different content.




With those two issues addressed, the patch is:

Reviewed-by: Paul Berry >


// Tapani

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

Re: [Mesa-dev] [wip 3/9] glsl: memory_map helper class for data deserialization

[Tapani Pälli]

On 01/14/2014 12:30 AM, Paul Berry wrote:
On 2 January 2014 03:58, Tapani Pälli > wrote:


Class will be used by the shader binary cache implementation.

Signed-off-by: Tapani Pälli mailto:tapani.pa...@intel.com>>
---
 src/glsl/memory_map.h | 174
++
 1 file changed, 174 insertions(+)
 create mode 100644 src/glsl/memory_map.h

diff --git a/src/glsl/memory_map.h b/src/glsl/memory_map.h
+   /* read from disk */
+   int map(const char *path)
+   {
+  struct stat stat_info;
+  if (stat(path, &stat_info) != 0)
+ return -1;


As before, I'm not thrilled with the use of -1 to mean failure and 0 
to mean success, because it forces the caller to use counterintuitive 
if statements.  I'd prefer for map() to return a bool with true 
meaning success and false meaning failure.


OK, I will change to use bool. All the 'read from disk' part can be 
actually removed as the extension does not require it. I've been using 
this patch for 2 different sets so it was left unintentionally. It can 
be added if/when Mesa wants to read the files directly itself.



+
+  mode = memory_map::READ_MAP;
+  cache_size = stat_info.st_size;
+
+  fd = open(path, O_RDONLY);
+  if (fd) {
+ cache_mmap_p = cache_mmap = (char *)
+mmap(NULL, cache_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ return (cache_mmap == MAP_FAILED) ? -1 : 0;


MAP_FAILED is a nonzero value, so if this error condition ever occurs, 
the destructor will errneously try to call munmap().


What I'd recommend doing instead is:

void *mmap_result = mmap(...);
if (mmap_result == MAP_FAILED) {
   close(fd);
   return -1;
}
cache_mmap_p = cache_mmap = (char *) mmap_result;
return 0;


I will fix this to another branch that implements 'automatic cache' and 
maps from disk. It seems I can actually close the fd right away as 
closing it won't unmap the region.



+  }
+  return -1;
+   }
+
+   /* read from memory */
+   int map(const void *memory, size_t size)
+   {
+  cache_mmap_p = cache_mmap = (char *) memory;
+  cache_size = size;
+  return 0;
+   }


IMHO, functions that cannot fail should return void.


will fix


+
+   /* wrap a portion from another map */
+   int map(memory_map &map, size_t size)
+   {
+  cache_mmap_p = cache_mmap = map.cache_mmap_p;
+  cache_size = size;
+  map.ffwd(size);
+  return 0;
+   }
+
+   inline char *read_string()
+   {
+  char *str = ralloc_strdup(mem_ctx, cache_mmap_p);
+  ffwd(strlen(str)+1);
+  return str;


This is problematic from a security perspective.  If the client 
provides corrupted data that ends in a truncated string (lacking a 
null terminator) that could cause ralloc_strdup() to try to read 
beyond the end of the file.  We need to make sure the code doesn't try 
to read beyond the end of file, even if the data is corrupted or 
truncated.


My recommendation would be:

- Have a boolean in the memory_map class to tell whether an error has 
occurred.
- If we ever try to read beyond the end of the file, set the boolean 
and return ralloc_strdup("").
- At the end of deserialization, check the boolean to see if an error 
occurred.


I've done this now to other reads, but read_string is problematic. I 
think safest approach would be that writer actually writes the length 
there so that reader does not need to make guesses how long string could 
be and if it is terminated or not?



+   }
+
+/**
+ * read functions per type
+ */
+#define DECL_READER(type) type read_ ##type () {\
+   ffwd(sizeof(type));\
+   return *(type *) (cache_mmap_p - sizeof(type));\


This is a similar security issue if the input is truncated.  If 
cache_mmap_p points beyond the end of the file after the call to 
ffwd(), we should set the error boolean and return 0.


Agreed, this is now fixed.


+}
+
+   DECL_READER(int32_t);
+   DECL_READER(int64_t);
+   DECL_READER(uint8_t);
+   DECL_READER(uint32_t);
+
+   inline uint8_t read_bool()
+   {
+  return read_uint8_t();
+   }
+
+   inline void read(void *dst, size_t size)
+   {
+  memcpy(dst, cache_mmap_p, size);
+  ffwd(size);


Similar security issue here.


Fixed also, thanks for pointing these out!


+   }
+
+   /* total size of mapped memory */
+   inline int32_t size()
+   {
+  return cache_size;
+   }
+
+private:
+
+   void *mem_ctx;
+
+   /* specifies if we are reading mapped memory or user passed mem */
+   enum read_mode {
+  READ_MEM = 0,
+  READ_MAP
+   };
+
+   int32_t mode;
+   int32_t fd;
+   int32_t cache_size;
+   char *cache_mm

Re: [Mesa-dev] Naming everything in src/gallium/drivers/radeonsi si_*

[Christian König]

Am 13.01.2014 22:00, schrieb Andreas Hartmetz:

I don't have an fdo account or push rights. Can somebody else push it
for me please? I've added the Reviewed-by: lines so the patches only
need to be pushed now.


You should consider registering an account if you are planning to do 
more work on mesa and/or other projects hosted at fdo.


Christian.



On Monday 13 January 2014 11:22:07 Marek Olšák wrote:

For the series:

Reviewed-by: Marek Olšák 

Feel free to push this.

Marek

On Sat, Jan 11, 2014 at 4:20 PM, Andreas Hartmetz 

wrote:

Continuing here because the threads had diverged...

I've updated the patch series under the same URL and applied all the
suggested improvements. The variable renames are still in, but at the
very end so they are trivial to omit.

On Tuesday 07 January 2014 17:27:56 Andreas Hartmetz wrote:

We have talked on IRC meanwhile:
"Everywhere" was supposed to mean file names and data structures.

I have made a patch series (git link because file renames produce huge
diffs) that renames *everything* away from r600 (and also radeonsi)
to si, where it is actually about SI. In the such modified code it is
then clear at first glance that only resources, textures and some
other low-level interface code from R600 / generic Radeon are actually
used in SI code.

The patch series is ordered by increasing controversy potential due
to destruction of git blame history, so the last parts can be omitted
if they are deemed too destructive to history. In my opinion, it is
better to have code that is readable now than code that is less
readable but with the possibility to look up how it became like that.

Michel said on IRC that he'd prefer to keep the name radeonsi_pipe.h/c,
I disagree: If the library name is to be kept, there must be a break
between radeonsi and si *somewhere*, and it is normal for library names
to not correspond to any file name in the library. The same scheme is
used in llvmpipe, llvmpipe lib / directory versus lp_* file names.

Here's the repository (branch is master):
git git://anongit.kde.org/scratch/ahartmetz/mesa.git
web http://quickgit.kde.org/?p=scratch%2Fahartmetz%2Fmesa.git

On Monday 06 January 2014 15:50:05 Marek Olšák wrote:

It sounds good, but I'd like the prefix to be si_ everywhere.

Marek

On Mon, Jan 6, 2014 at 2:47 PM, Andreas Hartmetz 

wrote:

Hello,

many of the files in radeonsi originally came from other places where
they had different names and were never renamed.
Most of them now have names that don't tell what the files are for
(r600 is not actually the first hardware supported by them, they
start
at radeonsi), and even those with radeonsi are split between
radeonsi_ and si_.
si_ is shorter than radeonsi_, but inconsistent with the directory
and
library name. I still think it's the best option, but no strong
opinion
from me. If and when the files are renamed, the next step would be
doing the same with the r600_ struct and function names.
Does that sound good? I'll send the patches shortly if so.

Cheers,
Andreas
___
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] Android build targets

[Emil Velikov]

On 14/01/14 06:19, Tom Gall wrote:
> Hi,
> 
> Been experimenting with building mesa on android specifically for ARM.
> I was curious if there is a wiki page that covers building mesa on
> android somewhere. Didn't see anything with the source or on
> mesa3d.org.
> 
Hi Tom,

The only form of documentation that I know of wrt the android build is
the one Chad shared a while back
http://lists.freedesktop.org/archives/mesa-dev/2013-October/047266.html

Hope it helps
Emil

> As a start I'm building with BOARD_GPU_DRIVERS := swrast
> 
> libGLES_mesa.so is built but I don't seem to end up with like a
> libGLESv2.so for instance from mesa which I was expecting. Guessing it
> looks like libGLES_mesa.so goes into /system/lib/egl and then mesa
> would be put into egl.conf but that's a guess on my part.
> 
> Thanks!
> 

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

Re: [Mesa-dev] [wip 6/9] glsl: ir_deserializer class for the binary shader cache

[Tapani Pälli]

On 01/14/2014 01:24 AM, Paul Berry wrote:
On 2 January 2014 03:58, Tapani Pälli > wrote:


+
+
+/**
+ * Reads header part of the binary blob. Main purpose of this
header is to
+ * validate that cached shader was produced with same Mesa driver
version.
+ */
+int
+ir_deserializer::read_header(struct gl_shader *shader)
+{
+   char *cache_magic_id = map->read_string();
+   char *driver_vendor = map->read_string();
+   char *driver_renderer = map->read_string();
+
+   /* only used or debug output, silence compiler warning */
+   (void) driver_vendor;
+   (void) driver_renderer;


A single version of Mesa potentially supports many different hardware 
types, and those different hardware types may define different values 
of GLSL built-in constants.  They also may require core Mesa to do 
different sets of lowering passes during compilation.  So we can't 
just ignore driver_vendor and driver_renderer. We need to reject the 
binary blob if they don't match.


ok, I'll add check against this


+
+   shader->Version = map->read_uint32_t();
+   shader->Type = map->read_uint32_t();
+   shader->IsES = map->read_uint8_t();
+
+   CACHE_DEBUG("%s: version %d, type 0x%x, %s (mesa %s)\n[%s %s]\n",
+   __func__,  shader->Version, shader->Type,
+   (shader->IsES) ? "glsl es" : "desktop glsl",
+   cache_magic_id, driver_vendor, driver_renderer);
+
+   const char *magic = mesa_get_shader_cache_magic();
+
+   if (memcmp(cache_magic_id, magic, strlen(magic)))
+  return DIFFERENT_MESA_VER;


If cache_magic_id is "foobar" and magic is "foo", this will erroneusly 
consider them equal.  The correct way to do this is to use strcmp().


will fix


+  for (unsigned k = 0; k < length; k++) {
+ uint8_t row_major, interpolation, centroid;
+ int32_t location;
+ char *field_name = map->read_string();
+ fields[k].name = _mesa_strdup(field_name);
+ fields[k].type = read_glsl_type();
+ row_major = map->read_uint8_t();
+ location = map->read_int32_t();
+ interpolation = map->read_uint8_t();
+ centroid = map->read_uint8_t();
+ fields[k].row_major = row_major;
+ fields[k].location = location;
+ fields[k].interpolation = interpolation;
+ fields[k].centroid = centroid;


Another security issue: if the binary blob is corrupted, length may be 
outrageously large (e.g. 0x).  We need a way for this loop to 
bail out and exit if it tries to read past the end of the binary blob.


I've added check now for this and other such cases where we might read 
past the end that you found. Check is is memory_map and these loops will 
ask if there were errors.




+   var->state_slots = NULL;
+
+   if (var->num_state_slots > 0) {
+  var->state_slots = ralloc_array(var, ir_state_slot,
+ var->num_state_slots);


Security issue: if the shader blob is corrupted, num_state_slots could 
be outrageously large, causing this memory allocation to fail (which 
would then cause the loop below to perform illegal memory accesses).  
We should validate that num_state_slots is within a reasonable range, 
and if it isn't, abort reading the binary blob.


What is the expected reasonable range for state_slots?


+  /* used for debugging */
+  (void) ir_type;
+  (void) len;


This is a nice opportunity to do some validation and detect corrupted 
blobs.  I think we should go ahead and do that.


OK, will add validation of read ir_type against expected ir_type for all 
the rvalues.



+  /* peek type of next instruction */


"peek" implies that you're going to look at the data but not advance 
the read pointer.  But it looks like you're advancing the read pointer 
anyhow.  Which is correct, the code or the comment?


Code is correct, s/peek/switch/


+   /* fill parse state from shader header information */
+   switch (shader->Type) {
+   case GL_VERTEX_SHADER:
+  state->target = MESA_SHADER_VERTEX;
+  break;
+   case GL_FRAGMENT_SHADER:
+  state->target = MESA_SHADER_FRAGMENT;
+  break;
+   case GL_GEOMETRY_SHADER_ARB:
+  state->target = MESA_SHADER_GEOMETRY;
+  break;


There should be a default case here to handle corrupted blobs with an 
illegal type.


I'm now doing _mesa_shader_enum_to_shader_stage(shader->Type) here which 
will assert if type is illegal.


Thanks for going through this;

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

Re: [Mesa-dev] [wip 1/9] glsl: memory_writer helper class for data serialization

[Tapani Pälli]

On 01/13/2014 08:29 PM, Ian Romanick wrote:

On 01/02/2014 03:58 AM, Tapani Pälli wrote:

Class will be used by the shader binary cache implementation.

Signed-off-by: Tapani Pälli 
---
  src/glsl/memory_writer.h | 147 +++
  1 file changed, 147 insertions(+)
  create mode 100644 src/glsl/memory_writer.h

diff --git a/src/glsl/memory_writer.h b/src/glsl/memory_writer.h
new file mode 100644
index 000..a6c6b55
--- /dev/null
+++ b/src/glsl/memory_writer.h
@@ -0,0 +1,147 @@
+/* -*- c++ -*- */
+/*
+ * Copyright © 2013 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.
+ */
+
+#pragma once
+#ifndef MEMORY_WRITER_H
+#define MEMORY_WRITER_H
+
+#include 
+#include 
+#include 
+
+#ifdef __cplusplus
+/**
+ * Helper class for writing data to memory
+ *
+ * This class maintains a dynamically-sized memory buffer and allows
+ * for data to be efficiently appended to it with automatic resizing.
+ */
+class memory_writer
+{
+public:
+   memory_writer() :
+  memory(NULL),
+  curr_size(0),
+  pos(0) {}
+
+   ~memory_writer()
+   {
+  free(memory);
+   }
+
+   /* user wants to claim the memory */
+   char *release_memory(size_t *size)
+   {
+  /* final realloc to free allocated but unused memory */
+  char *result = (char *) realloc(memory, pos);
+  *size = pos;
+  memory = NULL;
+  curr_size = 0;
+  pos = 0;
+  return result;
+   }
+
+/**
+ * write functions per type
+ */
+#define DECL_WRITER(type) int write_ ##type (const type data) {\
+   return write(&data, sizeof(type));\
+}
+
+   DECL_WRITER(int32_t);
+   DECL_WRITER(int64_t);
+   DECL_WRITER(uint8_t);
+   DECL_WRITER(uint32_t);
+
+   int write_bool(bool data)

I agree with Paul's previous comments about the return values.

http://lists.freedesktop.org/archives/mesa-dev/2013-November/047740.html

It looks like the only errors tested are either memory allocation or bad
parameters.  The bad parameter checks should just be assertions.


OK, I'll remove error checking from here for now as it is not really 
used by the serialization.



+   {
+  uint8_t val = data;
+  return write_uint8_t(val);
+   }
+
+   /* write function that reallocates more memory if required */
+   int write(const void *data, int32_t size)
+   {
+  if (!memory || pos > (int32_t)(curr_size - size))
+ if (grow(size))
+return -1;
+
+  memcpy(memory + pos, data, size);
+
+  pos += size;
+  return 0;
+   }
+
+   int overwrite(const void *data, int32_t size, int32_t offset)
+   {
+  if (offset < 0 || offset + size > pos)
+ return -1;
+  memcpy(memory + offset, data, size);
+  return 0;
+   }
+
+   int write_string(const char *str)
+   {
+  if (!str)
+ return -1;
+  char terminator = '\0';
+  write(str, strlen(str));
+  write(&terminator, 1);

This should just be

   write(str, strlen(str) + 1);


fixed


+  return 0;
+   }
+
+   inline int32_t position() { return pos; }
+
+
+private:
+
+   /* reallocate more memory */
+   int grow(int32_t size)
+   {
+  int32_t new_size = 2 * (curr_size + size);
+  char *more_mem = (char *) realloc(memory, new_size);
+  if (more_mem == NULL) {
+ free(memory);
+ memory = NULL;
+ return -1;
+  } else {
+ memory = more_mem;
+ curr_size = new_size;
+ return 0;
+  }
+   }
+
+   /* allocated memory */
+   char *memory;
+
+   /* current size of the whole allocation */
+   int32_t curr_size;

Is there a reason to specifically make this int32_t instead of just int?
  Or even unsigned?


Not really, can be changed.


+
+   /* write position / size of the data written */
+   int32_t pos;
+};
+
+#endif /* ifdef __cplusplus */
+
+#endif /* MEMORY_WRITER_H */



// Tapani

___
mesa-dev mailing list
mesa-dev@lists.freede

[Mesa-dev] RFC: ARB_arrays_of_arrays work in progress

[Timothy Arceri]

Hi all,

Its still a work in progress currently just passing the compile tests
that I submitted to the piglit list [1].
Its also a bit of a mess (some patches need squashing, a number of
patches are just temp updates to support single dimension arrays for the
time being) but I thought I would request feedback from anyone that's
interested so that I can find out if I'm at least heading in the right
direction at this early stage.

Anyway if anyone's interested in taking a look my latest code is here:
https://github.com/tarceri/Mesa_arrays_of_arrays/tree/rebase6

Some issues I'm aware of (aside all the missing functionality) is the
key and name generation code in glsl_types.cpp is a bit flimsy its good
enough to pass the piglit tests but I'm sure it wouldn't take much to
break it.

[1]
http://lists.freedesktop.org/archives/piglit/2014-January/008990.html


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

Re: [Mesa-dev] [PATCH 05/10] i965: Use Global GTT for Sandybridge post-sync non-zero workaround.

[Daniel Vetter]

On Mon, Jan 13, 2014 at 01:02:19PM -0800, Eric Anholt wrote:
> Kenneth Graunke  writes:
> 
> > On 01/09/2014 10:03 PM, Eric Anholt wrote:
> >> Eric Anholt  writes:
> >> 
> >>> Kenneth Graunke  writes:
> >>>
>  The kernel doesn't even set up the aliasing PPGTT on Sandybridge, so any
>  writes marked as PPGTT will likely just get dropped on the floor.
> >>>
> >>> The hardware bug is that writes not marked as GTT are still looked up in
> >>> the GTT anyway.
> >>>
> >>> The kernel does set up the PPGTT, which is how we found we needed to put
> >>> in the kernel workaround based on DOMAIN_INSTRUCTION (of binding the
> >>> target buffer to the gtt as well as the ppgtt, since the writes landed
> >>> in the wrong place)
> >>>
> >>> I don't think this patch will change anything, but it seems reasonable
> >>> if the commit message is updated.
> >> 
> >> Actually, thinking about it more, I'd rather not explicitly use global
> >> GTT, unless the function is also renamed to
> >> gen6_emit_post_sync_nonzero_workaround, since now this function on
> >> non-gen6 would reference GTT memory in its instruction, but the kernel
> >> wouldn't put anything in the GTT.
> >> 
> >> (I'd rather just leave the workaround as is, myself).
> >
> > Okay, sounds like this is unnecessary.  But...the next patch (helper
> > function for writes) causes this to use PIPE_CONTROL_GLOBAL_GTT_WRITE on
> > SNB only, and PPGTT on Gen7+.
> 
> Oh, right.  I'm fine with this as-is, then (r-b).

Hm, I didn't spot the code to set the address space bit correctly, but
unconditionally setting the ppgtt bit isn't the right thing to do.
Currently we have ppgtt (the hw mode, not the separate address spaces)
enabled on snb, ivb and hsw, but disabled on byt and bdw. There's also a
module option to override that default.

If the write actually matters you need to consult the
I915_PARAM_HAS_ALIASING_PPGTT driver param. If it is set then you should
use ppgtt as the address space selector. This will even hold for full
ppgtt (so a better name would be USES_PPGTT_FOR_EXECBUF, but abi and all
that).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Dorrington, Albert]

Hi Tom and Francisco,

When I tried to use Clang from the command line to produce binaries, all I 
could get was the LLVM IR code, so I adapted my test program to produce a 
binary using clGetProgramInfo().
(I have been following code examples in book 'OpenCL Programming Guide')

I have been stepping through the existing code in this area, using GDB, for the 
past few days, trying to get the binary to load successfully, and I have also 
stepped through the code behind clCreateProgramWithSource() -  so I have 
started getting familiar with the process that is going on.

I thought, if I generated the binary using clGetProgramInfo() after 
clBuildProgram() that the binary would be in the same format as would be needed.

So far, I have run into two main issues.
The first is, if there is only one kernel in the binary, it seems that 
clCreateProgramWithBinary() thinks there are two, due to (I think) an issue 
with the range() processing.
In the debugger I see a second pair of binary/length fields in the result map, 
and when the 'return new program()' call is made at the end of 
clCreateProgramWithBinary() I get a SegFault after the first (only) binary is 
deserialized.

So, I added a second kernel function to the CL program, and I am able to get 
through clCreateProgramWithBinary() without crashing, but quickly ran into a 
second issue.

My code currently calls in the order:
clCreateProgramWithBinary();
clBuildProgram();
clCreateKernel();

The clCreateKernel() call fails with a -46/Invalid Kernel Name; stepping 
through the debugger, I believe I can see the two loaded kernels, however I 
cannot find the names in what was loaded.

For now, I don't need Clang/LLVM to produce the binary without Mesa/Clover, I 
am fine with Mesa/Clover producing the binary.

Tom, from what you wrote below, it sounds like the clBuildProgram() 
implementation may only be expecting IR code and not a binary input?

Since getting this to function is related to my current assignment at work, I 
do have a lot of time I can spend on this task.

Thanks!
-Al

-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net] 
Sent: Tuesday, January 14, 2014 4:06 AM
To: Tom Stellard; Dorrington, Albert
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: EXTERNAL: Re: [Mesa-dev] OpenCL Clang/Clover Offline Compilation 
issue

Tom Stellard  writes:

> On Mon, Jan 13, 2014 at 06:44:15PM +, Dorrington, Albert wrote:
>> Tom,
>> 
>> Thanks for your response. I am very interested in implementing this, so any 
>> pointers you can provide would be greatly appreciated.
>
> I'm cc'ing Fransisco since he may also have some feedback.
>
> The first step is to build a clover::module object from the binary code.
> When we compile OpenCL C, we use the build_module_llvm() function in 
> llvm/invocation.cpp to do this.  This function takes LLVM IR as input 
> (stored in the LLVM:Module object) and produces a clover::module as 
> output.
>
> With clCreateProgramFromBinary() we build a clover::module by 
> deserializing the binary code using the module::deserialize function declared 
> in module.cpp.
> This function expects the binary code to use a specific format, the 
> code that is output from Clang/LLVM is not in the expected format 
> which is probably why this is crashing for you.
>
> I don't think this format is documented anywhere, but you should be 
> able to deduce it by looking through the code in core/module.cpp.
> The challenge is to get Clang/LLVM to produce code in the correct format.
>
> I think the correct way to do this would be to add a new triple, 
> something like r600-clover-unknown, and then have the code emitter 
> produce clover formatted code when it is passed this triple.  However, 
> I would recommend not worrying about the triple for now and just 
> change the code emitter to emit clover's format.  Once this is 
> working, then we can go back and add the new triple.
>
> Once LLVM is producing the correct format, you will need to find a way 
> for clover to communicate to the drivers that the code being passed is 
> binary and not whatever its preferred IR is.  One way to do this is to 
> add the
>
> enum pipe_shader_ir ir_type;
>
> field to struct pipe_compute_state and use this to tell the drivers 
> what kind of IR it has.  You will also need to add the 
> PIPE_SHADER_IR_BINARY type to enum pipe_hsader_ir.
>
> Then you will need to implement support for PIPE_SHADER_IR_BINARY in r600g.
> The code for doing this is already their you will just need to add a 
> code path which skips over all of the LLVM compilation stages.
>
> Hopefully, this will help get you started.
>

Hi Tom,

I'm not sure if this makes sense to me.  Ideally programs created from source 
code and from binary would share the same driver path.  If there's a way to 
invoke clang that gets us a native GPU binary in the clover::module format we 
should always invoke it that way -- also when the program is specified using 
clCr

Re: [Mesa-dev] [PATCH] mesa: rename MESA format names to have the same names as PIPE formats

[Marek Olšák]

On Sat, Jan 11, 2014 at 4:19 AM, Mark Mueller  wrote:
> The predominant feedback on this adventure has been to make the MESA_FORMATs
> match the PIPE, or gallium formats but every journey I've made down that
> path has been fraught with peril. There are some cases where PIPE_FORMATs
> are even more confusing then MESA_FORMATs*. Either there is something that I
> am missing, or there are things about the PIPE_FORMATS that people aren't
> aware of, so let me pull out some specific references.
>
> The first problem is that in PIPE_FORMATS there is no distinction between
> array and packed formats, and this has proven to be a big cause for format
> ambiguity that some are wanting to see addressed. One proposed solution is
> to represent array formats like (hypothetically): R8G8B8A8; and packed
> formats as RGBA_ (or vice versa) in the MESA_FORMATs and subsequently
> modifying the PIPE_FORMATs to suit. But that makes RGBA_1010102 kinda messy
> (though it could be RGBA_aaa2). So then how to handle this:
>
> So how about a poll! Isn't that the rage these days?
>
>
> Please vote on:
>
>
> 1) Should MESA_FORMAT names clearly distinguish between array and packed
> formats, yes or no?

Yes.

> 2) What is your preference for array format naming convention:
>
> a) RGBA_UNORM
>
> b) R8G8B8A8_UNORM
>
> c) RGBA_UNORM8

B or C. C is cleaner, B is used by gallium. I'll leave that decision to you.

> 3) What is your preference for packed format naming convention:
>
>a) RGBA5551_UNORM
>
>b) R5G5B5A1_UNORM

if the final answer to (2) is C, then B. Otherwise A. B is more
readable for formats like Z24S8 as opposed to ZS248.

> 4) What is your preference for naming packed formats with 10 or more bits:
>
>a) RGBA1010102_UNORM
>
>b) R10G10B10A2_UNORM
>
>c) RGBAaaa2_UNORM
>
>d) Croque-monsieur

Same as (3).

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

[Mesa-dev] [PATCH] radeonsi: use hardware scissors correctly

[Marek Olšák]

From: Marek Olšák 

Use the WINDOW and VPORT scissors for the framebuffer and scissor test,
respectively. The other two scissors are disabled (they cover the max fb size).

We actually have 16 VPORT scissors, which will map well to ARB_viewport_array.

Also, we don't need to write SC_WINDOW_OFFSET with this commit, because it's
disabled everywhere.
---
 src/gallium/drivers/radeonsi/si_state.c | 54 -
 1 file changed, 19 insertions(+), 35 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index b1cd4be..9d2712f 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -414,21 +414,15 @@ static void si_set_scissor_states(struct pipe_context 
*ctx,
 {
struct si_context *sctx = (struct si_context *)ctx;
struct si_pm4_state *pm4 = si_pm4_alloc_state(sctx);
-   uint32_t tl, br;
 
if (pm4 == NULL)
return;
 
-   tl = S_028240_TL_X(state->minx) | S_028240_TL_Y(state->miny);
-   br = S_028244_BR_X(state->maxx) | S_028244_BR_Y(state->maxy);
-   si_pm4_set_reg(pm4, R_028210_PA_SC_CLIPRECT_0_TL, tl);
-   si_pm4_set_reg(pm4, R_028214_PA_SC_CLIPRECT_0_BR, br);
-   si_pm4_set_reg(pm4, R_028218_PA_SC_CLIPRECT_1_TL, tl);
-   si_pm4_set_reg(pm4, R_02821C_PA_SC_CLIPRECT_1_BR, br);
-   si_pm4_set_reg(pm4, R_028220_PA_SC_CLIPRECT_2_TL, tl);
-   si_pm4_set_reg(pm4, R_028224_PA_SC_CLIPRECT_2_BR, br);
-   si_pm4_set_reg(pm4, R_028228_PA_SC_CLIPRECT_3_TL, tl);
-   si_pm4_set_reg(pm4, R_02822C_PA_SC_CLIPRECT_3_BR, br);
+   si_pm4_set_reg(pm4, R_028250_PA_SC_VPORT_SCISSOR_0_TL,
+  S_028250_TL_X(state->minx) | S_028250_TL_Y(state->miny) |
+  S_028250_WINDOW_OFFSET_DISABLE(1));
+   si_pm4_set_reg(pm4, R_028254_PA_SC_VPORT_SCISSOR_0_BR,
+  S_028254_BR_X(state->maxx) | S_028254_BR_Y(state->maxy));
 
si_pm4_set_state(sctx, scissor, pm4);
 }
@@ -536,7 +530,6 @@ static void *si_create_rs_state(struct pipe_context *ctx,
struct si_pm4_state *pm4 = &rs->pm4;
unsigned tmp;
unsigned prov_vtx = 1, polygon_dual_mode;
-   unsigned clip_rule;
float psize_min, psize_max;
 
if (rs == NULL) {
@@ -577,8 +570,6 @@ static void *si_create_rs_state(struct pipe_context *ctx,
S_028810_DX_RASTERIZATION_KILL(state->rasterizer_discard) |
S_028810_DX_LINEAR_ATTR_CLIP_ENA(1);
 
-   clip_rule = state->scissor ? 0x : 0x;
-
/* offset */
rs->offset_units = state->offset_units;
rs->offset_scale = state->offset_scale * 12.0f;
@@ -617,14 +608,14 @@ static void *si_create_rs_state(struct pipe_context *ctx,
si_pm4_set_reg(pm4, R_028A08_PA_SU_LINE_CNTL, S_028A08_WIDTH(tmp));
si_pm4_set_reg(pm4, R_028A48_PA_SC_MODE_CNTL_0,
   S_028A48_LINE_STIPPLE_ENABLE(state->line_stipple_enable) 
|
-  S_028A48_MSAA_ENABLE(state->multisample));
+  S_028A48_MSAA_ENABLE(state->multisample) |
+  S_028A48_VPORT_SCISSOR_ENABLE(state->scissor));
 
si_pm4_set_reg(pm4, R_028BE4_PA_SU_VTX_CNTL,
   S_028BE4_PIX_CENTER(state->half_pixel_center) |
   
S_028BE4_QUANT_MODE(V_028BE4_X_16_8_FIXED_POINT_1_256TH));
 
si_pm4_set_reg(pm4, R_028B7C_PA_SU_POLY_OFFSET_CLAMP, 
fui(state->offset_clamp));
-   si_pm4_set_reg(pm4, R_02820C_PA_SC_CLIPRECT_RULE, clip_rule);
 
return rs;
 }
@@ -2081,8 +2072,7 @@ static void si_set_framebuffer_state(struct pipe_context 
*ctx,
 {
struct si_context *sctx = (struct si_context *)ctx;
struct si_pm4_state *pm4 = si_pm4_alloc_state(sctx);
-   uint32_t tl, br;
-   int tl_x, tl_y, br_x, br_y, nr_samples, i;
+   int nr_samples, i;
 
if (pm4 == NULL)
return;
@@ -2126,22 +2116,8 @@ static void si_set_framebuffer_state(struct pipe_context 
*ctx,
assert(!(sctx->export_16bpc & ~0xff));
si_db(sctx, pm4, state);
 
-   tl_x = 0;
-   tl_y = 0;
-   br_x = state->width;
-   br_y = state->height;
-
-   tl = S_028240_TL_X(tl_x) | S_028240_TL_Y(tl_y);
-   br = S_028244_BR_X(br_x) | S_028244_BR_Y(br_y);
-
-   si_pm4_set_reg(pm4, R_028240_PA_SC_GENERIC_SCISSOR_TL, tl);
-   si_pm4_set_reg(pm4, R_028244_PA_SC_GENERIC_SCISSOR_BR, br);
-   si_pm4_set_reg(pm4, R_028250_PA_SC_VPORT_SCISSOR_0_TL, tl);
-   si_pm4_set_reg(pm4, R_028254_PA_SC_VPORT_SCISSOR_0_BR, br);
-   si_pm4_set_reg(pm4, R_028030_PA_SC_SCREEN_SCISSOR_TL, tl);
-   si_pm4_set_reg(pm4, R_028034_PA_SC_SCREEN_SCISSOR_BR, br);
-   si_pm4_set_reg(pm4, R_028204_PA_SC_WINDOW_SCISSOR_TL, tl);
-   si_pm4_set_reg(pm4, R_028208_PA_SC_WINDOW_SCISSOR_BR, br);
+   si_pm4_set_reg(pm4, R_028208_PA_SC_WINDOW_SCISSOR_BR,
+  S_028208_BR_X(state->width) 

Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Tom Stellard]

On Tue, Jan 14, 2014 at 10:05:47AM +0100, Francisco Jerez wrote:
> Tom Stellard  writes:
> 
> > On Mon, Jan 13, 2014 at 06:44:15PM +, Dorrington, Albert wrote:
> >> Tom,
> >> 
> >> Thanks for your response. I am very interested in implementing this, so 
> >> any pointers you can provide would be greatly appreciated.
> >
> > I'm cc'ing Fransisco since he may also have some feedback.
> >
> > The first step is to build a clover::module object from the binary code.
> > When we compile OpenCL C, we use the build_module_llvm() function in
> > llvm/invocation.cpp to do this.  This function takes LLVM IR as input
> > (stored in the LLVM:Module object) and produces a clover::module as
> > output.
> >
> > With clCreateProgramFromBinary() we build a clover::module by deserializing 
> > the
> > binary code using the module::deserialize function declared in module.cpp.
> > This function expects the binary code to use a specific format, the code 
> > that
> > is output from Clang/LLVM is not in the expected format which is probably 
> > why
> > this is crashing for you.
> >
> > I don't think this format is documented anywhere, but you should
> > be able to deduce it by looking through the code in core/module.cpp.
> > The challenge is to get Clang/LLVM to produce code in the correct format.
> >
> > I think the correct way to do this would be to add a new triple,
> > something like r600-clover-unknown, and then have the code emitter
> > produce clover formatted code when it is passed this triple.  However,
> > I would recommend not worrying about the triple for now and just change
> > the code emitter to emit clover's format.  Once this is working, then
> > we can go back and add the new triple.
> >
> > Once LLVM is producing the correct format, you will need to find a way
> > for clover to communicate to the drivers that the code being
> > passed is binary and not whatever its preferred IR is.  One way to do
> > this is to add the
> >
> > enum pipe_shader_ir ir_type;
> >
> > field to struct pipe_compute_state and use this to tell the drivers what
> > kind of IR it has.  You will also need to add the PIPE_SHADER_IR_BINARY
> > type to enum pipe_hsader_ir.
> >
> > Then you will need to implement support for PIPE_SHADER_IR_BINARY in r600g.
> > The code for doing this is already their you will just need to add a code
> > path which skips over all of the LLVM compilation stages.
> >
> > Hopefully, this will help get you started.
> >
> 
> Hi Tom,
> 
> I'm not sure if this makes sense to me.  Ideally programs created from
> source code and from binary would share the same driver path.  If
> there's a way to invoke clang that gets us a native GPU binary in the
> clover::module format we should always invoke it that way -- also when
> the program is specified using clCreateProgramWithSource().  If we want
> to stick to the two-stage compilation approach r600g uses now with a
> half-baked LLVM representation, we should expect the input of
> clCreateProgramFromBinary() to be in the same format.  Mixing two
> program representations depending on the way the program is created
> sounds like a recipe for headache to me...
> 

Hi Fransisco,

I never really considered this, but I think it makes sense.  Someone would
still need to modify the LLVM backend to output clover's binary format, but
once that is done, we could drop the two-stage compilation approach, and
just pass binary code directly to the driver.  I think this would actually
be easier than what I described.


> Albert, have you tried creating your binary using a CL client that calls
> clBuildProgram() and then extracts the generated code with
> clGetProgramInfo(CL_PROGRAM_BINARIES)?  That's the only portable way to
> generate a binary for a given CL device, invoking clang manually is not
> -- and as you've already realized it's not supposed to work right now.
> 

If you do it this way, the 'binary' will be LLVM bytecode.  I'm assuming you
want the actual machine code.

-Tom

> Thanks.
> 
> > When it comes to generating a binary from clang and llvm.  Here is the clang
> > invocation I use:
> >
> > clang -o test.o -target r600-unknown-unknown -mcpu=redwood -integrated-as 
> > -c test.cl
> >
> > Note that this will work only if you uses non-vector types and don't
> > use any builtin functions.  To cover all use cases you can use the attached
> > shell script to compile the code.
> >
> > -Tom
> >
> >> I don't have access to IRC at work (at least I doubt I do) due to 
> >> firewalls - but I can use the mailing list.
> >> 
> >> I wasn't entirely sure about the proper clang command line, so I wrote 
> >> another program which does the online compile, then saves the output away.
> >> I think I can produce an appropriate binary now.
> >> 
> >> I am currently using a Radeon 6670; so I assume it will be: -mcpu=turks
> >> 
> >> It looks like the LLVM output from clang is identical with either 
> >> -mcpu=turks or -mcpu=r600.
> >> I can't seem to make clang output a binary file. (I fig

Re: [Mesa-dev] [PATCH] radeonsi: use hardware scissors correctly

[Alex Deucher]

On Tue, Jan 14, 2014 at 9:16 AM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> Use the WINDOW and VPORT scissors for the framebuffer and scissor test,
> respectively. The other two scissors are disabled (they cover the max fb 
> size).
>
> We actually have 16 VPORT scissors, which will map well to ARB_viewport_array.
>
> Also, we don't need to write SC_WINDOW_OFFSET with this commit, because it's
> disabled everywhere.

Just one small comment below, otherwise:

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/drivers/radeonsi/si_state.c | 54 
> -
>  1 file changed, 19 insertions(+), 35 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
> b/src/gallium/drivers/radeonsi/si_state.c
> index b1cd4be..9d2712f 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -414,21 +414,15 @@ static void si_set_scissor_states(struct pipe_context 
> *ctx,
>  {
> struct si_context *sctx = (struct si_context *)ctx;
> struct si_pm4_state *pm4 = si_pm4_alloc_state(sctx);
> -   uint32_t tl, br;
>
> if (pm4 == NULL)
> return;
>
> -   tl = S_028240_TL_X(state->minx) | S_028240_TL_Y(state->miny);
> -   br = S_028244_BR_X(state->maxx) | S_028244_BR_Y(state->maxy);
> -   si_pm4_set_reg(pm4, R_028210_PA_SC_CLIPRECT_0_TL, tl);
> -   si_pm4_set_reg(pm4, R_028214_PA_SC_CLIPRECT_0_BR, br);
> -   si_pm4_set_reg(pm4, R_028218_PA_SC_CLIPRECT_1_TL, tl);
> -   si_pm4_set_reg(pm4, R_02821C_PA_SC_CLIPRECT_1_BR, br);
> -   si_pm4_set_reg(pm4, R_028220_PA_SC_CLIPRECT_2_TL, tl);
> -   si_pm4_set_reg(pm4, R_028224_PA_SC_CLIPRECT_2_BR, br);
> -   si_pm4_set_reg(pm4, R_028228_PA_SC_CLIPRECT_3_TL, tl);
> -   si_pm4_set_reg(pm4, R_02822C_PA_SC_CLIPRECT_3_BR, br);
> +   si_pm4_set_reg(pm4, R_028250_PA_SC_VPORT_SCISSOR_0_TL,
> +  S_028250_TL_X(state->minx) | 
> S_028250_TL_Y(state->miny) |
> +  S_028250_WINDOW_OFFSET_DISABLE(1));
> +   si_pm4_set_reg(pm4, R_028254_PA_SC_VPORT_SCISSOR_0_BR,
> +  S_028254_BR_X(state->maxx) | 
> S_028254_BR_Y(state->maxy));
>
> si_pm4_set_state(sctx, scissor, pm4);
>  }
> @@ -536,7 +530,6 @@ static void *si_create_rs_state(struct pipe_context *ctx,
> struct si_pm4_state *pm4 = &rs->pm4;
> unsigned tmp;
> unsigned prov_vtx = 1, polygon_dual_mode;
> -   unsigned clip_rule;
> float psize_min, psize_max;
>
> if (rs == NULL) {
> @@ -577,8 +570,6 @@ static void *si_create_rs_state(struct pipe_context *ctx,
> S_028810_DX_RASTERIZATION_KILL(state->rasterizer_discard) |
> S_028810_DX_LINEAR_ATTR_CLIP_ENA(1);
>
> -   clip_rule = state->scissor ? 0x : 0x;
> -
> /* offset */
> rs->offset_units = state->offset_units;
> rs->offset_scale = state->offset_scale * 12.0f;
> @@ -617,14 +608,14 @@ static void *si_create_rs_state(struct pipe_context 
> *ctx,
> si_pm4_set_reg(pm4, R_028A08_PA_SU_LINE_CNTL, S_028A08_WIDTH(tmp));
> si_pm4_set_reg(pm4, R_028A48_PA_SC_MODE_CNTL_0,
>
> S_028A48_LINE_STIPPLE_ENABLE(state->line_stipple_enable) |
> -  S_028A48_MSAA_ENABLE(state->multisample));
> +  S_028A48_MSAA_ENABLE(state->multisample) |
> +  S_028A48_VPORT_SCISSOR_ENABLE(state->scissor));
>
> si_pm4_set_reg(pm4, R_028BE4_PA_SU_VTX_CNTL,
>S_028BE4_PIX_CENTER(state->half_pixel_center) |
>
> S_028BE4_QUANT_MODE(V_028BE4_X_16_8_FIXED_POINT_1_256TH));
>
> si_pm4_set_reg(pm4, R_028B7C_PA_SU_POLY_OFFSET_CLAMP, 
> fui(state->offset_clamp));
> -   si_pm4_set_reg(pm4, R_02820C_PA_SC_CLIPRECT_RULE, clip_rule);
>
> return rs;
>  }
> @@ -2081,8 +2072,7 @@ static void si_set_framebuffer_state(struct 
> pipe_context *ctx,
>  {
> struct si_context *sctx = (struct si_context *)ctx;
> struct si_pm4_state *pm4 = si_pm4_alloc_state(sctx);
> -   uint32_t tl, br;
> -   int tl_x, tl_y, br_x, br_y, nr_samples, i;
> +   int nr_samples, i;
>
> if (pm4 == NULL)
> return;
> @@ -2126,22 +2116,8 @@ static void si_set_framebuffer_state(struct 
> pipe_context *ctx,
> assert(!(sctx->export_16bpc & ~0xff));
> si_db(sctx, pm4, state);
>
> -   tl_x = 0;
> -   tl_y = 0;
> -   br_x = state->width;
> -   br_y = state->height;
> -
> -   tl = S_028240_TL_X(tl_x) | S_028240_TL_Y(tl_y);
> -   br = S_028244_BR_X(br_x) | S_028244_BR_Y(br_y);
> -
> -   si_pm4_set_reg(pm4, R_028240_PA_SC_GENERIC_SCISSOR_TL, tl);
> -   si_pm4_set_reg(pm4, R_028244_PA_SC_GENERIC_SCISSOR_BR, br);
> -   si_pm4_set_reg(pm4, R_028250_PA_SC_VPORT_SCISSOR_0_TL, tl);
> -   si_pm4_set_reg(pm4, R_028254_PA_SC_VPORT_SCISSOR_0_BR, br);
> -   si_pm4_set_reg(pm4, R_028030_PA_SC

Re: [Mesa-dev] [PATCH] mesa: rename MESA format names to have the same names as PIPE formats

[Brian Paul]

On 01/14/2014 05:49 AM, Marek Olšák wrote:

On Sat, Jan 11, 2014 at 4:19 AM, Mark Mueller  wrote:

The predominant feedback on this adventure has been to make the MESA_FORMATs
match the PIPE, or gallium formats but every journey I've made down that
path has been fraught with peril. There are some cases where PIPE_FORMATs
are even more confusing then MESA_FORMATs*. Either there is something that I
am missing, or there are things about the PIPE_FORMATS that people aren't
aware of, so let me pull out some specific references.

The first problem is that in PIPE_FORMATS there is no distinction between
array and packed formats, and this has proven to be a big cause for format
ambiguity that some are wanting to see addressed. One proposed solution is
to represent array formats like (hypothetically): R8G8B8A8; and packed
formats as RGBA_ (or vice versa) in the MESA_FORMATs and subsequently
modifying the PIPE_FORMATs to suit. But that makes RGBA_1010102 kinda messy
(though it could be RGBA_aaa2). So then how to handle this:

So how about a poll! Isn't that the rage these days?


Please vote on:


1) Should MESA_FORMAT names clearly distinguish between array and packed
formats, yes or no?


Yes.


Agreed.





2) What is your preference for array format naming convention:

 a) RGBA_UNORM

 b) R8G8B8A8_UNORM

 c) RGBA_UNORM8


B or C. C is cleaner, B is used by gallium. I'll leave that decision to you.


I prefer C there.





3) What is your preference for packed format naming convention:

a) RGBA5551_UNORM

b) R5G5B5A1_UNORM


if the final answer to (2) is C, then B. Otherwise A. B is more
readable for formats like Z24S8 as opposed to ZS248.


I prefer B.





4) What is your preference for naming packed formats with 10 or more bits:

a) RGBA1010102_UNORM

b) R10G10B10A2_UNORM

c) RGBAaaa2_UNORM

d) Croque-monsieur


Same as (3).


B again.


-Brian

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

Re: [Mesa-dev] [PATCH] mesa: rename MESA format names to have the same names as PIPE formats

[Jose Fonseca]

- Original Message -
> The predominant feedback on this adventure has been to make the MESA_FORMATs
> match the PIPE, or gallium formats but every journey I've made down that
> path has been fraught with peril. There are some cases where PIPE_FORMATs
> are even more confusing then MESA_FORMATs*. Either there is something that I
> am missing, or there are things about the PIPE_FORMATS that people aren't
> aware of, so let me pull out some specific references.
> 
> The first problem is that in PIPE_FORMATS there is no distinction between
> array and packed formats

This is not true anymore, at least not entirely.  There are the 
PIPE_FORMAT_XYZW1234_UNORM formats:

src/gallium/include/pipe/p_format.h:#define PIPE_FORMAT_RGBA_UNORM 
PIPE_FORMAT_R8G8B8A8_UNORM
src/gallium/include/pipe/p_format.h:#define PIPE_FORMAT_RGBA_UNORM 
PIPE_FORMAT_A8B8G8R8_UNORM
[...]

and the hope to extend to other formats.

Jose



, and this has proven to be a big cause for format
> ambiguity that some are wanting to see addressed. One proposed solution is
> to represent array formats like (hypothetically): R8G8B8A8; and packed
> formats as RGBA_ (or vice versa) in the MESA_FORMATs and subsequently
> modifying the PIPE_FORMATs to suit. But that makes RGBA_1010102 kinda messy
> (though it could be RGBA_aaa2). So then how to handle this:
> 
> So how about a poll! Isn't that the rage these days?
> 
> Please vote on:
> 
> 1) Should MESA_FORMAT names clearly distinguish between array and packed
> formats, yes or no?
> 
> 2) What is your preference for array format naming convention:
> a) RGBA_UNORM
> b) R8G8B8A8_UNORM
> c) RGBA_UNORM8
> 
> 3) What is your preference for packed format naming convention:
> a) RGBA5551_UNORM
> b) R5G5B5A1_UNORM
> 
> 4) What is your preference for naming packed formats with 10 or more bits:
> a) RGBA1010102_UNORM
> b) R10G10B10A2_UNORM
> c) RGBAaaa2_UNORM
> d) Croque-monsieur
> 
> 
> Please vote just once!
> 
> Thanks,
> Mark
> 
> * code snip-it from p_format.h
> #if defined ( PIPE_ARCH_LITTLE_ENDIAN )
> #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_R8G8B8X8_UNORM
> #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
> #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
> #elif defined ( PIPE_ARCH_BIG_ENDIAN )
> #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_R8G8B8X8_UNORM
> #define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_B8G8R8X8_UNORM
> #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
> #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
> #endif
> There is more below the surface here too because the above macros aren't
> employed consistently throughout the gallium drivers as best as I can tell.
> 
> 
> 
> On Thu, Dec 26, 2013 at 7:48 PM, Mark Mueller < markkmuel...@gmail.com >
> wrote:
> 
> 
> 
> 
> 
> 
> On Thu, Dec 26, 2013 at 6:57 PM, Michel Dänzer < mic...@daenzer.net > wrote:
> 
> 
> 
> On Mit, 2013-12-25 at 20:35 -0800, Mark Mueller wrote:
> 
> > On Wed, Dec 25, 2013 at 7:25 PM, Michel Dänzer < mic...@daenzer.net >
> > wrote:
> > On Mit, 2013-12-25 at 15:19 -0800, Mark Mueller wrote:
> > > 
> > > -- Format Base Type P: Packed --
> > > MESA_FORMAT_[[component list,bit width][storage
> > type*][_]][_][storage
> > > type**]
> > > * when type differs between component
> > > ** when type applies to all components
> > > 
> > > 
> > > examples:
> > > MESA_FORMAT_R5G6B5_UNORM /*  RGGG GGGB 
> > */
> > > 
> > > MESA_FORMAT_B4G4R4X4_UNORM /*    
> > */
> > 
> > This is slightly confusing in that the PIPE_FORMATs use this
> > convention
> > for naming the components of 'array' formats, packed formats
> > use
> > BGRX (just like packed MESA_FORMATs do now). Beware that
> > not all
> > PIPE_FORMATs have been updated yet according to that
> > distinction.
> > 
> > Is this what you are suggesting then?
> > 
> > 
> > -- Format Base Type P: Packed --
> > MESA_FORMAT_[[component list][bit width per component]_[storage
> > type*]][_][storage type**]
> > * when type differs between component
> > ** when type applies to all components
> > 
> > 
> > examples:
> > MESA_FORMAT_RGB565_UNORM /*  RGGG GGGB  */
> > MESA_FORMAT_BGRX_UNORM /*     */
> > MESA_FORMAT_Z32_FLOAT_SX824_UINT
> > MESA_FORMAT_RGBA1010102_UINT
> > MESA_FORMAT_RGBE9995_FLOA

[Mesa-dev] [Bug 72926] Memory corruption (crash) in draw/draw_pt_fetch_shade_pipeline_llvm.c:435

[bugzilla-daemon]

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

--- Comment #9 from Peter Wu  ---
Created attachment 92053
  --> https://bugs.freedesktop.org/attachment.cgi?id=92053&action=edit
gdb debug session (with more details)

The address v0 is invalid according to AddressSanitizer. This looks fishy:

#2  0x70ae213f in lp_setup_draw_elements (vbr=0x6074a100,
indices=0x60521b80, nr=6) at lp_setup_vbuf.c:188
188  setup->triangle( setup,
(gdb) p i
$30 = 5
(gdb) p stride
$31 = 32
(gdb) p (ushort[64])indices[0]
$32 = {0, 0, 0, 48910, 1, 2, 4, 3, 0, 5, 3, 4, 6, 5, 4, 7, 5, 6, 8, 9, 10, 11,
9, 8, 12, 11, 8, 13, 11, 12, 14, 13, 12, 15, 13, 14, 0 }

Playing a bit with break- and watchpoints did not really enlight me. See the
GDB session, all I know now is that something wrong entered
llvm_pipeline_generic().

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

Re: [Mesa-dev] [wip 8/9] glsl: functions to serialize gl_shader and gl_shader_program

[Paul Berry]

On 2 January 2014 03:58, Tapani Pälli  wrote:

> diff --git a/src/glsl/shader_cache.cpp b/src/glsl/shader_cache.cpp
> new file mode 100644
> index 000..4b5de45
> --- /dev/null
> +++ b/src/glsl/shader_cache.cpp
> @@ -0,0 +1,489 @@
> +/* -*- c++ -*- */
> +/*
> + * Copyright © 2013 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 "main/shaderobj.h"
> +#include "main/uniforms.h"
> +#include "main/macros.h"
> +#include "program/hash_table.h"
> +#include "ir_serialize.h"
> +#include "ir_deserializer.h"
> +#include "shader_cache_magic.h"
> +
> +/**
> + * It is currently unknown if we need these to be available.
> + * There can be calls in mesa/main (like glGetAttachedShaders) that use
> + * the Shaders list.
> + */
> +const bool STORE_UNLINKED_SHADERS = false;
>

I think it really exaggerates our level of uncertainty to say that it is
"currently unknown" whether we need unlinked shaders to be available.
Speaking for myself at least, I'm quite convinced that we don't.  AFAICT,
OES_get_program_binary was purposefully architected so taht we don't need
to store the unlinked shaders.  GL has always maintained two independent
collections of state about any given program: pre-link state and post-link
state.  There's a one-way flow of information from the pre-link state to
the post-link state--once you've linked a program using glLinkShader(),
there's no way to get the unlinked information back.  This isn't a problem
for most users of GL because most people don't try to modify the pre-link
state after linking the program.  However it's perfectly permissible for
someone to create a program, attach shaders, link, and then detatch all the
shaders.  Since detatching the shaders affects pre-link state, the program
would still work after this point (since the post-link information would
not have changed since the link) but it would be impossible to query
information about the individual shaders anymore.

A similar situation exists when the client uses OES_get_attached_shaders.
glProgramBinaryOES() bypasses the pre-link state completely, and drops the
compiled binary directly into the post-link state.  From the
OES_get_program_binary spec:

Note that ProgramBinaryOES disregards any shader objects attached to the
program object, as these shader objects are used only by LinkProgram.

And later:

7. Can BindAttribLocation be called after ProgramBinaryOES to remap an
   attribute location used by the program binary?

RESOLVED: No.  BindAttribLocation only affects the result of a
subsequent
call to LinkProgram.  LinkProgram operates on the attached shader
objects
and replaces any program binary loaded prior to LinkProgram.  So there
is no
mechanism to remap an attribute location after loading a program binary.

However, an application is free to remap an attribute location prior to
retrieving the program binary.  By calling BindAttribLocation followed
by
LinkProgram, an application can remap the attribute location.  If this
is
followed by a call to GetProgramBinaryOES, the retrieved program binary
will
include the desired attribute location assignment.

So if the user creates a program and calls glProgramBinaryOES() followed by
glGetAttachedShaders(), they will see no shaders, since the pre-link state
is still in its initial configuration of having no shaders attached.

IMHO, trying to plan for the contingency case where we're wrong about this
is just going to lead to confusion and make the code hard to maintain.  I
think we should drop this const, and remove the code that would have been
executed if STORE_UNLINKED_SHADERS were true.  In the unlikely event that
it turns out we were wrong about this (or Khronos makes a change to the
spec that makes it necessary to store unlinked shaders) we can always
change the code in a fu

[Mesa-dev] [PATCH 3/3] driconf: Add Catalan translations

[Alex Henrie]

See the instructions in Makefile.am under "Adding new translations".
---
 src/mesa/drivers/dri/common/xmlpool/Makefile.am |   2 +-
 src/mesa/drivers/dri/common/xmlpool/ca.po   | 301 
 2 files changed, 302 insertions(+), 1 deletion(-)
 create mode 100644 src/mesa/drivers/dri/common/xmlpool/ca.po

diff --git a/src/mesa/drivers/dri/common/xmlpool/Makefile.am 
b/src/mesa/drivers/dri/common/xmlpool/Makefile.am
index ad7887d..0908c82 100644
--- a/src/mesa/drivers/dri/common/xmlpool/Makefile.am
+++ b/src/mesa/drivers/dri/common/xmlpool/Makefile.am
@@ -41,7 +41,7 @@
 # - info gettext
 
 # The set of supported languages. Add languages as needed.
-POS=de.po es.po nl.po fr.po sv.po
+POS=ca.po de.po es.po nl.po fr.po sv.po
 
 #
 # Don't change anything below, unless you know what you're doing.
diff --git a/src/mesa/drivers/dri/common/xmlpool/ca.po 
b/src/mesa/drivers/dri/common/xmlpool/ca.po
new file mode 100644
index 000..5bb68e6
--- /dev/null
+++ b/src/mesa/drivers/dri/common/xmlpool/ca.po
@@ -0,0 +1,301 @@
+# Language  translations for Mesa package
+# Traduccions al català del paquet «Mesa».
+# Copyright (C) 2014 MESA'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the Mesa package.
+# Alex Henrie , 2014.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: Mesa 10.1.0-devel\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2014-01-13 22:30-0700\n"
+"PO-Revision-Date: 2014-01-13 23:16-0700\n"
+"Last-Translator: Alex Henrie \n"
+"Language-Team: Catalan \n"
+"Language: ca\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: t_options.h:56
+msgid "Debugging"
+msgstr "Depuració"
+
+#: t_options.h:60
+msgid "Disable 3D acceleration"
+msgstr "Deshabilita l'acceleració 3D"
+
+#: t_options.h:65
+msgid "Show performance boxes"
+msgstr "Mostra les caixes de rendiment"
+
+#: t_options.h:70
+msgid "Enable flushing batchbuffer after each draw call"
+msgstr "Habilita el buidatge del batchbuffer després de cada trucada de dibuix"
+
+#: t_options.h:75
+msgid "Enable flushing GPU caches with each draw call"
+msgstr ""
+"Habilita el buidatge de les memòries cau de GPU amb cada trucada de dibuix"
+
+#: t_options.h:80
+msgid "Disable throttling on first batch after flush"
+msgstr "Deshabilita la regulació en el primer lot després de buidar"
+
+#: t_options.h:85
+msgid "Force GLSL extension default behavior to 'warn'"
+msgstr "Força el comportament de l'extensió GLSL a 'warn'"
+
+#: t_options.h:90
+msgid "Disable dual source blending"
+msgstr "Deshabilita la barreja de font dual"
+
+#: t_options.h:95
+msgid "Disable backslash-based line continuations in GLSL source"
+msgstr ""
+"Deshabilitar les continuacions de línia basades en barra invertida en la font 
"
+"GLSL"
+
+#: t_options.h:100
+msgid "Disable GL_ARB_shader_bit_encoding"
+msgstr "Deshabilita el GL_ARB_shader_bit_encoding"
+
+#: t_options.h:105
+msgid ""
+"Force a default GLSL version for shaders that lack an explicit #version line"
+msgstr ""
+"Força una versió GLSL per defecte en shaders que falten una línia #version "
+"explícita"
+
+#: t_options.h:115
+msgid "Image Quality"
+msgstr "Qualitat d'Imatge"
+
+#: t_options.h:128
+msgid "Texture color depth"
+msgstr "Profunditat de color de textura"
+
+#: t_options.h:129
+msgid "Prefer frame buffer color depth"
+msgstr "Prefereix profunditat de color del framebuffer"
+
+#: t_options.h:130
+msgid "Prefer 32 bits per texel"
+msgstr "Prefereix 32 bits per texel"
+
+#: t_options.h:131
+msgid "Prefer 16 bits per texel"
+msgstr "Prefereix 16 bits per texel"
+
+#: t_options.h:132
+msgid "Force 16 bits per texel"
+msgstr "Força 16 bits per texel"
+
+#: t_options.h:138
+msgid "Initial maximum value for anisotropic texture filtering"
+msgstr "Valor màxim inicial per la filtració de textura anisòtropa"
+
+#: t_options.h:143
+msgid "Forbid negative texture LOD bias"
+msgstr ""
+"Prohibeix una parcialitat negativa del Nivell de Detalle (LOD) de les "
+"textures"
+
+#: t_options.h:148
+msgid ""
+"Enable S3TC texture compression even if software support is not available"
+msgstr ""
+"Habilitar la compressió de textures S3TC encara que el suport de programari "
+"no estigui disponible"
+
+#: t_options.h:155
+msgid "Initial color reduction method"
+msgstr "Mètode inicial de reducció de color"
+
+#: t_options.h:156
+msgid "Round colors"
+msgstr "Colors arrodonits"
+
+#: t_options.h:157
+msgid "Dither colors"
+msgstr "Colors tramats"
+
+#: t_options.h:165
+msgid "Color rounding method"
+msgstr "Mètode d'arrodoniment de color"
+
+#: t_options.h:166
+msgid "Round color components downward"
+msgstr "Arrondeix els components de color a baix"
+
+#: t_options.h:167
+msgid "Round to nearest color"
+msgstr "Arrondeix al color més proper"
+
+#: t_options.h:176
+msgid "Color dithering method"
+msgstr "Mètode de tramat de color"
+
+#: t_options.h:177
+msgid "Horizontal error diffusion"
+msgstr "Difusió d'error horitzontal"
+
+#: t_options.h:178
+ms

[Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Alex Henrie]

---
 src/mesa/drivers/dri/common/xmlpool/es.po | 59 ---
 1 file changed, 30 insertions(+), 29 deletions(-)

diff --git a/src/mesa/drivers/dri/common/xmlpool/es.po 
b/src/mesa/drivers/dri/common/xmlpool/es.po
index e5b4d1a..0e30a0b 100644
--- a/src/mesa/drivers/dri/common/xmlpool/es.po
+++ b/src/mesa/drivers/dri/common/xmlpool/es.po
@@ -10,7 +10,7 @@ msgstr ""
 "Project-Id-Version: es\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2014-01-13 22:30-0700\n"
-"PO-Revision-Date: 2005-04-12 20:26+0200\n"
+"PO-Revision-Date: 2014-01-13 22:30-0700\n"
 "Last-Translator: David Rubio Miguélez \n"
 "Language-Team: Spanish \n"
 "Language: es\n"
@@ -22,11 +22,11 @@ msgstr ""
 
 #: t_options.h:56
 msgid "Debugging"
-msgstr "Depurando"
+msgstr "Depuración"
 
 #: t_options.h:60
 msgid "Disable 3D acceleration"
-msgstr "Desactivar aceleración 3D"
+msgstr "Deshabilitar aceleración 3D"
 
 #: t_options.h:65
 msgid "Show performance boxes"
@@ -34,36 +34,40 @@ msgstr "Mostrar cajas de rendimiento"
 
 #: t_options.h:70
 msgid "Enable flushing batchbuffer after each draw call"
-msgstr ""
+msgstr "Habilitar vaciado del batchbuffer después de cada llamada de dibujo"
 
 #: t_options.h:75
 msgid "Enable flushing GPU caches with each draw call"
-msgstr ""
+msgstr "Habilitar vaciado de los cachés GPU con cada llamada de dibujo"
 
 #: t_options.h:80
 msgid "Disable throttling on first batch after flush"
-msgstr ""
+msgstr "Deshabilitar regulación del primer lote después de vaciar"
 
 #: t_options.h:85
 msgid "Force GLSL extension default behavior to 'warn'"
-msgstr ""
+msgstr "Forzar comportamiento por defecto de la extensión GLSL a 'warn'"
 
 #: t_options.h:90
 msgid "Disable dual source blending"
-msgstr ""
+msgstr "Deshabilitar mezcla de fuente dual"
 
 #: t_options.h:95
 msgid "Disable backslash-based line continuations in GLSL source"
 msgstr ""
+"Deshabilitar continuaciones de línea basadas en barra inversa en la fuente "
+"GLSL"
 
 #: t_options.h:100
 msgid "Disable GL_ARB_shader_bit_encoding"
-msgstr ""
+msgstr "Deshabilitar GL_ARB_shader_bit_encoding"
 
 #: t_options.h:105
 msgid ""
 "Force a default GLSL version for shaders that lack an explicit #version line"
 msgstr ""
+"Forzar una versión GLSL por defecto en shaders que faltan una línea #version "
+"explícita"
 
 #: t_options.h:115
 msgid "Image Quality"
@@ -75,7 +79,7 @@ msgstr "Profundidad de color de textura"
 
 #: t_options.h:129
 msgid "Prefer frame buffer color depth"
-msgstr "Preferir profundidad de color del \"framebuffer\""
+msgstr "Preferir profundidad de color del framebuffer"
 
 #: t_options.h:130
 msgid "Prefer 32 bits per texel"
@@ -101,8 +105,8 @@ msgstr "Prohibir valores negativos de Nivel De Detalle 
(LOD) de texturas"
 msgid ""
 "Enable S3TC texture compression even if software support is not available"
 msgstr ""
-"Activar la compresión de texturas S3TC incluso si el soporte por software no "
-"está disponible"
+"Habilitar la compresión de texturas S3TC incluso si el soporte por software "
+"no está disponible"
 
 #: t_options.h:155
 msgid "Initial color reduction method"
@@ -150,31 +154,35 @@ msgstr "Búfer de profundidad en coma flotante"
 
 #: t_options.h:190
 msgid "A post-processing filter to cel-shade the output"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para cel-shade la salida"
 
 #: t_options.h:195
 msgid "A post-processing filter to remove the red channel"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para eliminar el canal rojo"
 
 #: t_options.h:200
 msgid "A post-processing filter to remove the green channel"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para eliminar el canal verde"
 
 #: t_options.h:205
 msgid "A post-processing filter to remove the blue channel"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para eliminar el canal azul"
 
 #: t_options.h:210
 msgid ""
 "Morphological anti-aliasing based on Jimenez\\' MLAA. 0 to disable, 8 for "
 "default quality"
 msgstr ""
+"Antialiasing morfológico basado en el MLAA de Jimenez. 0 per deshabilitar, 8 "
+"por calidad por defecto"
 
 #: t_options.h:215
 msgid ""
 "Morphological anti-aliasing based on Jimenez\\' MLAA. 0 to disable, 8 for "
 "default quality. Color version, usable with 2d GL apps"
 msgstr ""
+"Antialiasing morfológico basado en el MLAA de Jimenez. 0 per deshabilitar, 8 "
+"por calidad por defecto. Versión en color, usable con aplicaciones GL 2D"
 
 #: t_options.h:225
 msgid "Performance"
@@ -200,7 +208,7 @@ msgstr "Pasar por alto la tubería TCL"
 msgid ""
 "Bypass the TCL pipeline with state-based machine code generated on-the-fly"
 msgstr ""
-"Pasar por alto la tubería TCL con código máquina basado en estados generado "
+"Pasar por alto la tubería TCL con código máquina basado en estados, generado "
 "al vuelo"
 
 #: t_options.h:246
@@ -272,11 +280,11 @@ msgstr "Toda la memoria disponible"
 
 #: t_options.h:291
 msgid "Only card memory (if available)"
-msgstr "Sólo la memoria de la tarjeta (si disponible)"
+msgstr "Solo m

Re: [Mesa-dev] [libdrm PATCH] intel: Create a new drm_intel_bo offset64 field.

[Ben Widawsky]

On Mon, Jan 13, 2014 at 11:41:11PM -0800, Eric Anholt wrote:
> Kenneth Graunke  writes:
> 
> > The existing 'offset' field is unfortunately typed as 'unsigned long',
> > which is unfortunately only 4 bytes with a 32-bit userspace.
> >
> > Traditionally, the hardware has only supported 32-bit virtual addresses,
> > so even though the kernel uses a __u64, the value would always fit.
> >
> > However, Broadwell supports 48-bit addressing.  So with a 64-bit kernel,
> > the card virtual address may be too large to fit in the 'offset' field.
> >
> > Ideally, we would change the type of 'offset' to be a uint64_t---but
> > this would break the libdrm ABI.  Instead, we create a new 'offset64'
> > field to hold the full 64-bit value from the kernel, and store the
> > 32-bit truncation in the existing 'offset' field, for compatibility.
> >
> > Cc: Eric Anholt 
> > Cc: Daniel Vetter 
> > Cc: Ben Widawsky 
> > Signed-off-by: Kenneth Graunke 
> > ---
> >  intel/intel_bufmgr.h | 12 +---
> >  intel/intel_bufmgr_gem.c | 16 ++--
> >  2 files changed, 19 insertions(+), 9 deletions(-)
> >
> > I didn't update the bufmgr_fake stuff.  Do I need to...?
> 
> Nope.  Also, this was less patch than I was originally imagining it
> would be.  Sweet.
> 
> Reviewed-by: Eric Anholt 
> 
> Maybe some day we'll do a symbol-versioned fork of the code without all
> the compatibility insanity, and with other 4G limits fixed.  I don't
> think we have any instances of sharing drm_intel_bos across build-system
> boundaries.  Anyone want to correct me on that?

libva?

As a small correction to all the current mails - the current limit is
2G, not 4. There is a 4G patch series which won't be merged until PPGTT
is merged.

Anyway, patch is also:
Reviewed-by: Ben Widawsky 

I can review the mesa patch as well if needed - but I am not the best
person for that.

-- 
Ben Widawsky, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Error Building Mesa 10.0.1 on Windows

[Dorrington, Albert]

I'm attempting to build Mesa 10.0.1 on Windows (Win7, 64-bit) using the scons 
interface.

Currently getting the following error:
link /nologo /fixed:no /incremental:no /dll 
/out:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll 
build\windows-x86-debug\gallium\state_
trackers\wgl\wgl.lib build\windows-x86-debug\gallium\winsys\sw\gdi\ws_gdi.lib 
build\windows-x86-debug\mapi\glapi\glapi.lib build\windows-x86-debug\mes
a\mesa.lib build\windows-x86-debug\gallium\drivers\softpipe\softpipe.lib 
build\windows-x86-debug\gallium\drivers\trace\trace.lib build\windows-x86-deb
ug\gallium\drivers\rbug\rbug.lib 
build\windows-x86-debug\gallium\auxiliary\gallium.lib 
build\windows-x86-debug\glsl\glsl.lib gdi32.lib user32.lib kern
el32.lib ws2_32.lib 
/PDB:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.pdb /DEBUG 
build\windows-x86-debug\gallium\targets\libgl-gdi\libgl
_gdi.obj /def:src\gallium\state_trackers\wgl\opengl32.def
  Creating library 
build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.lib and object 
build\windows-x86-debug\gallium\targets\libgl-gdi\opengl
32.exp
mesa.lib(texparam.obj) : error LNK2019: unresolved external symbol _roundf 
referenced in function __mesa_GetTexParameteriv@12
build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll : fatal error 
LNK1120: 1 unresolved externals
scons: *** [build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll] 
Error 1120
scons: building terminated because of errors.

It seems that on Windows, there is no roundf() defined in the math libraries.
I see that there is a roundf() defined in src\gallium\auxiliary\util\u_math.h, 
but I don't see any equivalent utility library in the src\mesa section of code.

If I include the following code at the top of src\mesa\main\texparam.c, the 
code compiles on Windows, but I don't think this is necessarily the right 
solution.

static INLINE float
roundf(float x)
{
  return x > 0.0f ? floorf( x + 0.5f ) : ceilf( x - 0.5f );
}

Al Dorrington
Software Engineer Sr
Lockheed Martin, Mission Systems and Training
albert.dorring...@lmco.com / 607-751-4859

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

Re: [Mesa-dev] Error Building Mesa 10.0.1 on Windows

[Dorrington, Albert]

A little further investigation, it looks like the correct solution is to 
replace the call to roundf() with IROUND() which is defined in 
src\mesa\main\imports.h

From: mesa-dev-boun...@lists.freedesktop.org 
[mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of Dorrington, Albert
Sent: Tuesday, January 14, 2014 1:43 PM
To: mesa-dev@lists.freedesktop.org
Subject: EXTERNAL: [Mesa-dev] Error Building Mesa 10.0.1 on Windows

I'm attempting to build Mesa 10.0.1 on Windows (Win7, 64-bit) using the scons 
interface.

Currently getting the following error:
link /nologo /fixed:no /incremental:no /dll 
/out:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll 
build\windows-x86-debug\gallium\state_
trackers\wgl\wgl.lib build\windows-x86-debug\gallium\winsys\sw\gdi\ws_gdi.lib 
build\windows-x86-debug\mapi\glapi\glapi.lib build\windows-x86-debug\mes
a\mesa.lib build\windows-x86-debug\gallium\drivers\softpipe\softpipe.lib 
build\windows-x86-debug\gallium\drivers\trace\trace.lib build\windows-x86-deb
ug\gallium\drivers\rbug\rbug.lib 
build\windows-x86-debug\gallium\auxiliary\gallium.lib 
build\windows-x86-debug\glsl\glsl.lib gdi32.lib user32.lib kern
el32.lib ws2_32.lib 
/PDB:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.pdb /DEBUG 
build\windows-x86-debug\gallium\targets\libgl-gdi\libgl
_gdi.obj /def:src\gallium\state_trackers\wgl\opengl32.def
  Creating library 
build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.lib and object 
build\windows-x86-debug\gallium\targets\libgl-gdi\opengl
32.exp
mesa.lib(texparam.obj) : error LNK2019: unresolved external symbol _roundf 
referenced in function __mesa_GetTexParameteriv@12
build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll : fatal error 
LNK1120: 1 unresolved externals
scons: *** [build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll] 
Error 1120
scons: building terminated because of errors.

It seems that on Windows, there is no roundf() defined in the math libraries.
I see that there is a roundf() defined in src\gallium\auxiliary\util\u_math.h, 
but I don't see any equivalent utility library in the src\mesa section of code.

If I include the following code at the top of src\mesa\main\texparam.c, the 
code compiles on Windows, but I don't think this is necessarily the right 
solution.

static INLINE float
roundf(float x)
{
  return x > 0.0f ? floorf( x + 0.5f ) : ceilf( x - 0.5f );
}

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

Re: [Mesa-dev] [PATCH 0/40] Implement GL_ARB_viewport_array

[Ian Romanick]

On 01/11/2014 03:43 PM, Kenneth Graunke wrote:
> On 01/10/2014 05:44 PM, Ian Romanick wrote:
>> (Sent after the fact... sorry.)
>>
>> This represents a medling of GL_ARB_viewport_array code written by
>> Courtney Goeltzenleuchter (LunarG) and myself over the last couple
>> months.  It implements all of the core Mesa code for the extension and
>> enables it in the i965 driver.
>>
>> Like layered rendering, this extension depends on geometry shaders, so
>> it is currently only enabled in core profiles.  There is one bit of core
>> Mesa code that behaves differently when the extension is enabled (see
>> "mesa: Add new viewport and depth-range entry points for
>> GL_ARB_viewport_array"), so the enable flag is only set by the i965
>> driver in core profile.
>>
>> When multiple viewports, depth ranges, or scissor rectangles are updated
>> in one API call, the driver is only notified once, at the end.  There is
>> also no per-viewport "dirty" tracking.  The i965 driver has to send all
>> of the data when anything changes, so it didn't need that feature.  If
>> some other hardware could use per-viewport dirty tracking as an
>> optimization, it would be trivial to add that tracking to the
>> gl_context.  Then the driver state update (or
>> dd_function_table::Viewport) function could consult the appropriate
>> dirty bits before doing the update.
> 
> I've finished reviewing this series.  Other than what I've commented on,
> this series is:
> Reviewed-by: Kenneth Graunke 
> 
> Nice work, both of you!

Thanks.  I'll push the first 5 patches later today, and I'll get a new
series incorporating your feedback out soon.

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

[Mesa-dev] [Bug 72926] Memory corruption (crash) in draw/draw_pt_fetch_shade_pipeline_llvm.c:435

[bugzilla-daemon]

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

--- Comment #10 from Peter Wu  ---
Created attachment 92081
  --> https://bugs.freedesktop.org/attachment.cgi?id=92081&action=edit
Small test program (robot.c)

Here is a small test program that crashes with Mesa 10.0 (and master). On
startup, it immediately crashes. A heap-buffer-overflow according to ASAN.

Some notes:
- It has something to do with anti-aliasing (with GL_LINE_SMOOTH disabled, it
runs fine).
- The problem is probably related to negative vertices and clipping. If the
triangle vertex (-10,100) is changed to (-1,100), it still crashes but (0,100)
is fine.
- It is an combination of vertices, if I remove two vertices for GL_LINES, then
it won't crash.

Another hint is the following assertion failure when replacing GL_LINES by
GL_POINTS:

lp_setup_vbuf.c:112:lp_setup_unmap_vertices: Assertion
`setup->vertex_buffer_size >= (max_index+1) * setup->vertex_size' failed.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7fffefc004a5 in _debug_assert_fail (expr=expr@entry=0x701f9be0
"setup->vertex_buffer_size >= (max_index+1) * setup->vertex_size",
file=file@entry=0x701f9ba0 "lp_setup_vbuf.c", line=line@entry=112, 
function=function@entry=0x701f9d20 <__func__.15180>
"lp_setup_unmap_vertices") at util/u_debug.c:278
278   os_abort();
#0  0x7fffefc004a5 in _debug_assert_fail (expr=expr@entry=0x701f9be0
"setup->vertex_buffer_size >= (max_index+1) * setup->vertex_size",
file=file@entry=0x701f9ba0 "lp_setup_vbuf.c", line=line@entry=112, 
function=function@entry=0x701f9d20 <__func__.15180>
"lp_setup_unmap_vertices") at util/u_debug.c:278
#1  0x7fffeff5be20 in lp_setup_unmap_vertices (vbr=0x6074a100,
min_index=, max_index=) at lp_setup_vbuf.c:112
#2  0x7fffefb10aeb in vbuf_flush_vertices (vbuf=vbuf@entry=0x601e9820)
at draw/draw_pipe_vbuf.c:323
#3  0x7fffefb112a9 in vbuf_flush (stage=0x601e9820, flags=4) at
draw/draw_pipe_vbuf.c:392
#4  0x7fffefaf1ab1 in aaline_flush (stage=0x6036e4c0, flags=4) at
draw/draw_pipe_aaline.c:734
#5  0x7fffefafe27a in clip_flush (stage=0x602a0001f660, flags=4) at
draw/draw_pipe_clip.c:796
#6  0x7fffefaeb064 in draw_pipeline_flush (draw=draw@entry=0x60680001b100,
flags=flags@entry=4) at draw/draw_pipe.c:349
#7  0x7fffefad26a8 in draw_do_flush (draw=draw@entry=0x60680001b100,
flags=flags@entry=4) at draw/draw_context.c:741
#8  0x7fffefad0571 in draw_flush (draw=draw@entry=0x60680001b100) at
draw/draw_context.c:234
#9  0x7fffeff0da0a in llvmpipe_draw_vbo (pipe=0x606e0001c300,
info=0x7fffdf10) at lp_draw_arrays.c:155
#10 0x7fffefacc1e8 in cso_draw_vbo (cso=0x60640001a500,
info=info@entry=0x7fffdf10) at cso_cache/cso_context.c:1400
#11 0x7fffef7ed6bb in st_draw_vbo (ctx=, prims=, nr_prims=, ib=,
index_bounds_valid=, min_index=,
max_index=, 
tfb_vertcount=, indirect=) at
state_tracker/st_draw.c:290
#12 0x7fffef72f418 in vbo_exec_vtx_flush (exec=exec@entry=0x608800012e48,
keepUnmapped=keepUnmapped@entry=1 '\001') at vbo/vbo_exec_draw.c:399
#13 0x7fffef71c8bc in vbo_exec_FlushVertices_internal
(exec=exec@entry=0x608800012e48, unmap=unmap@entry=1 '\001') at
vbo/vbo_exec_api.c:555
#14 0x7fffef72151d in vbo_exec_FlushVertices (ctx=0x7fffe9eb1800, flags=1)
at vbo/vbo_exec_api.c:1164
#15 0x7fffef3ecdc6 in _mesa_flush (ctx=ctx@entry=0x7fffe9eb1800) at
main/context.c:1666
#16 0x7fffef3ed051 in _mesa_Flush () at main/context.c:1701
#17 0x74bf1677 in glFlush () at
../../../src/mapi/glapi/glapi_mapi_tmp.h:2968
#18 0x00400ef8 in display () at robot.c:29
#19 0x748b4ac4 in ?? () from /usr/lib/libglut.so.3
#20 0x748b8329 in fgEnumWindows () from /usr/lib/libglut.so.3
#21 0x748b507d in glutMainLoopEvent () from /usr/lib/libglut.so.3
#22 0x748b58e5 in glutMainLoop () from /usr/lib/libglut.so.3
#23 0x00401035 in main (argc=1, argv=0x7fffe468) at robot.c:57

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

[Mesa-dev] [Bug 72926] [REGRESSION, swrast] Memory-related crash with anti-aliasing enabled

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

Summary|Memory corruption (crash)   |[REGRESSION,swrast]
   |in  |Memory-related crash with
   |draw/draw_pt_fetch_shade_pi |anti-aliasing enabled
   |peline_llvm.c:435   |

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

[Mesa-dev] [Bug 73571] [clover] Add support for NULL global memory object arguments

[bugzilla-daemon]

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

--- Comment #4 from Tom Stellard  ---
(In reply to comment #3)
> Created attachment 92006 [details]
> Don't crash on NULL global mem objects
> 
> The attached patch fixes the original issue (bt in #c2), and adds prelimnary
> support for NULL global mem objects.

Can you send this patch to the mailing list and cc Francisco.  Also, in order
to fix this correctly on r600g, you will need to reserve offset 0 in the memory
pool, so that there are 0 can never be a valid pointer.

You can do this by creating a 1024 byte memory pool item and adding it to the
item list in the compute_memory_pool_init() function.  This should reserve the
space so no other items can use it.

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

Re: [Mesa-dev] Error Building Mesa 10.0.1 on Windows

[Roland Scheidegger]

This is correct. Note that on master this was introduced by commit
7e61b44dcd6175579f60d8ff2f703a6c83e33d27 (mesa: enable
GL_TEXTURE_LOD_BIAS set/get) and immediately fixed by the next commit
bba8f10598866776ae198b363b3752c2e3bbb126 (mesa: Use IROUND instead of
roundf). But only the first commit was cherry-picked to the 10.0 branch
likely because the second lacked the CC to stable.

Roland

Am 14.01.2014 19:51, schrieb Dorrington, Albert:
> A little further investigation, it looks like the correct solution is to
> replace the call to roundf() with IROUND() which is defined in
> src\mesa\main\imports.h
> 
>  
> 
> *From:*mesa-dev-boun...@lists.freedesktop.org
> [mailto:mesa-dev-boun...@lists.freedesktop.org] *On Behalf Of
> *Dorrington, Albert
> *Sent:* Tuesday, January 14, 2014 1:43 PM
> *To:* mesa-dev@lists.freedesktop.org
> *Subject:* EXTERNAL: [Mesa-dev] Error Building Mesa 10.0.1 on Windows
> 
>  
> 
> I’m attempting to build Mesa 10.0.1 on Windows (Win7, 64-bit) using the
> scons interface.
> 
>  
> 
> Currently getting the following error:
> 
> link /nologo /fixed:no /incremental:no /dll
> /out:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll
> build\windows-x86-debug\gallium\state_
> 
> trackers\wgl\wgl.lib
> build\windows-x86-debug\gallium\winsys\sw\gdi\ws_gdi.lib
> build\windows-x86-debug\mapi\glapi\glapi.lib build\windows-x86-debug\mes
> 
> a\mesa.lib build\windows-x86-debug\gallium\drivers\softpipe\softpipe.lib
> build\windows-x86-debug\gallium\drivers\trace\trace.lib
> build\windows-x86-deb
> 
> ug\gallium\drivers\rbug\rbug.lib
> build\windows-x86-debug\gallium\auxiliary\gallium.lib
> build\windows-x86-debug\glsl\glsl.lib gdi32.lib user32.lib kern
> 
> el32.lib ws2_32.lib
> /PDB:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.pdb
> /DEBUG build\windows-x86-debug\gallium\targets\libgl-gdi\libgl
> 
> _gdi.obj /def:src\gallium\state_trackers\wgl\opengl32.def
> 
>   Creating library
> build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.lib and
> object build\windows-x86-debug\gallium\targets\libgl-gdi\opengl
> 
> 32.exp
> 
> mesa.lib(texparam.obj) : error LNK2019: unresolved external symbol
> _roundf referenced in function __mesa_GetTexParameteriv@12
> 
> build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll : fatal
> error LNK1120: 1 unresolved externals
> 
> scons: ***
> [build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll] Error 1120
> 
> scons: building terminated because of errors.
> 
>  
> 
> It seems that on Windows, there is no roundf() defined in the math
> libraries.
> 
> I see that there is a roundf() defined in
> src\gallium\auxiliary\util\u_math.h, but I don’t see any equivalent
> utility library in the src\mesa section of code.
> 
>  
> 
> If I include the following code at the top of src\mesa\main\texparam.c,
> the code compiles on Windows, but I don’t think this is necessarily the
> right solution.
> 
>  
> 
> static INLINE float
> 
> roundf(float x)
> 
> {
> 
>   return x > 0.0f ? floorf( x + 0.5f ) : ceilf( x – 0.5f );
> 
> }
> 
>  
> 
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=CnywXmJzFnjKzYT%2BAtaYXJPj8VGZVHPlISbPdLHcTjE%3D%0A&s=640613901026045639975ac1bc63abdcd45f41b2b4ce96d2c871e606f848afb0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 72926] [REGRESSION, swrast] Memory-related crash with anti-aliasing enabled

[bugzilla-daemon]

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

--- Comment #11 from Roland Scheidegger  ---
(In reply to comment #10)
> Here is a small test program that crashes with Mesa 10.0 (and master). On
> startup, it immediately crashes. A heap-buffer-overflow according to ASAN.
> 
> Some notes:
> - It has something to do with anti-aliasing (with GL_LINE_SMOOTH disabled,
> it runs fine).
Ahh yes this makes sense, this must be due to the additional pipeline stage
draw injects for smooth lines (probably would crash with other additional
pipeline stages too, not just the one for aa lines). I suspect the interaction
with front face injection and those additional stages is just broken, as this
probably wasn't tested all that much.

> - The problem is probably related to negative vertices and clipping. If the
> triangle vertex (-10,100) is changed to (-1,100), it still crashes but
> (0,100) is fine.
> - It is an combination of vertices, if I remove two vertices for GL_LINES,
> then it won't crash.
> 
> Another hint is the following assertion failure when replacing GL_LINES by
> GL_POINTS:
> 
> lp_setup_vbuf.c:112:lp_setup_unmap_vertices: Assertion
> `setup->vertex_buffer_size >= (max_index+1) * setup->vertex_size' failed.

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

Re: [Mesa-dev] EXTERNAL: Re: Error Building Mesa 10.0.1 on Windows

[Dorrington, Albert]

I am still learning how to browse/use GIT; I see now that the main branch has 
the commit, but it was not brought into the 10.0 branch yet. 

Should this be tagged somehow so it isn't lost? 

-Original Message-
From: Roland Scheidegger [mailto:srol...@vmware.com] 
Sent: Tuesday, January 14, 2014 2:33 PM
To: Dorrington, Albert; mesa-dev@lists.freedesktop.org
Subject: EXTERNAL: Re: [Mesa-dev] Error Building Mesa 10.0.1 on Windows

This is correct. Note that on master this was introduced by commit
7e61b44dcd6175579f60d8ff2f703a6c83e33d27 (mesa: enable GL_TEXTURE_LOD_BIAS 
set/get) and immediately fixed by the next commit
bba8f10598866776ae198b363b3752c2e3bbb126 (mesa: Use IROUND instead of roundf). 
But only the first commit was cherry-picked to the 10.0 branch likely because 
the second lacked the CC to stable.

Roland

Am 14.01.2014 19:51, schrieb Dorrington, Albert:
> A little further investigation, it looks like the correct solution is 
> to replace the call to roundf() with IROUND() which is defined in 
> src\mesa\main\imports.h
> 
>  
> 
> *From:*mesa-dev-boun...@lists.freedesktop.org
> [mailto:mesa-dev-boun...@lists.freedesktop.org] *On Behalf Of 
> *Dorrington, Albert
> *Sent:* Tuesday, January 14, 2014 1:43 PM
> *To:* mesa-dev@lists.freedesktop.org
> *Subject:* EXTERNAL: [Mesa-dev] Error Building Mesa 10.0.1 on Windows
> 
>  
> 
> I'm attempting to build Mesa 10.0.1 on Windows (Win7, 64-bit) using 
> the scons interface.
> 
>  
> 
> Currently getting the following error:
> 
> link /nologo /fixed:no /incremental:no /dll 
> /out:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll
> build\windows-x86-debug\gallium\state_
> 
> trackers\wgl\wgl.lib
> build\windows-x86-debug\gallium\winsys\sw\gdi\ws_gdi.lib
> build\windows-x86-debug\mapi\glapi\glapi.lib 
> build\windows-x86-debug\mes
> 
> a\mesa.lib 
> build\windows-x86-debug\gallium\drivers\softpipe\softpipe.lib
> build\windows-x86-debug\gallium\drivers\trace\trace.lib
> build\windows-x86-deb
> 
> ug\gallium\drivers\rbug\rbug.lib
> build\windows-x86-debug\gallium\auxiliary\gallium.lib
> build\windows-x86-debug\glsl\glsl.lib gdi32.lib user32.lib kern
> 
> el32.lib ws2_32.lib
> /PDB:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.pdb
> /DEBUG build\windows-x86-debug\gallium\targets\libgl-gdi\libgl
> 
> _gdi.obj /def:src\gallium\state_trackers\wgl\opengl32.def
> 
>   Creating library
> build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.lib and 
> object build\windows-x86-debug\gallium\targets\libgl-gdi\opengl
> 
> 32.exp
> 
> mesa.lib(texparam.obj) : error LNK2019: unresolved external symbol 
> _roundf referenced in function __mesa_GetTexParameteriv@12
> 
> build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll : fatal 
> error LNK1120: 1 unresolved externals
> 
> scons: ***
> [build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll] Error 
> 1120
> 
> scons: building terminated because of errors.
> 
>  
> 
> It seems that on Windows, there is no roundf() defined in the math 
> libraries.
> 
> I see that there is a roundf() defined in 
> src\gallium\auxiliary\util\u_math.h, but I don't see any equivalent 
> utility library in the src\mesa section of code.
> 
>  
> 
> If I include the following code at the top of 
> src\mesa\main\texparam.c, the code compiles on Windows, but I don't 
> think this is necessarily the right solution.
> 
>  
> 
> static INLINE float
> 
> roundf(float x)
> 
> {
> 
>   return x > 0.0f ? floorf( x + 0.5f ) : ceilf( x - 0.5f );
> 
> }
> 
>  
> 
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.or
> g/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4ms
> KE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=CnywXmJzFnjKzYT%2B
> AtaYXJPj8VGZVHPlISbPdLHcTjE%3D%0A&s=640613901026045639975ac1bc63abdcd4
> 5f41b2b4ce96d2c871e606f848afb0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Bruno Jimenez]

Hi,

Just a couple of comments to the Spanish translation. Maybe
there's others messages that may be changed, but I lack
context to do so.

On Tue, 2014-01-14 at 11:25 -0700, Alex Henrie wrote:
> ---
>  src/mesa/drivers/dri/common/xmlpool/es.po | 59 
> ---
>  1 file changed, 30 insertions(+), 29 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/common/xmlpool/es.po 
> b/src/mesa/drivers/dri/common/xmlpool/es.po
> index e5b4d1a..0e30a0b 100644
> --- a/src/mesa/drivers/dri/common/xmlpool/es.po
> +++ b/src/mesa/drivers/dri/common/xmlpool/es.po
> @@ -10,7 +10,7 @@ msgstr ""
>  "Project-Id-Version: es\n"
>  "Report-Msgid-Bugs-To: \n"
>  "POT-Creation-Date: 2014-01-13 22:30-0700\n"
> -"PO-Revision-Date: 2005-04-12 20:26+0200\n"
> +"PO-Revision-Date: 2014-01-13 22:30-0700\n"
>  "Last-Translator: David Rubio Miguélez \n"
>  "Language-Team: Spanish \n"
>  "Language: es\n"
> @@ -22,11 +22,11 @@ msgstr ""
>  
>  #: t_options.h:56
>  msgid "Debugging"
> -msgstr "Depurando"
> +msgstr "Depuración"
>  
>  #: t_options.h:60
>  msgid "Disable 3D acceleration"
> -msgstr "Desactivar aceleración 3D"
> +msgstr "Deshabilitar aceleración 3D"
>  
>  #: t_options.h:65
>  msgid "Show performance boxes"
> @@ -34,36 +34,40 @@ msgstr "Mostrar cajas de rendimiento"
>  
>  #: t_options.h:70
>  msgid "Enable flushing batchbuffer after each draw call"
> -msgstr ""
> +msgstr "Habilitar vaciado del batchbuffer después de cada llamada de dibujo"
>  
>  #: t_options.h:75
>  msgid "Enable flushing GPU caches with each draw call"
> -msgstr ""
> +msgstr "Habilitar vaciado de los cachés GPU con cada llamada de dibujo"
>  
>  #: t_options.h:80
>  msgid "Disable throttling on first batch after flush"
> -msgstr ""
> +msgstr "Deshabilitar regulación del primer lote después de vaciar"
>  
>  #: t_options.h:85
>  msgid "Force GLSL extension default behavior to 'warn'"
> -msgstr ""
> +msgstr "Forzar comportamiento por defecto de la extensión GLSL a 'warn'"
>  
>  #: t_options.h:90
>  msgid "Disable dual source blending"
> -msgstr ""
> +msgstr "Deshabilitar mezcla de fuente dual"
>  
>  #: t_options.h:95
>  msgid "Disable backslash-based line continuations in GLSL source"
>  msgstr ""
> +"Deshabilitar continuaciones de línea basadas en barra inversa en la fuente "
> +"GLSL"

I'm not sure about "la fuente GLSL", even though it's the
correct translation, I think in Spanish we talk more about
"source code" and "code". So I think that "el código GLSL"
would be a better translation.

>  
>  #: t_options.h:100
>  msgid "Disable GL_ARB_shader_bit_encoding"
> -msgstr ""
> +msgstr "Deshabilitar GL_ARB_shader_bit_encoding"
>  
>  #: t_options.h:105
>  msgid ""
>  "Force a default GLSL version for shaders that lack an explicit #version 
> line"
>  msgstr ""
> +"Forzar una versión GLSL por defecto en shaders que faltan una línea 
> #version "
> +"explícita"

I think a better translation would be:
"Forzar una versión de GLSL por defecto en shaders a los que
les falta una línea #versión explícita"

>  
>  #: t_options.h:115
>  msgid "Image Quality"
> @@ -75,7 +79,7 @@ msgstr "Profundidad de color de textura"
>  
>  #: t_options.h:129
>  msgid "Prefer frame buffer color depth"
> -msgstr "Preferir profundidad de color del \"framebuffer\""
> +msgstr "Preferir profundidad de color del framebuffer"
>  
>  #: t_options.h:130
>  msgid "Prefer 32 bits per texel"
> @@ -101,8 +105,8 @@ msgstr "Prohibir valores negativos de Nivel De Detalle 
> (LOD) de texturas"
>  msgid ""
>  "Enable S3TC texture compression even if software support is not available"
>  msgstr ""
> -"Activar la compresión de texturas S3TC incluso si el soporte por software 
> no "
> -"está disponible"
> +"Habilitar la compresión de texturas S3TC incluso si el soporte por software 
> "
> +"no está disponible"
>  
>  #: t_options.h:155
>  msgid "Initial color reduction method"
> @@ -150,31 +154,35 @@ msgstr "Búfer de profundidad en coma flotante"
>  
>  #: t_options.h:190
>  msgid "A post-processing filter to cel-shade the output"
> -msgstr ""
> +msgstr "Un filtro de postprocesamiento para cel-shade la salida"
>  

I think a better translation would be:
"Un filtro de postprocesamiento para aplicar cel shading a
la salida"

>  #: t_options.h:195
>  msgid "A post-processing filter to remove the red channel"
> -msgstr ""
> +msgstr "Un filtro de postprocesamiento para eliminar el canal rojo"
>  
>  #: t_options.h:200
>  msgid "A post-processing filter to remove the green channel"
> -msgstr ""
> +msgstr "Un filtro de postprocesamiento para eliminar el canal verde"
>  
>  #: t_options.h:205
>  msgid "A post-processing filter to remove the blue channel"
> -msgstr ""
> +msgstr "Un filtro de postprocesamiento para eliminar el canal azul"
>  
>  #: t_options.h:210
>  msgid ""
>  "Morphological anti-aliasing based on Jimenez\\' MLAA. 0 to disable, 8 for "
>  "default quality"
>  msgstr ""
> +"Antialiasing morfológico basado en el MLAA de Jimenez. 0 per deshabilitar, 
> 8 "
> +"por calidad por d

[Mesa-dev] [Bug 73512] [clover] mesa.icd. should contain full path

[bugzilla-daemon]

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

Igor Gnatenko  changed:

   What|Removed |Added

  Attachment #92004|0   |1
is obsolete||

--- Comment #12 from Igor Gnatenko  ---
Created attachment 92091
  --> https://bugs.freedesktop.org/attachment.cgi?id=92091&action=edit
[PATCH] opencl: use versioned .so in mesa.icd

We must have versioned library in mesa.icd, because ICD loader would
fail if the mesa-devel package wasn't installed.

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

[Mesa-dev] [Bug 73631] New: es2tri fragment shader did not compile AMD ARUBA

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 73631
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: es2tri fragment shader did not compile AMD ARUBA
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: aaronbpa...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 10.0
 Component: Demos
   Product: Mesa

some version info:
Linux: 3.12.7
mesa: 10.0.2
ati-dri: 10.0.2
mesa-demos: 8.1.0

This is the output of es2tri:

EGL_VERSION = 1.4 (Gallium)
EGL_VENDOR = Mesa Project
EGL_EXTENSIONS = EGL_WL_bind_wayland_display EGL_KHR_image_base
EGL_KHR_image_pixmap EGL_KHR_image EGL_KHR_reusable_sync EGL_KHR_fence_sync
EGL_KHR_surfaceless_context EGL_NOK_swap_region EGL_NV_post_sub_buffer 
EGL_CLIENT_APIS = OpenGL OpenGL_ES OpenGL_ES2 
Error: fragment shader did not compile!

I know nothing of value about OpenGL, but a DDG search pointed me toward
glGetShaderInfoLog, so I tossed that in the code and got this:

0:1(14): error: no precision specified this scope for type `vec4'

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

Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Francisco Jerez]

"Dorrington, Albert"  writes:

> Hi Tom and Francisco,
>
> When I tried to use Clang from the command line to produce binaries, all I 
> could get was the LLVM IR code, so I adapted my test program to produce a 
> binary using clGetProgramInfo().
> (I have been following code examples in book 'OpenCL Programming Guide')
>
> I have been stepping through the existing code in this area, using GDB, for 
> the past few days, trying to get the binary to load successfully, and I have 
> also stepped through the code behind clCreateProgramWithSource() -  so I have 
> started getting familiar with the process that is going on.
>
> I thought, if I generated the binary using clGetProgramInfo() after 
> clBuildProgram() that the binary would be in the same format as would be 
> needed.
>
> So far, I have run into two main issues.
> The first is, if there is only one kernel in the binary, it seems that 
> clCreateProgramWithBinary() thinks there are two, due to (I think) an issue 
> with the range() processing.
> In the debugger I see a second pair of binary/length fields in the result 
> map, and when the 'return new program()' call is made at the end of 
> clCreateProgramWithBinary() I get a SegFault after the first (only) binary is 
> deserialized.
>
> So, I added a second kernel function to the CL program, and I am able to get 
> through clCreateProgramWithBinary() without crashing, but quickly ran into a 
> second issue.
>
> My code currently calls in the order:
>   clCreateProgramWithBinary();
>   clBuildProgram();
>   clCreateKernel();
>   
> The clCreateKernel() call fails with a -46/Invalid Kernel Name; stepping 
> through the debugger, I believe I can see the two loaded kernels, however I 
> cannot find the names in what was loaded.
>
> For now, I don't need Clang/LLVM to produce the binary without Mesa/Clover, I 
> am fine with Mesa/Clover producing the binary.
>

Hi Albert, can you give the attached patch a try?  It fixes a couple of
issues I've found in the clCreateProgramWithBinary path.  Let me know if
it helps.

Thanks.

> Tom, from what you wrote below, it sounds like the clBuildProgram() 
> implementation may only be expecting IR code and not a binary input?
>
> Since getting this to function is related to my current assignment at work, I 
> do have a lot of time I can spend on this task.
>
> Thanks!
> -Al
>

diff --git a/src/gallium/state_trackers/clover/api/program.cpp b/src/gallium/state_trackers/clover/api/program.cpp
index 7d060c4..6049209 100644
--- a/src/gallium/state_trackers/clover/api/program.cpp
+++ b/src/gallium/state_trackers/clover/api/program.cpp
@@ -69,7 +69,7 @@ clCreateProgramWithBinary(cl_context d_ctx, cl_uint n,
   throw error(CL_INVALID_DEVICE);
 
// Deserialize the provided binaries,
-   auto result = map(
+   std::vector> result = map(
   [](const unsigned char *p, size_t l) -> std::pair {
  if (!p || !l)
 return { CL_INVALID_VALUE, {} };
diff --git a/src/gallium/state_trackers/clover/core/module.cpp b/src/gallium/state_trackers/clover/core/module.cpp
index 040f521..3e3ad99 100644
--- a/src/gallium/state_trackers/clover/core/module.cpp
+++ b/src/gallium/state_trackers/clover/core/module.cpp
@@ -108,6 +108,9 @@ namespace {
   proc(S &s, QT &x) {
  _proc(s, x.type);
  _proc(s, x.size);
+ _proc(s, x.target_size);
+ _proc(s, x.target_align);
+ _proc(s, x.ext_type);
   }
};
 
diff --git a/src/gallium/state_trackers/clover/core/program.cpp b/src/gallium/state_trackers/clover/core/program.cpp
index 6d4a9ba..fb7e8d1 100644
--- a/src/gallium/state_trackers/clover/core/program.cpp
+++ b/src/gallium/state_trackers/clover/core/program.cpp
@@ -26,13 +26,13 @@
 using namespace clover;
 
 program::program(context &ctx, const std::string &source) :
-   ctx(ctx), _source(source) {
+   has_source(true), ctx(ctx), _source(source) {
 }
 
 program::program(context &ctx,
  const ref_vector &devs,
  const std::vector &binaries) :
-   ctx(ctx) {
+   has_source(false), ctx(ctx) {
for_each([&](device &dev, const module &bin) {
  _binaries.insert({ &dev, bin });
   },
@@ -41,23 +41,25 @@ program::program(context &ctx,
 
 void
 program::build(const ref_vector &devs, const char *opts) {
-   for (auto &dev : devs) {
-  _binaries.erase(&dev);
-  _logs.erase(&dev);
-  _opts.erase(&dev);
-
-  _opts.insert({ &dev, opts });
-
-  try {
- auto module = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
-compile_program_tgsi(_source) :
-compile_program_llvm(_source, dev.ir_format(),
- dev.ir_target(), build_opts(dev)));
- _binaries.insert({ &dev, module });
-
-  } catch (build_error &e) {
- _logs.insert({ &dev, e.what() });
- throw;
+   if (has_source) {
+  for (auto &dev : devs) {
+ _binaries.erase(&dev);
+ _logs

Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Dorrington, Albert]

Hi Francisco,

I'd be glad to try the patch out, unfortunately it was blocked by our mail 
server rules.
If you can resend the file, and set the extension to ".allow" it should get 
through our mail server fine.

Thanks!
-Al

-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net] 
Sent: Tuesday, January 14, 2014 4:18 PM
To: Dorrington, Albert; Tom Stellard
Cc: mesa-dev@lists.freedesktop.org
Subject: RE: EXTERNAL: Re: [Mesa-dev] OpenCL Clang/Clover Offline Compilation 
issue

This e-mail message contained a file attachment that was blocked per Lockheed 
Martin Corporate Information Security Requirements.  Certain file types are 
being blocked from entering Lockheed Martin in order to minimize risk to 
Corporate computing and information resources. 

If a business need exists and you must receive this file, alternate methods 
have been approved for use by Corporate Information Security for receipt and 
review of files/attachments.  For more information and options for handling 
blocked attachments, visit E-mail Attachment Security, at
http://protection.global.lmco.com/protection/isafe/topics.e-attachments.cfm

The current list of allowed attachment types is located at:  

http://protection.global.lmco.com/protection/awareness/e-msging/allowed_attachments.cfm

If additional assistance is required, please contact the Lockheed Martin 
Service Desk at 1-800-435-7063.

==
"Dorrington, Albert"  writes:

> Hi Tom and Francisco,
>
> When I tried to use Clang from the command line to produce binaries, all I 
> could get was the LLVM IR code, so I adapted my test program to produce a 
> binary using clGetProgramInfo().
> (I have been following code examples in book 'OpenCL Programming 
> Guide')
>
> I have been stepping through the existing code in this area, using GDB, for 
> the past few days, trying to get the binary to load successfully, and I have 
> also stepped through the code behind clCreateProgramWithSource() -  so I have 
> started getting familiar with the process that is going on.
>
> I thought, if I generated the binary using clGetProgramInfo() after 
> clBuildProgram() that the binary would be in the same format as would be 
> needed.
>
> So far, I have run into two main issues.
> The first is, if there is only one kernel in the binary, it seems that 
> clCreateProgramWithBinary() thinks there are two, due to (I think) an issue 
> with the range() processing.
> In the debugger I see a second pair of binary/length fields in the result 
> map, and when the 'return new program()' call is made at the end of 
> clCreateProgramWithBinary() I get a SegFault after the first (only) binary is 
> deserialized.
>
> So, I added a second kernel function to the CL program, and I am able to get 
> through clCreateProgramWithBinary() without crashing, but quickly ran into a 
> second issue.
>
> My code currently calls in the order:
>   clCreateProgramWithBinary();
>   clBuildProgram();
>   clCreateKernel();
>   
> The clCreateKernel() call fails with a -46/Invalid Kernel Name; stepping 
> through the debugger, I believe I can see the two loaded kernels, however I 
> cannot find the names in what was loaded.
>
> For now, I don't need Clang/LLVM to produce the binary without Mesa/Clover, I 
> am fine with Mesa/Clover producing the binary.
>

Hi Albert, can you give the attached patch a try?  It fixes a couple of issues 
I've found in the clCreateProgramWithBinary path.  Let me know if it helps.

Thanks.

> Tom, from what you wrote below, it sounds like the clBuildProgram() 
> implementation may only be expecting IR code and not a binary input?
>
> Since getting this to function is related to my current assignment at work, I 
> do have a lot of time I can spend on this task.
>
> Thanks!
> -Al
>

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

Re: [Mesa-dev] EXTERNAL: Re: OpenCL Clang/Clover Offline Compilation issue

[Aaron Watry]

A general FYI for anyone: The mesa-dev archive has a copy of the patch
that you can download.

http://lists.freedesktop.org/archives/mesa-dev/2014-January/051551.html

On Tue, Jan 14, 2014 at 3:29 PM, Dorrington, Albert
 wrote:
> Hi Francisco,
>
> I'd be glad to try the patch out, unfortunately it was blocked by our mail 
> server rules.
> If you can resend the file, and set the extension to ".allow" it should get 
> through our mail server fine.
>
> Thanks!
> -Al
>
> -Original Message-
> From: Francisco Jerez [mailto:curroje...@riseup.net]
> Sent: Tuesday, January 14, 2014 4:18 PM
> To: Dorrington, Albert; Tom Stellard
> Cc: mesa-dev@lists.freedesktop.org
> Subject: RE: EXTERNAL: Re: [Mesa-dev] OpenCL Clang/Clover Offline Compilation 
> issue
>
> This e-mail message contained a file attachment that was blocked per Lockheed 
> Martin Corporate Information Security Requirements.  Certain file types are 
> being blocked from entering Lockheed Martin in order to minimize risk to 
> Corporate computing and information resources.
>
> If a business need exists and you must receive this file, alternate methods 
> have been approved for use by Corporate Information Security for receipt and 
> review of files/attachments.  For more information and options for handling 
> blocked attachments, visit E-mail Attachment Security, at
> 
> http://protection.global.lmco.com/protection/isafe/topics.e-attachments.cfm
>
> The current list of allowed attachment types is located at:
> 
> http://protection.global.lmco.com/protection/awareness/e-msging/allowed_attachments.cfm
>
> If additional assistance is required, please contact the Lockheed Martin 
> Service Desk at 1-800-435-7063.
>
> ==
> "Dorrington, Albert"  writes:
>
>> Hi Tom and Francisco,
>>
>> When I tried to use Clang from the command line to produce binaries, all I 
>> could get was the LLVM IR code, so I adapted my test program to produce a 
>> binary using clGetProgramInfo().
>> (I have been following code examples in book 'OpenCL Programming
>> Guide')
>>
>> I have been stepping through the existing code in this area, using GDB, for 
>> the past few days, trying to get the binary to load successfully, and I have 
>> also stepped through the code behind clCreateProgramWithSource() -  so I 
>> have started getting familiar with the process that is going on.
>>
>> I thought, if I generated the binary using clGetProgramInfo() after 
>> clBuildProgram() that the binary would be in the same format as would be 
>> needed.
>>
>> So far, I have run into two main issues.
>> The first is, if there is only one kernel in the binary, it seems that 
>> clCreateProgramWithBinary() thinks there are two, due to (I think) an issue 
>> with the range() processing.
>> In the debugger I see a second pair of binary/length fields in the result 
>> map, and when the 'return new program()' call is made at the end of 
>> clCreateProgramWithBinary() I get a SegFault after the first (only) binary 
>> is deserialized.
>>
>> So, I added a second kernel function to the CL program, and I am able to get 
>> through clCreateProgramWithBinary() without crashing, but quickly ran into a 
>> second issue.
>>
>> My code currently calls in the order:
>>   clCreateProgramWithBinary();
>>   clBuildProgram();
>>   clCreateKernel();
>>
>> The clCreateKernel() call fails with a -46/Invalid Kernel Name; stepping 
>> through the debugger, I believe I can see the two loaded kernels, however I 
>> cannot find the names in what was loaded.
>>
>> For now, I don't need Clang/LLVM to produce the binary without Mesa/Clover, 
>> I am fine with Mesa/Clover producing the binary.
>>
>
> Hi Albert, can you give the attached patch a try?  It fixes a couple of 
> issues I've found in the clCreateProgramWithBinary path.  Let me know if it 
> helps.
>
> Thanks.
>
>> Tom, from what you wrote below, it sounds like the clBuildProgram() 
>> implementation may only be expecting IR code and not a binary input?
>>
>> Since getting this to function is related to my current assignment at work, 
>> I do have a lot of time I can spend on this task.
>>
>> Thanks!
>> -Al
>>
>
> ___
> 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] mesa: Add COMPRESSED_RGBA_S3TC_DXT1_EXT to COMPRESSED_TEXTURE_FORMATS for GLES

[Ian Romanick]

From: Ian Romanick 

The ES and desktop GL specs diverge here.  Yay!

In desktop OpenGL, the driver can perform online compression of
uncompressed texture data.  GL_NUM_COMPRESSED_TEXTURE_FORMATS and
GL_COMPRESSED_TEXTURE_FORMATS give the application a list of formats
that it could ask the driver to compress with some expectation of
quality.  The GL_ARB_texture_compression spec calls this "suitable for
general-purpose usage."  As noted above, this means
GL_COMPRESSED_RGBA_S3TC_DXT1_EXT is not included in the list.

In OpenGL ES, the driver never performs compression.
GL_NUM_COMPRESSED_TEXTURE_FORMATS and GL_COMPRESSED_TEXTURE_FORMATS give
the application a list of formats that the driver can receive from the
application.  It is the *complete* list of formats.  The
GL_EXT_texture_compression_s3tc spec says:

"New State for OpenGL ES 2.0.25 and 3.0.2 Specifications

The queries for NUM_COMPRESSED_TEXTURE_FORMATS and
COMPRESSED_TEXTURE_FORMATS include COMPRESSED_RGB_S3TC_DXT1_EXT,
COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT,
and COMPRESSED_RGBA_S3TC_DXT5_EXT."

Note that the addition is only to the OpenGL ES specification!

Signed-off-by: Ian Romanick 
See-also: 
http://lists.freedesktop.org/archives/mesa-dev/2013-October/047439.html
Cc: Marek Olšák 
Cc: Brian Paul 
Cc: "10.0" 
---
 src/mesa/main/texcompress.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
index e71d0c4..47ad306 100644
--- a/src/mesa/main/texcompress.c
+++ b/src/mesa/main/texcompress.c
@@ -263,6 +263,43 @@ _mesa_get_compressed_formats(struct gl_context *ctx, GLint 
*formats)
   else {
  n += 3;
   }
+
+  /* The ES and desktop GL specs diverge here.
+   *
+   * In desktop OpenGL, the driver can perform online compression of
+   * uncompressed texture data.  GL_NUM_COMPRESSED_TEXTURE_FORMATS and
+   * GL_COMPRESSED_TEXTURE_FORMATS give the application a list of
+   * formats that it could ask the driver to compress with some
+   * expectation of quality.  The GL_ARB_texture_compression spec
+   * calls this "suitable for general-purpose usage."  As noted
+   * above, this means GL_COMPRESSED_RGBA_S3TC_DXT1_EXT is not
+   * included in the list.
+   *
+   * In OpenGL ES, the driver never performs compression.
+   * GL_NUM_COMPRESSED_TEXTURE_FORMATS and
+   * GL_COMPRESSED_TEXTURE_FORMATS give the application a list of
+   * formats that the driver can receive from the application.  It
+   * is the *complete* list of formats.  The
+   * GL_EXT_texture_compression_s3tc spec says:
+   *
+   * "New State for OpenGL ES 2.0.25 and 3.0.2 Specifications
+   *
+   * The queries for NUM_COMPRESSED_TEXTURE_FORMATS and
+   * COMPRESSED_TEXTURE_FORMATS include
+   * COMPRESSED_RGB_S3TC_DXT1_EXT,
+   * COMPRESSED_RGBA_S3TC_DXT1_EXT,
+   * COMPRESSED_RGBA_S3TC_DXT3_EXT, and
+   * COMPRESSED_RGBA_S3TC_DXT5_EXT."
+   *
+   * Note that the addition is only to the OpenGL ES specification!
+   */
+  if (_mesa_is_gles(ctx)) {
+ if (formats) {
+formats[n++] = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT;
+ } else {
+n += 1;
+ }
+  }
}
 
/* The GL_OES_compressed_ETC1_RGB8_texture spec says:
-- 
1.8.1.4

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

[Mesa-dev] [Bug 72926] [REGRESSION, swrast] Memory-related crash with anti-aliasing enabled

[bugzilla-daemon]

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

--- Comment #12 from Brian Paul  ---
Created attachment 92096
  --> https://bugs.freedesktop.org/attachment.cgi?id=92096&action=edit
proposed fix for the bug

Can you try this patch?  It fixes your test program for me.

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

Re: [Mesa-dev] [PATCH] mesa: Add COMPRESSED_RGBA_S3TC_DXT1_EXT to COMPRESSED_TEXTURE_FORMATS for GLES

[Brian Paul]

On 01/14/2014 02:19 PM, Ian Romanick wrote:

From: Ian Romanick 

The ES and desktop GL specs diverge here.  Yay!

In desktop OpenGL, the driver can perform online compression of
uncompressed texture data.  GL_NUM_COMPRESSED_TEXTURE_FORMATS and
GL_COMPRESSED_TEXTURE_FORMATS give the application a list of formats
that it could ask the driver to compress with some expectation of
quality.  The GL_ARB_texture_compression spec calls this "suitable for
general-purpose usage."  As noted above, this means
GL_COMPRESSED_RGBA_S3TC_DXT1_EXT is not included in the list.

In OpenGL ES, the driver never performs compression.
GL_NUM_COMPRESSED_TEXTURE_FORMATS and GL_COMPRESSED_TEXTURE_FORMATS give
the application a list of formats that the driver can receive from the
application.  It is the *complete* list of formats.  The
GL_EXT_texture_compression_s3tc spec says:

 "New State for OpenGL ES 2.0.25 and 3.0.2 Specifications

 The queries for NUM_COMPRESSED_TEXTURE_FORMATS and
 COMPRESSED_TEXTURE_FORMATS include COMPRESSED_RGB_S3TC_DXT1_EXT,
 COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT,
 and COMPRESSED_RGBA_S3TC_DXT5_EXT."

Note that the addition is only to the OpenGL ES specification!

Signed-off-by: Ian Romanick 
See-also: 
http://lists.freedesktop.org/archives/mesa-dev/2013-October/047439.html
Cc: Marek Olšák 
Cc: Brian Paul 
Cc: "10.0" 
---
  src/mesa/main/texcompress.c | 37 +
  1 file changed, 37 insertions(+)

diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
index e71d0c4..47ad306 100644
--- a/src/mesa/main/texcompress.c
+++ b/src/mesa/main/texcompress.c
@@ -263,6 +263,43 @@ _mesa_get_compressed_formats(struct gl_context *ctx, GLint 
*formats)
else {
   n += 3;
}
+
+  /* The ES and desktop GL specs diverge here.
+   *
+   * In desktop OpenGL, the driver can perform online compression of
+   * uncompressed texture data.  GL_NUM_COMPRESSED_TEXTURE_FORMATS and
+   * GL_COMPRESSED_TEXTURE_FORMATS give the application a list of
+   * formats that it could ask the driver to compress with some
+   * expectation of quality.  The GL_ARB_texture_compression spec
+   * calls this "suitable for general-purpose usage."  As noted
+   * above, this means GL_COMPRESSED_RGBA_S3TC_DXT1_EXT is not
+   * included in the list.
+   *
+   * In OpenGL ES, the driver never performs compression.
+   * GL_NUM_COMPRESSED_TEXTURE_FORMATS and
+   * GL_COMPRESSED_TEXTURE_FORMATS give the application a list of
+   * formats that the driver can receive from the application.  It
+   * is the *complete* list of formats.  The
+   * GL_EXT_texture_compression_s3tc spec says:
+   *
+   * "New State for OpenGL ES 2.0.25 and 3.0.2 Specifications
+   *
+   * The queries for NUM_COMPRESSED_TEXTURE_FORMATS and
+   * COMPRESSED_TEXTURE_FORMATS include
+   * COMPRESSED_RGB_S3TC_DXT1_EXT,
+   * COMPRESSED_RGBA_S3TC_DXT1_EXT,
+   * COMPRESSED_RGBA_S3TC_DXT3_EXT, and
+   * COMPRESSED_RGBA_S3TC_DXT5_EXT."
+   *
+   * Note that the addition is only to the OpenGL ES specification!
+   */
+  if (_mesa_is_gles(ctx)) {
+ if (formats) {
+formats[n++] = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT;
+ } else {
+n += 1;
+ }
+  }
 }

 /* The GL_OES_compressed_ETC1_RGB8_texture spec says:



Reviewed-by: Brian Paul 


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

Re: [Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Alex Henrie]

2014/1/14 Bruno Jimenez 
> I'm not sure about "la fuente GLSL", even though it's the
> correct translation, I think in Spanish we talk more about
> "source code" and "code". So I think that "el código GLSL"
> would be a better translation.

Sure.

> I think a better translation would be:
> "Forzar una versión de GLSL por defecto en shaders a los que
> les falta una línea #versión explícita"

How about "Forzar una versión de GLSL por defecto en los shaders a que
les falta una línea #versión explícita"

> I think a better translation would be:
> "Un filtro de postprocesamiento para aplicar cel shading a
> la salida"

Sure.

> Here, there's an error translating "to" as "per" or "por",
> the correct translation is "para":
> "Antialiasing morfológico basado en el MLAA de Jimenez.
> 0 para deshabilitar, 8 para calidad por defecto."

Good catch.

> If "only card memory" refers to the memory of the graphics
> card, then the translation was correct. But there was
> a recent change in the spelling of "solo". So the correct
> translation would be:
> "Solo la memoria de la tarjeta (si disponible)"
> And I further change it to:
> "Solo la memoria de la tarjeta (si está disponible)"

What if you have a CrossFireX or SLI configuration? (Assuming that you
got it working with the DRI drivers.) In that case multiple graphics
cards would share memory, so "la tarjeta" would not make sense.
"memoria de tarjeta" does not say how many graphics cards there are,
so that wording covers all cases.

> Here I'd also translate it as:
> "Solo memoria GART (AGP/PCIE) (si está disponible)"

In the above translation you have "Solo la memoria" but here you have
"Solo memoria". We should either include the "la" in both or leave it
out in both.

Once you're satisfied with the Spanish translation, I'll make some
similar changes to the Catalan translation and resubmit the patch
series. The first patch of the series can be committed now; it does
not have to wait.

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

[Mesa-dev] [PATCH RFC 1/1] clover: Don't crash on NULL global buffer objects.

[Jan Vesely]

Specs say it's legal.
Fixes clones.xml gegl test.

---
Hi,

this patch is an attempt to support NULL buffer objects in clover.
It adds NULL handling to few places, and it's enough to get 'clones'
gegl test running.

The specs say: "If the argument is a buffer object, the arg_value
pointer can be NULL or point to a NULL value in which case a NULL
value will be used as the value for the argument declared as a
pointer to __global or __constant memory in the kernel."

I was considering using a special buffer instance to represent
NULL buffers but this seems more straightforward. Using 'pobj'
should take care of the latter part of the spec requirement too.

BZ: https://bugs.freedesktop.org/show_bug.cgi?id=73571#c2
ignore the first two comments I forgot I was testing some
additional patches.

Tom, I'm not sure I understand your comment. Does it mean that at
the moment it's possible that kernels receive NULL pointers
that point to valid buffers?

regards,
Jan

 src/gallium/drivers/r600/evergreen_compute.c  | 9 ++---
 src/gallium/state_trackers/clover/core/kernel.cpp | 4 ++--
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_compute.c 
b/src/gallium/drivers/r600/evergreen_compute.c
index a2db69b..f14b7c5 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -655,10 +655,13 @@ static void evergreen_set_global_binding(
 
for (int i = 0; i < n; i++)
{
-   assert(resources[i]->target == PIPE_BUFFER);
-   assert(resources[i]->bind & PIPE_BIND_GLOBAL);
+   if (resources[i]) {
+   assert(resources[i]->target == PIPE_BUFFER);
+   assert(resources[i]->bind & PIPE_BIND_GLOBAL);
 
-   *(handles[i]) = buffers[i]->chunk->start_in_dw * 4;
+   *(handles[i]) = buffers[i]->chunk->start_in_dw * 4;
+   } else
+   *(handles[i]) = NULL;
}
 
evergreen_set_rat(ctx->cs_shader_state.shader, 0, pool->bo, 0, 
pool->size_in_dw * 4);
diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp 
b/src/gallium/state_trackers/clover/core/kernel.cpp
index ac57c71..412eac4 100644
--- a/src/gallium/state_trackers/clover/core/kernel.cpp
+++ b/src/gallium/state_trackers/clover/core/kernel.cpp
@@ -331,7 +331,7 @@ kernel::global_argument::set(size_t size, const void 
*value) {
if (size != sizeof(cl_mem))
   throw error(CL_INVALID_ARG_SIZE);
 
-   buf = &obj(*(cl_mem *)value);
+   buf = pobj(value ? *(cl_mem *)value : NULL);
_set = true;
 }
 
@@ -340,7 +340,7 @@ kernel::global_argument::bind(exec_context &ctx,
   const module::argument &marg) {
align(ctx.input, marg.target_align);
ctx.g_handles.push_back(allocate(ctx.input, marg.target_size));
-   ctx.g_buffers.push_back(buf->resource(*ctx.q).pipe);
+   ctx.g_buffers.push_back(buf ? buf->resource(*ctx.q).pipe: NULL);
 }
 
 void
-- 
1.8.4.2

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

[Mesa-dev] [Bug 72926] [REGRESSION, swrast] Memory-related crash with anti-aliasing enabled

[bugzilla-daemon]

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

--- Comment #13 from Peter Wu  ---
(In reply to comment #12)
> Created attachment 92096 [details]
> proposed fix for the bug
> 
> Can you try this patch?  It fixes your test program for me.

Works great, tested it with mesa master
8c4a9f631d7438aeaf56785401891d0773792123 and on top of 10.0.2. Both versions do
not crash anymore, whatever I try for some minutes (my java program, another C
program and the attached apitrace).

I verified that 10.0.2 still crashes without the patch. Can this patch be
backported to 10.0? I have not ran piglit tests though.

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

Re: [Mesa-dev] EXTERNAL: Re: Error Building Mesa 10.0.1 on Windows

[Roland Scheidegger]

Am 14.01.2014 20:38, schrieb Dorrington, Albert:
> I am still learning how to browse/use GIT; I see now that the main branch has 
> the commit, but it was not brought into the 10.0 branch yet. 
> 
> Should this be tagged somehow so it isn't lost?
Yes, it should be nominated for the stable branches (the same ones the
first commit landed in), so it gets into the next stable branch release.
You can do that if you want (according to devinfo.html, just send a note
to mesa-sta...@lists.freedesktop.org).

Roland

> 
> -Original Message-
> From: Roland Scheidegger [mailto:srol...@vmware.com] 
> Sent: Tuesday, January 14, 2014 2:33 PM
> To: Dorrington, Albert; mesa-dev@lists.freedesktop.org
> Subject: EXTERNAL: Re: [Mesa-dev] Error Building Mesa 10.0.1 on Windows
> 
> This is correct. Note that on master this was introduced by commit
> 7e61b44dcd6175579f60d8ff2f703a6c83e33d27 (mesa: enable GL_TEXTURE_LOD_BIAS 
> set/get) and immediately fixed by the next commit
> bba8f10598866776ae198b363b3752c2e3bbb126 (mesa: Use IROUND instead of 
> roundf). But only the first commit was cherry-picked to the 10.0 branch 
> likely because the second lacked the CC to stable.
> 
> Roland
> 
> Am 14.01.2014 19:51, schrieb Dorrington, Albert:
>> A little further investigation, it looks like the correct solution is 
>> to replace the call to roundf() with IROUND() which is defined in 
>> src\mesa\main\imports.h
>>
>>  
>>
>> *From:*mesa-dev-boun...@lists.freedesktop.org
>> [mailto:mesa-dev-boun...@lists.freedesktop.org] *On Behalf Of 
>> *Dorrington, Albert
>> *Sent:* Tuesday, January 14, 2014 1:43 PM
>> *To:* mesa-dev@lists.freedesktop.org
>> *Subject:* EXTERNAL: [Mesa-dev] Error Building Mesa 10.0.1 on Windows
>>
>>  
>>
>> I'm attempting to build Mesa 10.0.1 on Windows (Win7, 64-bit) using 
>> the scons interface.
>>
>>  
>>
>> Currently getting the following error:
>>
>> link /nologo /fixed:no /incremental:no /dll 
>> /out:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll
>> build\windows-x86-debug\gallium\state_
>>
>> trackers\wgl\wgl.lib
>> build\windows-x86-debug\gallium\winsys\sw\gdi\ws_gdi.lib
>> build\windows-x86-debug\mapi\glapi\glapi.lib 
>> build\windows-x86-debug\mes
>>
>> a\mesa.lib 
>> build\windows-x86-debug\gallium\drivers\softpipe\softpipe.lib
>> build\windows-x86-debug\gallium\drivers\trace\trace.lib
>> build\windows-x86-deb
>>
>> ug\gallium\drivers\rbug\rbug.lib
>> build\windows-x86-debug\gallium\auxiliary\gallium.lib
>> build\windows-x86-debug\glsl\glsl.lib gdi32.lib user32.lib kern
>>
>> el32.lib ws2_32.lib
>> /PDB:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.pdb
>> /DEBUG build\windows-x86-debug\gallium\targets\libgl-gdi\libgl
>>
>> _gdi.obj /def:src\gallium\state_trackers\wgl\opengl32.def
>>
>>   Creating library
>> build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.lib and 
>> object build\windows-x86-debug\gallium\targets\libgl-gdi\opengl
>>
>> 32.exp
>>
>> mesa.lib(texparam.obj) : error LNK2019: unresolved external symbol 
>> _roundf referenced in function __mesa_GetTexParameteriv@12
>>
>> build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll : fatal 
>> error LNK1120: 1 unresolved externals
>>
>> scons: ***
>> [build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll] Error 
>> 1120
>>
>> scons: building terminated because of errors.
>>
>>  
>>
>> It seems that on Windows, there is no roundf() defined in the math 
>> libraries.
>>
>> I see that there is a roundf() defined in 
>> src\gallium\auxiliary\util\u_math.h, but I don't see any equivalent 
>> utility library in the src\mesa section of code.
>>
>>  
>>
>> If I include the following code at the top of 
>> src\mesa\main\texparam.c, the code compiles on Windows, but I don't 
>> think this is necessarily the right solution.
>>
>>  
>>
>> static INLINE float
>>
>> roundf(float x)
>>
>> {
>>
>>   return x > 0.0f ? floorf( x + 0.5f ) : ceilf( x - 0.5f );
>>
>> }
>>
>>  
>>
>>
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.or
>> g/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4ms
>> KE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=CnywXmJzFnjKzYT%2B
>> AtaYXJPj8VGZVHPlISbPdLHcTjE%3D%0A&s=640613901026045639975ac1bc63abdcd4
>> 5f41b2b4ce96d2c871e606f848afb0
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Bruno Jimenez]

On Tue, 2014-01-14 at 15:35 -0700, Alex Henrie wrote:
> 2014/1/14 Bruno Jimenez 
> > I'm not sure about "la fuente GLSL", even though it's the
> > correct translation, I think in Spanish we talk more about
> > "source code" and "code". So I think that "el código GLSL"
> > would be a better translation.
> 
> Sure.
> 
> > I think a better translation would be:
> > "Forzar una versión de GLSL por defecto en shaders a los que
> > les falta una línea #versión explícita"
> 
> How about "Forzar una versión de GLSL por defecto en los shaders a que
> les falta una línea #versión explícita"

I think we are still missing a "los":
"Forzar una versión de GLSL por defecto en los shaders a los
que les falta una línea #versión explícita"

> 
> > I think a better translation would be:
> > "Un filtro de postprocesamiento para aplicar cel shading a
> > la salida"
> 
> Sure.
> 
> > Here, there's an error translating "to" as "per" or "por",
> > the correct translation is "para":
> > "Antialiasing morfológico basado en el MLAA de Jimenez.
> > 0 para deshabilitar, 8 para calidad por defecto."
> 
> Good catch.
> 
> > If "only card memory" refers to the memory of the graphics
> > card, then the translation was correct. But there was
> > a recent change in the spelling of "solo". So the correct
> > translation would be:
> > "Solo la memoria de la tarjeta (si disponible)"
> > And I further change it to:
> > "Solo la memoria de la tarjeta (si está disponible)"
> 
> What if you have a CrossFireX or SLI configuration? (Assuming that you
> got it working with the DRI drivers.) In that case multiple graphics
> cards would share memory, so "la tarjeta" would not make sense.
> "memoria de tarjeta" does not say how many graphics cards there are,
> so that wording covers all cases.

You are right, I always think in terms of one card and miss this cases.
I'm ok with the translation.

> 
> > Here I'd also translate it as:
> > "Solo memoria GART (AGP/PCIE) (si está disponible)"
> 
> In the above translation you have "Solo la memoria" but here you have
> "Solo memoria". We should either include the "la" in both or leave it
> out in both.

True again. I was thinking about GART memory as something more generic
and that's why I didn't use the article "la".

> 
> Once you're satisfied with the Spanish translation, I'll make some
> similar changes to the Catalan translation and resubmit the patch
> series. The first patch of the series can be committed now; it does
> not have to wait.

I have looked at the translations, and I think I would also
change the translation for:
"Method to limit rendering latency"
to
"Método para limitar la latencia de renderizado"

> 
> -Alex

Hope it helps!
Bruno

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

Re: [Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Alex Henrie]

2014/1/14 Bruno Jimenez :
> I think we are still missing a "los":
> "Forzar una versión de GLSL por defecto en los shaders a los
> que les falta una línea #versión explícita"

If we include a second "los" then it doesn't sound right to me unless
we say "los cuales": "Forzar una versión de GLSL por defecto en los
shaders a los cuales les falta una línea #versión explícita"

> True again. I was thinking about GART memory as something more generic
> and that's why I didn't use the article "la".

So, do you want "Solo la memoria de tarjeta" and "Solo la memoria
GART" or "Solo memoria de tarjeta" and "Solo memoria GART"?

> I have looked at the translations, and I think I would also
> change the translation for:
> "Method to limit rendering latency"
> to
> "Método para limitar la latencia de renderizado"

Another good catch. But is the right term "renderizado" or "renderización"?

Thanks for the help,

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

[Mesa-dev] [PATCH v2] nouveau: add framebuffer validation callback

[Ilia Mirkin]

Fixes assertions when trying to attach textures to fbs with formats not
supported by the render engines.

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

Signed-off-by: Ilia Mirkin 
---

Francisco, thanks for the review. Is this more like what you had in mind?
Interesting that nv10/nv20 support different-bitness color/depth -- that
requirement came back for nv30/nv40.

 src/mesa/drivers/dri/nouveau/nouveau_context.c |  1 +
 src/mesa/drivers/dri/nouveau/nouveau_fbo.c | 52 ++
 2 files changed, 53 insertions(+)

diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c 
b/src/mesa/drivers/dri/nouveau/nouveau_context.c
index 181c9d0..ec474d4 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
@@ -187,6 +187,7 @@ nouveau_context_init(struct gl_context *ctx, struct 
nouveau_screen *screen,
ctx->Extensions.EXT_framebuffer_blit = true;
ctx->Extensions.EXT_texture_filter_anisotropic = true;
ctx->Extensions.NV_texture_env_combine4 = true;
+   ctx->Const.MaxColorAttachments = 1;
 
return GL_TRUE;
 }
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c 
b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
index 25543e4..427eb00 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
@@ -268,6 +268,57 @@ nouveau_finish_render_texture(struct gl_context *ctx,
texture_dirty(rb->TexImage->TexObject);
 }
 
+static int
+validate_format_bpp(gl_format format)
+{
+   switch (format) {
+   case MESA_FORMAT_XRGB:
+   case MESA_FORMAT_ARGB:
+   case MESA_FORMAT_Z24_S8:
+   return 32;
+   case MESA_FORMAT_RGB565:
+   case MESA_FORMAT_Z16:
+   return 16;
+   default:
+   return 0;
+   }
+}
+
+static void
+nouveau_check_framebuffer_complete(struct gl_context *ctx,
+  struct gl_framebuffer *fb)
+{
+   const struct nouveau_driver *drv = context_drv(ctx);
+   struct gl_renderbuffer_attachment *color =
+   &fb->Attachment[BUFFER_COLOR0];
+   struct gl_renderbuffer_attachment *depth =
+   &fb->Attachment[BUFFER_DEPTH];
+   int color_bpp = 0, zeta_bpp;
+
+   if (color->Type == GL_TEXTURE) {
+   color_bpp = validate_format_bpp(
+   color->Renderbuffer->TexImage->TexFormat);
+   if (!color_bpp)
+   goto err;
+   }
+
+   if (depth->Type == GL_TEXTURE) {
+   zeta_bpp = validate_format_bpp(
+   depth->Renderbuffer->TexImage->TexFormat);
+   if (!zeta_bpp)
+   goto err;
+   /* NV04/NV05 requires same bpp-ness for color/zeta */
+   if (context_chipset(ctx) < 0x10 &&
+   color_bpp && color_bpp != zeta_bpp)
+   goto err;
+   }
+
+   return;
+err:
+   fb->_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
+   return;
+}
+
 void
 nouveau_fbo_functions_init(struct dd_function_table *functions)
 {
@@ -279,4 +330,5 @@ nouveau_fbo_functions_init(struct dd_function_table 
*functions)
functions->FramebufferRenderbuffer = nouveau_framebuffer_renderbuffer;
functions->RenderTexture = nouveau_render_texture;
functions->FinishRenderTexture = nouveau_finish_render_texture;
+   functions->ValidateFramebuffer = nouveau_check_framebuffer_complete;
 }
-- 
1.8.3.2

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

[Mesa-dev] [PATCH] i965: Remove CACHED_BATCH support altogether.

[Eric Anholt]

From: Kenneth Graunke 

Using an unoptimized variant of glamor spending 50% of its CPU time in
brw_draw_prims() (and hitting the cache *very* frequently):

N   Min   MaxMedian   AvgStddev
x 200 29200 40500 34900 34750 958.43256
+ 200 31000 40300 34700 34622 916.35941
No difference proven at 95.0% confidence

Similarly, no difference on GLB2.7 (also with cache hits):

N   Min   MaxMedian   AvgStddev
x  63  64.1 71.36 70.69 70.113175 1.6782026
+  63  63.6 71.18 70.75 70.223651 1.6044186
No difference proven at 95.0% confidence

v2: Rebase on master (by anholt)

Signed-off-by: Kenneth Graunke 
Signed-off-by: Eric Anholt 
Reviewed-by: Eric Anholt 
---

Before sending this out, I tried writing a lower-overhead CACHED_BATCH as a
variation on the cached-batch-2 branch of my tree.  It didn't help, either.

I'm just sending it to the list in case anyone has any objection to it -- I'll
push it soon if not.

 src/mesa/drivers/dri/i965/brw_cc.c|  2 +-
 src/mesa/drivers/dri/i965/brw_curbe.c |  2 +-
 src/mesa/drivers/dri/i965/brw_draw_upload.c   |  4 +--
 src/mesa/drivers/dri/i965/brw_misc_state.c|  8 ++---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 42 ---
 src/mesa/drivers/dri/i965/intel_batchbuffer.h |  3 --
 6 files changed, 8 insertions(+), 53 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_cc.c 
b/src/mesa/drivers/dri/i965/brw_cc.c
index 4bc3b23..460dad6 100644
--- a/src/mesa/drivers/dri/i965/brw_cc.c
+++ b/src/mesa/drivers/dri/i965/brw_cc.c
@@ -247,7 +247,7 @@ static void upload_blend_constant_color(struct brw_context 
*brw)
OUT_BATCH_F(ctx->Color.BlendColorUnclamped[1]);
OUT_BATCH_F(ctx->Color.BlendColorUnclamped[2]);
OUT_BATCH_F(ctx->Color.BlendColorUnclamped[3]);
-   CACHED_BATCH();
+   ADVANCE_BATCH();
 }
 
 const struct brw_tracked_state brw_blend_constant_color = {
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c 
b/src/mesa/drivers/dri/i965/brw_curbe.c
index 5da92cc..121b0aa 100644
--- a/src/mesa/drivers/dri/i965/brw_curbe.c
+++ b/src/mesa/drivers/dri/i965/brw_curbe.c
@@ -161,7 +161,7 @@ void brw_upload_cs_urb_state(struct brw_context *brw)
   assert(brw->urb.nr_cs_entries);
   OUT_BATCH((brw->urb.csize - 1) << 4 | brw->urb.nr_cs_entries);
}
-   CACHED_BATCH();
+   ADVANCE_BATCH();
 }
 
 static GLfloat fixed_plane[6][4] = {
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c 
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index 2179a3a..aa6514d 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -643,7 +643,7 @@ static void brw_emit_vertices(struct brw_context *brw)
(BRW_VE1_COMPONENT_STORE_0 << BRW_VE1_COMPONENT_1_SHIFT) |
(BRW_VE1_COMPONENT_STORE_0 << BRW_VE1_COMPONENT_2_SHIFT) |
(BRW_VE1_COMPONENT_STORE_1_FLT << BRW_VE1_COMPONENT_3_SHIFT));
-  CACHED_BATCH();
+  ADVANCE_BATCH();
   return;
}
 
@@ -808,7 +808,7 @@ static void brw_emit_vertices(struct brw_context *brw)
   OUT_BATCH(dw1);
}
 
-   CACHED_BATCH();
+   ADVANCE_BATCH();
 }
 
 const struct brw_tracked_state brw_vertices = {
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 3c908c8..57f9926 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -778,7 +778,7 @@ static void upload_polygon_stipple(struct brw_context *brw)
   for (i = 0; i < 32; i++)
 OUT_BATCH(ctx->PolygonStipple[i]);
}
-   CACHED_BATCH();
+   ADVANCE_BATCH();
 }
 
 const struct brw_tracked_state brw_polygon_stipple = {
@@ -822,7 +822,7 @@ static void upload_polygon_stipple_offset(struct 
brw_context *brw)
   OUT_BATCH((32 - (ctx->DrawBuffer->Height & 31)) & 31);
else
   OUT_BATCH(0);
-   CACHED_BATCH();
+   ADVANCE_BATCH();
 }
 
 const struct brw_tracked_state brw_polygon_stipple_offset = {
@@ -856,7 +856,7 @@ static void upload_aa_line_parameters(struct brw_context 
*brw)
/* use legacy aa line coverage computation */
OUT_BATCH(0);
OUT_BATCH(0);
-   CACHED_BATCH();
+   ADVANCE_BATCH();
 }
 
 const struct brw_tracked_state brw_aa_line_parameters = {
@@ -901,7 +901,7 @@ static void upload_line_stipple(struct brw_context *brw)
   OUT_BATCH(tmpi << 16 | ctx->Line.StippleFactor);
}
 
-   CACHED_BATCH();
+   ADVANCE_BATCH();
 }
 
 const struct brw_tracked_state brw_line_stipple = {
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index d9b6c15..64e0298 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -432,48 +432,6 @@ intel_batchbuffer_data(struct brw_context *brw,
b

Re: [Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Bruno Jimenez]

On Tue, 2014-01-14 at 17:39 -0700, Alex Henrie wrote:
> 2014/1/14 Bruno Jimenez :
> > I think we are still missing a "los":
> > "Forzar una versión de GLSL por defecto en los shaders a los
> > que les falta una línea #versión explícita"
> 
> If we include a second "los" then it doesn't sound right to me unless
> we say "los cuales": "Forzar una versión de GLSL por defecto en los
> shaders a los cuales les falta una línea #versión explícita"

I'm ok with this translation.

> 
> > True again. I was thinking about GART memory as something more generic
> > and that's why I didn't use the article "la".
> 
> So, do you want "Solo la memoria de tarjeta" and "Solo la memoria
> GART" or "Solo memoria de tarjeta" and "Solo memoria GART"?

I think I prefer without "la", but if you prefer with, it's also ok.

> 
> > I have looked at the translations, and I think I would also
> > change the translation for:
> > "Method to limit rendering latency"
> > to
> > "Método para limitar la latencia de renderizado"
> 
> Another good catch. But is the right term "renderizado" or "renderización"?

To me, it sounds better "renderizado". As usual, RAE doesn't say
anything, and wikipedia has an entry titled "renderización" (and
"renderizado" redirected to it too), but the first word of the article
is "renderizado". Still, both are ok, so I don't really mind which one.

> 
> Thanks for the help,
> 
> -Alex

Hope it helps!
Bruno


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

Re: [Mesa-dev] [PATCH] mesa: rename MESA format names to have the same names as PIPE formats

[Michel Dänzer]

On Fre, 2014-01-10 at 19:19 -0800, Mark Mueller wrote:
> 
> 
> 1) Should MESA_FORMAT names clearly distinguish between array and
> packed formats, yes or no?

Yes.


> 2) What is your preference for array format naming convention:
> a) RGBA_UNORM
> b) R8G8B8A8_UNORM
> c) RGBA_UNORM8

c)


> 3) What is your preference for packed format naming convention:
>a) RGBA5551_UNORM
>b) R5G5B5A1_UNORM

b)


> 4) What is your preference for naming packed formats with 10 or more bits:
>a) RGBA1010102_UNORM
>b) R10G10B10A2_UNORM
>c) RGBAaaa2_UNORM
>d) Croque-monsieur

b) (so the component size doesn't matter for packed formats)


-- 
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

[Mesa-dev] [Bug 72926] [REGRESSION, swrast] Memory-related crash with anti-aliasing enabled

[bugzilla-daemon]

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

--- Comment #14 from Brian Paul  ---
(In reply to comment #13)
> (In reply to comment #12)
> > Created attachment 92096 [details]
> > proposed fix for the bug
> > 
> > Can you try this patch?  It fixes your test program for me.
> 
> Works great, tested it with mesa master
> 8c4a9f631d7438aeaf56785401891d0773792123 and on top of 10.0.2. Both versions
> do not crash anymore, whatever I try for some minutes (my java program,
> another C program and the attached apitrace).
> 
> I verified that 10.0.2 still crashes without the patch. Can this patch be
> backported to 10.0? I have not ran piglit tests though.

I'll post the patch for review on mesa-dev and tag it for inclusion in the next
10.0.x release.

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

[Mesa-dev] [Bug 73638] New: [llvmpipe] piglit fbo-missing-attachment-blit es2 from regression

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 73638
  Keywords: regression
CC: bri...@vmware.com, mar...@gmail.com
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [llvmpipe] piglit fbo-missing-attachment-blit es2 from
regression
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Mesa core
   Product: Mesa

mesa: 8c4a9f631d7438aeaf56785401891d0773792123 (master)

$ ./bin/fbo-missing-attachment-blit es2 from -auto
Testing blit from buffer with missing attachment to complete buffer...
Segmentation fault (core dumped)

Program terminated with signal 11, Segmentation fault.
#0  0x7f6e6757cd1c in lp_scene_begin_binning (scene=0x7f6e6b1e0010,
fb=0x191a998, discard=0 '\000') at src/gallium/drivers/llvmpipe/lp_scene.c:524
524  if (llvmpipe_resource_is_texture(cbuf->texture)) {
(gdb) bt
#0  0x7f6e6757cd1c in lp_scene_begin_binning (scene=0x7f6e6b1e0010,
fb=0x191a998, discard=0 '\000') at src/gallium/drivers/llvmpipe/lp_scene.c:524
#1  0x7f6e6757e1ed in lp_setup_get_empty_scene (setup=0x191a820) at
src/gallium/drivers/llvmpipe/lp_setup.c:84
#2  0x7f6e6757e964 in set_scene_state (setup=0x191a820,
new_state=SETUP_CLEARED, reason=0x7f6e68384cb0 <__func__.16142>
"lp_setup_try_clear")
at src/gallium/drivers/llvmpipe/lp_setup.c:290
#3  0x7f6e6757ed7b in lp_setup_try_clear (setup=0x191a820,
color=0x7f6e5dc404ec, depth=0, stencil=0, flags=1) at
src/gallium/drivers/llvmpipe/lp_setup.c:434
#4  0x7f6e6757ee5c in lp_setup_clear (setup=0x191a820,
color=0x7f6e5dc404ec, depth=0, stencil=0, flags=1) at
src/gallium/drivers/llvmpipe/lp_setup.c:461
#5  0x7f6e675a400f in llvmpipe_clear (pipe=0x19038b0, buffers=1,
color=0x7f6e5dc404ec, depth=0, stencil=0) at
src/gallium/drivers/llvmpipe/lp_clear.c:62
#6  0x7f6e677e6a6a in st_Clear (ctx=0x7f6e5dc3f010, mask=16) at
src/mesa/state_tracker/st_cb_clear.c:512
#7  0x7f6e677413d4 in _mesa_Clear (mask=256) at src/mesa/main/clear.c:206
#8  0x7f6e6ae762cf in stub_glClear (mask=256) at
piglit/tests/util/generated_dispatch.c:1935
#9  0x004015ef in do_blit_test (use_es2=true,
from_missing_to_complete=true) at
piglit/tests/spec/arb_es2_compatibility/fbo-missing-attachment-blit.c:143
#10 0x004018fc in piglit_init (argc=3, argv=0x7fffbad52918) at
piglit/tests/spec/arb_es2_compatibility/fbo-missing-attachment-blit.c:214
#11 0x7f6e6ae718fa in run_test (gl_fw=0x7f6e6b15f340 , argc=3,
argv=0x7fffbad52918) at
piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:140
#12 0x7f6e6ae6f6c9 in piglit_gl_test_run (argc=3, argv=0x7fffbad52918,
config=0x7fffbad527e0) at piglit/tests/util/piglit-framework-gl.c:191
#13 0x0040133e in main (argc=3, argv=0x7fffbad52918) at
piglit/tests/spec/arb_es2_compatibility/fbo-missing-attachment-blit.c:67
(gdb) frame 0
#0  0x7f6e6757cd1c in lp_scene_begin_binning (scene=0x7f6e6b1e0010,
fb=0x191a998, discard=0 '\000') at src/gallium/drivers/llvmpipe/lp_scene.c:524
524  if (llvmpipe_resource_is_texture(cbuf->texture)) {
(gdb) print cbuf
$1 = (struct pipe_surface *) 0x0


9baa45f78b8ca7d66280e36009b6a685055d7cd6 is the first bad commit
commit 9baa45f78b8ca7d66280e36009b6a685055d7cd6
Author: Marek Olšák 
Date:   Wed Jan 8 01:09:15 2014 +0100

st/mesa: bind NULL colorbuffers as specified by glDrawBuffers

An example why it is required:

Let's say there's a fragment shader writing to gl_FragData[0..1].
The user calls: glDrawBuffers(2, {GL_NONE, GL_COLOR_ATTACHMENT0});

That means gl_FragData[0] is unused and gl_FragData[1] is written
to GL_COLOR_ATTACHMENT0.

st/mesa was skipping the GL_NONE draw buffer, therefore gl_FragData[0]
was written to GL_COLOR_ATTACHMENT0, which was wrong.

This commit fixes it, but drivers must also be fixed not to crash when
binding NULL colorbuffers. There is also a new set of piglit tests for
this.

The MSAA state also had to be fixed not to crash when reading fb->cbufs[0].

Reviewed-by: Brian Paul 

:04 04 6818bdd84e475c30bd43fc3b5d98af8c6cdd39a7
e73a34aacda41dd8046b425b6d2397a1f8dd6ee8 Msrc
bisect run success

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

[Mesa-dev] [PATCH] draw: fix incorrect vertex size computation in LLVM drawing code

[Brian Paul]

We were calling draw_total_vs_outputs() too early.  The call to
draw_pt_emit_prepare() could result in the vertex size changing.
So call draw_total_vs_outputs() after draw_pt_emit_prepare().

This fix would seem to be needed for the non-LLVM code as well,
but it's not obvious.  Instead, I added an assertion there to
try to catch this problem if it were to occur there.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72926
Cc: 10.0 
---
 .../auxiliary/draw/draw_pt_fetch_shade_pipeline.c  |7 +--
 .../draw/draw_pt_fetch_shade_pipeline_llvm.c   |   22 
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c 
b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
index 8fcc170..2c5c4cd 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
@@ -72,8 +72,8 @@ static void fetch_pipeline_prepare( struct draw_pt_middle_end 
*middle,
 
const unsigned gs_out_prim = (gs ? gs->output_primitive :
  u_assembled_prim(prim));
-   unsigned nr = MAX2( vs->info.num_inputs,
-  draw_total_vs_outputs(draw) );
+   unsigned nr_vs_outputs = draw_total_vs_outputs(draw);
+   unsigned nr = MAX2(vs->info.num_inputs, nr_vs_outputs);
 
if (gs) {
   nr = MAX2(nr, gs->info.num_outputs + 1);
@@ -129,6 +129,9 @@ static void fetch_pipeline_prepare( struct 
draw_pt_middle_end *middle,
/* No need to prepare the shader.
 */
vs->prepare(vs, draw);
+
+   /* Make sure that the vertex size didn't change at any point above */
+   assert(nr_vs_outputs == draw_total_vs_outputs(draw));
 }
 
 
diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c 
b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
index 9f17241..60ec528 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
@@ -141,19 +141,11 @@ llvm_middle_end_prepare( struct draw_pt_middle_end 
*middle,
struct draw_geometry_shader *gs = draw->gs.geometry_shader;
const unsigned out_prim = gs ? gs->output_primitive :
   u_assembled_prim(in_prim);
-   const unsigned nr = MAX2(vs->info.num_inputs,
-draw_total_vs_outputs(draw));
+   unsigned nr;
 
fpme->input_prim = in_prim;
fpme->opt = opt;
 
-   /* Always leave room for the vertex header whether we need it or
-* not.  It's hard to get rid of it in particular because of the
-* viewport code in draw_pt_post_vs.c.
-*/
-   fpme->vertex_size = sizeof(struct vertex_header) + nr * 4 * sizeof(float);
-
-
draw_pt_post_vs_prepare( fpme->post_vs,
 draw->clip_xy,
 draw->clip_z,
@@ -177,6 +169,18 @@ llvm_middle_end_prepare( struct draw_pt_middle_end *middle,
   *max_vertices = 4096;
}
 
+   /* Get the number of float[4] attributes per vertex.
+* Note: this must be done after draw_pt_emit_prepare() since that
+* can effect the vertex size.
+*/
+   nr = MAX2(vs->info.num_inputs, draw_total_vs_outputs(draw));
+
+   /* Always leave room for the vertex header whether we need it or
+* not.  It's hard to get rid of it in particular because of the
+* viewport code in draw_pt_post_vs.c.
+*/
+   fpme->vertex_size = sizeof(struct vertex_header) + nr * 4 * sizeof(float);
+
/* return even number */
*max_vertices = *max_vertices & ~1;
 
-- 
1.7.10.4

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

[Mesa-dev] [PATCH] nv50, nvc0: don't crash on a null cbuf

[Ilia Mirkin]

This is needed since commit 9baa45f78b (st/mesa: bind NULL colorbuffers
as specified by glDrawBuffers).

Signed-off-by: Ilia Mirkin 
---

Not sure whether something needs to be done to clear out the old RT_* settings
for that index buffer, or if things are cleared out implicitly. Perhaps
instead of skipping indices, RT_CONTROL needs to be adjusted with the
appropriate indices?

 src/gallium/drivers/nouveau/nv50/nv50_state_validate.c | 14 +++---
 src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 14 +++---
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c 
b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
index 86b9a23..7d330c9 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
@@ -20,9 +20,17 @@ nv50_validate_fb(struct nv50_context *nv50)
PUSH_DATA (push, fb->height << 16);
 
for (i = 0; i < fb->nr_cbufs; ++i) {
-  struct nv50_miptree *mt = nv50_miptree(fb->cbufs[i]->texture);
-  struct nv50_surface *sf = nv50_surface(fb->cbufs[i]);
-  struct nouveau_bo *bo = mt->base.bo;
+  struct nv50_miptree *mt;
+  struct nv50_surface *sf;
+  struct nouveau_bo *bo;
+
+  /* Do we need to clear the old RT settings? */
+  if (!fb->cbufs[i])
+ continue;
+
+  mt = nv50_miptree(fb->cbufs[i]->texture);
+  sf = nv50_surface(fb->cbufs[i]);
+  bo = mt->base.bo;
 
   array_size = MIN2(array_size, sf->depth);
   if (mt->layout_3d)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
index 0ba4bad..9059d76 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c
@@ -72,9 +72,17 @@ nvc0_validate_fb(struct nvc0_context *nvc0)
 PUSH_DATA (push, fb->height << 16);
 
 for (i = 0; i < fb->nr_cbufs; ++i) {
-struct nv50_surface *sf = nv50_surface(fb->cbufs[i]);
-struct nv04_resource *res = nv04_resource(sf->base.texture);
-struct nouveau_bo *bo = res->bo;
+struct nv50_surface *sf;
+struct nv04_resource *res;
+struct nouveau_bo *bo;
+
+/* Do we need to clear the old RT settings? */
+if (!fb->cbufs[i])
+   continue;
+
+sf = nv50_surface(fb->cbufs[i]);
+res = nv04_resource(sf->base.texture);
+bo = res->bo;
 
 BEGIN_NVC0(push, NVC0_3D(RT_ADDRESS_HIGH(i)), 9);
 PUSH_DATAh(push, res->address + sf->offset);
-- 
1.8.3.2

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

Re: [Mesa-dev] RFC: ARB_arrays_of_arrays work in progress

[Timothy Arceri]

I think I've made things harder for my self than they need to be rather
than creating a glsl_type object to hold all the array information for
all dimensions I'm now thinking it would be simpler when processing the
ast to hir to just create a new type object for each dimension which
will then just be accessed recursively in the ir code. This way I
possibly don't need to touch the ir code at all, everything should just
work. I have been back and forth on which was the correct was to do this
but I'm now pretty sure I need to go back and change the way I've
currently implemented this part. However if everything works how I'm
picturing it in my mind after changing this there isn't much more left
to do for implementing the extension (I'm sure there probably is more to
it though).

On Tue, 2014-01-14 at 22:53 +1100, Timothy Arceri wrote:
> Hi all,
> 
> Its still a work in progress currently just passing the compile tests
> that I submitted to the piglit list [1].
> Its also a bit of a mess (some patches need squashing, a number of
> patches are just temp updates to support single dimension arrays for the
> time being) but I thought I would request feedback from anyone that's
> interested so that I can find out if I'm at least heading in the right
> direction at this early stage.
> 
> Anyway if anyone's interested in taking a look my latest code is here:
> https://github.com/tarceri/Mesa_arrays_of_arrays/tree/rebase6
> 
> Some issues I'm aware of (aside all the missing functionality) is the
> key and name generation code in glsl_types.cpp is a bit flimsy its good
> enough to pass the piglit tests but I'm sure it wouldn't take much to
> break it.
> 
> [1]
> http://lists.freedesktop.org/archives/piglit/2014-January/008990.html
> 


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

[Mesa-dev] [Bug 69874] Automake throws a lot of "[...] option 'subdir-objects' is disabled"

[bugzilla-daemon]

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

--- Comment #8 from David C. Rankin  ---
Help automake 1.14.1-1 HAL Fails to Build from Source.

  It appears this may be more than a warning for hal. How do I fix this? As
soon as the build starts:

configure.in:1046: the top level
automake: warning: autoconf input should be named 'configure.ac', not
'configure.in'
doc/man/Makefile.am:19: warning: '%'-style pattern rules are a GNU make
extension
parallel-tests: error: required file './test-driver' not found
parallel-tests:   'automake --add-missing' can install 'test-driver'
hald/linux/addons/Makefile.am:80: warning: source file '../../logger.c' is in a
subdirectory,
hald/linux/addons/Makefile.am:80: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding
output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout
your
automake: project, to avoid future incompatibilities.
hald/linux/addons/Makefile.am:80: warning: source file '../../util_helper.c' is
in a subdirectory,
hald/linux/addons/Makefile.am:80: but option 'subdir-objects' is disabled
hald/linux/addons/Makefile.am:84: warning: source file '../../logger.c' is in a
subdirectory,
hald/linux/addons/Makefile.am:84: but option 'subdir-objects' is disabled
hald/linux/addons/Makefile.am:84: warning: source file '../../util_helper.c' is
in a subdirectory,
hald/linux/addons/Makefile.am:84: but option 'subdir-objects' is disabled

hald/solaris/probing/Makefile.am:19: warning: source file '../../logger.c' is
in a subdirectory,
hald/solaris/probing/Makefile.am:19: but option 'subdir-objects' is disabled
partutil/Makefile.am:7: warning: source file '../hald/logger.c' is in a
subdirectory,
partutil/Makefile.am:7: but option 'subdir-objects' is disabled
policy/Makefile.am:27: warning: whitespace following trailing backslash
==> ERROR: A failure occurred in build().
Aborting...

I will attach the build log as hal-makefile.err.txt

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

[Mesa-dev] [Bug 69874] Automake throws a lot of "[...] option 'subdir-objects' is disabled"

[bugzilla-daemon]

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

--- Comment #9 from David C. Rankin  ---
Created attachment 92110
  --> https://bugs.freedesktop.org/attachment.cgi?id=92110&action=edit
hal failure to build log

This is the build log for the automake/makefile errors building hal with
automake 1.14.1-1 on Archlinux

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

Re: [Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Alex Henrie]

2014/1/14 Bruno Jimenez :
> I think I prefer without "la", but if you prefer with, it's also ok.

I also prefer to omit the "la".

> To me, it sounds better "renderizado". As usual, RAE doesn't say
> anything, and wikipedia has an entry titled "renderización" (and
> "renderizado" redirected to it too), but the first word of the article
> is "renderizado". Still, both are ok, so I don't really mind which one.

I'm going to go with "renderización". I think it must be a regional difference.

Let me know if you find any other errors.

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

[Mesa-dev] [PATCH 3/3] driconf: Add Catalan translations

[Alex Henrie]

See the instructions in Makefile.am under "Adding new translations".
---
 src/mesa/drivers/dri/common/xmlpool/Makefile.am |   2 +-
 src/mesa/drivers/dri/common/xmlpool/ca.po   | 302 
 2 files changed, 303 insertions(+), 1 deletion(-)
 create mode 100644 src/mesa/drivers/dri/common/xmlpool/ca.po

diff --git a/src/mesa/drivers/dri/common/xmlpool/Makefile.am 
b/src/mesa/drivers/dri/common/xmlpool/Makefile.am
index ad7887d..0908c82 100644
--- a/src/mesa/drivers/dri/common/xmlpool/Makefile.am
+++ b/src/mesa/drivers/dri/common/xmlpool/Makefile.am
@@ -41,7 +41,7 @@
 # - info gettext
 
 # The set of supported languages. Add languages as needed.
-POS=de.po es.po nl.po fr.po sv.po
+POS=ca.po de.po es.po nl.po fr.po sv.po
 
 #
 # Don't change anything below, unless you know what you're doing.
diff --git a/src/mesa/drivers/dri/common/xmlpool/ca.po 
b/src/mesa/drivers/dri/common/xmlpool/ca.po
new file mode 100644
index 000..ed84cca
--- /dev/null
+++ b/src/mesa/drivers/dri/common/xmlpool/ca.po
@@ -0,0 +1,302 @@
+# Language  translations for Mesa package
+# Traduccions al català del paquet «Mesa».
+# Copyright (C) 2014 MESA'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the Mesa package.
+# Alex Henrie , 2014.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: Mesa 10.1.0-devel\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2014-01-13 22:30-0700\n"
+"PO-Revision-Date: 2014-01-14 21:54-0700\n"
+"Last-Translator: Alex Henrie \n"
+"Language-Team: Catalan \n"
+"Language: ca\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: Poedit 1.5.4\n"
+
+#: t_options.h:56
+msgid "Debugging"
+msgstr "Depuració"
+
+#: t_options.h:60
+msgid "Disable 3D acceleration"
+msgstr "Deshabilita l'acceleració 3D"
+
+#: t_options.h:65
+msgid "Show performance boxes"
+msgstr "Mostra les caixes de rendiment"
+
+#: t_options.h:70
+msgid "Enable flushing batchbuffer after each draw call"
+msgstr "Habilita el buidatge del batchbuffer després de cada trucada de dibuix"
+
+#: t_options.h:75
+msgid "Enable flushing GPU caches with each draw call"
+msgstr ""
+"Habilita el buidatge de les memòries cau de GPU amb cada trucada de dibuix"
+
+#: t_options.h:80
+msgid "Disable throttling on first batch after flush"
+msgstr "Deshabilita la regulació en el primer lot després de buidar"
+
+#: t_options.h:85
+msgid "Force GLSL extension default behavior to 'warn'"
+msgstr "Força el comportament de l'extensió GLSL a 'warn'"
+
+#: t_options.h:90
+msgid "Disable dual source blending"
+msgstr "Deshabilita la barreja de font dual"
+
+#: t_options.h:95
+msgid "Disable backslash-based line continuations in GLSL source"
+msgstr ""
+"Deshabilitar les continuacions de línia basades en barra invertida en la "
+"font GLSL"
+
+#: t_options.h:100
+msgid "Disable GL_ARB_shader_bit_encoding"
+msgstr "Deshabilita el GL_ARB_shader_bit_encoding"
+
+#: t_options.h:105
+msgid ""
+"Force a default GLSL version for shaders that lack an explicit #version line"
+msgstr ""
+"Força una versió GLSL per defecte en els shaders als quals falta una línia "
+"#version explícita"
+
+#: t_options.h:115
+msgid "Image Quality"
+msgstr "Qualitat d'Imatge"
+
+#: t_options.h:128
+msgid "Texture color depth"
+msgstr "Profunditat de color de textura"
+
+#: t_options.h:129
+msgid "Prefer frame buffer color depth"
+msgstr "Prefereix profunditat de color del framebuffer"
+
+#: t_options.h:130
+msgid "Prefer 32 bits per texel"
+msgstr "Prefereix 32 bits per texel"
+
+#: t_options.h:131
+msgid "Prefer 16 bits per texel"
+msgstr "Prefereix 16 bits per texel"
+
+#: t_options.h:132
+msgid "Force 16 bits per texel"
+msgstr "Força 16 bits per texel"
+
+#: t_options.h:138
+msgid "Initial maximum value for anisotropic texture filtering"
+msgstr "Valor màxim inicial per a la filtració de textura anisòtropa"
+
+#: t_options.h:143
+msgid "Forbid negative texture LOD bias"
+msgstr ""
+"Prohibeix una parcialitat negativa del Nivell de Detalle (LOD) de les "
+"textures"
+
+#: t_options.h:148
+msgid ""
+"Enable S3TC texture compression even if software support is not available"
+msgstr ""
+"Habilitar la compressió de textures S3TC encara que el suport de programari "
+"no estigui disponible"
+
+#: t_options.h:155
+msgid "Initial color reduction method"
+msgstr "Mètode inicial de reducció de color"
+
+#: t_options.h:156
+msgid "Round colors"
+msgstr "Colors arrodonits"
+
+#: t_options.h:157
+msgid "Dither colors"
+msgstr "Colors tramats"
+
+#: t_options.h:165
+msgid "Color rounding method"
+msgstr "Mètode d'arrodoniment de color"
+
+#: t_options.h:166
+msgid "Round color components downward"
+msgstr "Arrondeix els components de color a baix"
+
+#: t_options.h:167
+msgid "Round to nearest color"
+msgstr "Arrondeix al color més proper"
+
+#: t_options.h:176
+msgid "Color dithering method"
+msgstr "Mètode de tramat de color"
+
+#: t_options.h:177
+msgid "Horizontal error diffusion"
+msgstr "Difusió d'err

[Mesa-dev] [PATCH 2/3] driconf: Correct and update Spanish translations

[Alex Henrie]

---
 src/mesa/drivers/dri/common/xmlpool/es.po | 65 ---
 1 file changed, 33 insertions(+), 32 deletions(-)

diff --git a/src/mesa/drivers/dri/common/xmlpool/es.po 
b/src/mesa/drivers/dri/common/xmlpool/es.po
index e5b4d1a..4f47e73 100644
--- a/src/mesa/drivers/dri/common/xmlpool/es.po
+++ b/src/mesa/drivers/dri/common/xmlpool/es.po
@@ -10,23 +10,23 @@ msgstr ""
 "Project-Id-Version: es\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2014-01-13 22:30-0700\n"
-"PO-Revision-Date: 2005-04-12 20:26+0200\n"
-"Last-Translator: David Rubio Miguélez \n"
+"PO-Revision-Date: 2014-01-14 18:15-0700\n"
+"Last-Translator: Alex Henrie \n"
 "Language-Team: Spanish \n"
 "Language: es\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=(n != 1);\n"
-"X-Generator: KBabel 1.10\n"
+"X-Generator: Poedit 1.5.4\n"
 
 #: t_options.h:56
 msgid "Debugging"
-msgstr "Depurando"
+msgstr "Depuración"
 
 #: t_options.h:60
 msgid "Disable 3D acceleration"
-msgstr "Desactivar aceleración 3D"
+msgstr "Deshabilitar aceleración 3D"
 
 #: t_options.h:65
 msgid "Show performance boxes"
@@ -34,36 +34,40 @@ msgstr "Mostrar cajas de rendimiento"
 
 #: t_options.h:70
 msgid "Enable flushing batchbuffer after each draw call"
-msgstr ""
+msgstr "Habilitar vaciado del batchbuffer después de cada llamada de dibujo"
 
 #: t_options.h:75
 msgid "Enable flushing GPU caches with each draw call"
-msgstr ""
+msgstr "Habilitar vaciado de los cachés GPU con cada llamada de dibujo"
 
 #: t_options.h:80
 msgid "Disable throttling on first batch after flush"
-msgstr ""
+msgstr "Deshabilitar regulación del primer lote después de vaciar"
 
 #: t_options.h:85
 msgid "Force GLSL extension default behavior to 'warn'"
-msgstr ""
+msgstr "Forzar comportamiento por defecto de la extensión GLSL a 'warn'"
 
 #: t_options.h:90
 msgid "Disable dual source blending"
-msgstr ""
+msgstr "Deshabilitar mezcla de fuente dual"
 
 #: t_options.h:95
 msgid "Disable backslash-based line continuations in GLSL source"
 msgstr ""
+"Deshabilitar continuaciones de línea basadas en barra inversa en el código "
+"GLSL"
 
 #: t_options.h:100
 msgid "Disable GL_ARB_shader_bit_encoding"
-msgstr ""
+msgstr "Deshabilitar GL_ARB_shader_bit_encoding"
 
 #: t_options.h:105
 msgid ""
 "Force a default GLSL version for shaders that lack an explicit #version line"
 msgstr ""
+"Forzar una versión de GLSL por defecto en los shaders a los cuales les falta "
+"una línea #version explícita"
 
 #: t_options.h:115
 msgid "Image Quality"
@@ -75,7 +79,7 @@ msgstr "Profundidad de color de textura"
 
 #: t_options.h:129
 msgid "Prefer frame buffer color depth"
-msgstr "Preferir profundidad de color del \"framebuffer\""
+msgstr "Preferir profundidad de color del framebuffer"
 
 #: t_options.h:130
 msgid "Prefer 32 bits per texel"
@@ -101,8 +105,8 @@ msgstr "Prohibir valores negativos de Nivel De Detalle 
(LOD) de texturas"
 msgid ""
 "Enable S3TC texture compression even if software support is not available"
 msgstr ""
-"Activar la compresión de texturas S3TC incluso si el soporte por software no "
-"está disponible"
+"Habilitar la compresión de texturas S3TC incluso si el soporte por software "
+"no está disponible"
 
 #: t_options.h:155
 msgid "Initial color reduction method"
@@ -150,31 +154,35 @@ msgstr "Búfer de profundidad en coma flotante"
 
 #: t_options.h:190
 msgid "A post-processing filter to cel-shade the output"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para aplicar cel shading a la salida"
 
 #: t_options.h:195
 msgid "A post-processing filter to remove the red channel"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para eliminar el canal rojo"
 
 #: t_options.h:200
 msgid "A post-processing filter to remove the green channel"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para eliminar el canal verde"
 
 #: t_options.h:205
 msgid "A post-processing filter to remove the blue channel"
-msgstr ""
+msgstr "Un filtro de postprocesamiento para eliminar el canal azul"
 
 #: t_options.h:210
 msgid ""
 "Morphological anti-aliasing based on Jimenez\\' MLAA. 0 to disable, 8 for "
 "default quality"
 msgstr ""
+"Antialiasing morfológico basado en el MLAA de Jimenez. 0 para deshabilitar, "
+"8 para calidad por defecto"
 
 #: t_options.h:215
 msgid ""
 "Morphological anti-aliasing based on Jimenez\\' MLAA. 0 to disable, 8 for "
 "default quality. Color version, usable with 2d GL apps"
 msgstr ""
+"Antialiasing morfológico basado en el MLAA de Jimenez. 0 para deshabilitar, "
+"8 para calidad por defecto. Versión en color, usable con aplicaciones GL 2D"
 
 #: t_options.h:225
 msgid "Performance"
@@ -200,12 +208,12 @@ msgstr "Pasar por alto la tubería TCL"
 msgid ""
 "Bypass the TCL pipeline with state-based machine code generated on-the-fly"
 msgstr ""
-"Pasar por alto la tubería TCL con código máquina basado en estados generado "
+"Pasar por alto la tubería TCL con código máquin

[Mesa-dev] [Bug 69874] Automake throws a lot of "[...] option 'subdir-objects' is disabled"

[bugzilla-daemon]

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

--- Comment #10 from Alan Coopersmith  ---
(In reply to comment #9)
> Created attachment 92110 [details]
> hal failure to build log
> 
> This is the build log for the automake/makefile errors building hal with
> automake 1.14.1-1 on Archlinux

Mesa has nothing to do with hal - you need to file a new bug with hal
developers about that (who will likely tell you hal was deprecated years ago).

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

Re: [Mesa-dev] gallium endianness and hw drivers

[Michel Dänzer]

On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote:
> I think the format conversion functions should look like:
> 
> #ifdef BIG_ENDIAN
>case PIPE_FORMAT_A8B8G8R8_UNORM:
>   return hw_format_for_R8G8B8A8_UNORM;
> ...
> #else
>case PIPE_FORMAT_R8G8B8A8_UNORM:
>   return hw_format_for_R8G8B8A8_UNORM;
> #endif
> 
> which can be simplified to:
> 
>case PIPE_FORMAT_RGBA_UNORM:
>   return hw_format_for_R8G8B8A8_UNORM;
> 
> So that the GPU can see the same formats, but they are different for the CPU.
> 
> What do you think?

That might be an option, but PIPE_FORMAT_R8G8B8A8_UNORM is useful on big
endian hosts as well, e.g. it matches GL_RGBA / GL_UNSIGNED_BYTE
exactly.

I think one issue here is that we're trying to use a single format
attribute for several purposes (API visible representation, GPU/driver
internal representation).


-- 
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