date:20150309

Re: [Mesa-dev] [PATCH 1/6] c11: add c11 compatibility wrapper around stdlib.h

2015-03-09 Thread Jose Fonseca


On 07/03/15 19:38, Emil Velikov wrote:

On 07/03/15 07:23, Jose Fonseca wrote:
...

we still
didn't eliminate the use of non-portable _MTX_INITIALIZER_NP from Mesa
tree gave me pause.


The only way I can think about resolving this, is to use call_once() to
initialize the mutex,


Yes, I'm afraid so.

Static initialization of is much simpler than the call_once paradigm, 
but unfortunately ISO didn't standardize a static initializer for ISO 
C11 threads.h, and we can't tell whether it will be possible to somehow 
to provide _MTX_INITIALIZER_NP on top of future C11 threads.h 
implementations that we might care about.


In particular, it is possible that GLIBC's C11 threads.h implementation 
of mutex will not be just a wrapper around pthreads:


 https://sourceware.org/ml/libc-alpha/2014-02/msg00782.html
 https://sourceware.org/bugzilla/show_bug.cgi?id=14092

And if mutexes become opaque binary structures, then it will really be 
impossible.


Maybe that's why ISO didn't do it -- precisely so that C11 mutexes 
internal representation doesn't need to be part of the ABI, only its 
size is, and standard lib is free to change its internals, withing that 
size.



but I'm not 100% sure if T2 will sync until T1
call_once's func has returned. How does it sound ?


I believe those are precisely the semantics of call_once.



...

We can can consider move the c99_foo.h/c11_foo.h them somewhere else
(another subdirectory, or util) or renaming them (like u_foo.h).


I have no objection on moving the file, but please keep the file name in
some form that makes it obvious about the spec compat/wrapping it provides.

FYI I'm contemplating on about adding a final wrapper - c99_string.h. It
should nuke nearly all of the remaining compiler abstraction that we
have around - mapi, egl, gallium, mesa, glsl...

-Emil



Sounds good to me.  I can build-test them if Brian's not available.


I wonder if we should remove src/gallium/auxiliary/util/u_snprintf.c too.

This implementation of snprintf was necessary when we needed to build 
gallium for XP kernel mode, which didn't support floating-point support, 
but nowadays MSVC's _snprintf suits just as well AFAICT.



On the other hand, we should be careful about localization, as using the 
system's snprintf might easily cause floating/integers to formatted 
weirdly (extra spaces, commas, or different decimal separators. etc), so 
it's not safe to use it for things beyond user messages/logs...


That is, it might be better to override

  #define snprintf _unlocalized_snprintf
  #define asprintf _unlocalized_asprintf
  [...]

and provide our own implementations of all these...


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

Re: [Mesa-dev] [PATCH 4/4] Clover: use get_device_vendor instead of get_vendor

2015-03-09 Thread Francisco Jerez

Giuseppe Bilotta giuseppe.bilo...@gmail.com writes:

 The pipe's get_vendor method returns something more akin to a driver
 vendor string in most cases, instead of the actual device vendor. Use
 get_device_vendor instead, which was introduced specifically for this
 purpose.

For this patch:
Reviewed-by: Francisco Jerez curroje...@riseup.net

 ---
  src/gallium/state_trackers/clover/core/device.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
 b/src/gallium/state_trackers/clover/core/device.cpp
 index c3f3b4e..42b45b7 100644
 --- a/src/gallium/state_trackers/clover/core/device.cpp
 +++ b/src/gallium/state_trackers/clover/core/device.cpp
 @@ -192,7 +192,7 @@ device::device_name() const {
  
  std::string
  device::vendor_name() const {
 -   return pipe-get_vendor(pipe);
 +   return pipe-get_device_vendor(pipe);
  }
  
  enum pipe_shader_ir
 -- 
 2.1.2.766.gaa23a90

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


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

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

2015-03-09 Thread Juliet Fru

Hello,

Thanks for the email. I am currently updating the proposal now.

Best,
Juliet

On Mon, Mar 9, 2015 at 12:32 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:

On 04/03/15 11:21, Juliet Fru wrote:
Hello,

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

Thanks,
Juliet
Porting Glean tests to Piglit framework OPW Proposal

https://docs.google.com/document/d/1Y5flvgsJg5s6XUfTP955qKDbhG0ldXBCjGd-YROtTtM/edit?usp=drive_web

Hi Juliet,

Thank you for the interest :-)

Did you link the correct proposal - this one seems to be for OPW ? Here
are some examples [1] [2] [3] [4], which you might find inspirational.

For your next iteration please send your proposal as plain text in the
email body. This way people can comment on it directly and their
feedback will be visible to everyone on the list.

1 2 >

1 - 100 of 107 matches

Mail list logo