[Mesa-dev] [PATCH 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead
Signed-off-by: Alon Levy --- src/glsl/glsl_parser.yy | 4 1 file changed, 4 insertions(+) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index faaf438..25370cd 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -26,6 +26,10 @@ #include #include +#ifdef _MSC_VER <= 1800 +#define strcasecmp _stricmp +#endif + #include "ast.h" #include "glsl_parser_extras.h" #include "glsl_types.h" -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/7] u_math.h: fix 64 to 32 bit truncation warning
Signed-off-by: Alon Levy --- This file is common so this warning comes up a lot. src/gallium/auxiliary/util/u_math.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h index 60995d7..7c1ac4a 100644 --- a/src/gallium/auxiliary/util/u_math.h +++ b/src/gallium/auxiliary/util/u_math.h @@ -760,7 +760,7 @@ util_bswap64(uint64_t n) #if defined(HAVE___BUILTIN_BSWAP64) return __builtin_bswap64(n); #else - return ((uint64_t)util_bswap32(n) << 32) | + return ((uint64_t)util_bswap32((uint32_t)n) << 32) | util_bswap32((n >> 32)); #endif } -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] gallium/u_debug_flush.c: fix build error for vs12
use util_snprintf that is already defined in other systems by u_string.h
to as snprintf, so to not change behavior in other systems.
Signed-off-by: Alon Levy
---
src/gallium/auxiliary/util/u_debug_flush.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_debug_flush.c
b/src/gallium/auxiliary/util/u_debug_flush.c
index 9cf70db..fdb248c 100644
--- a/src/gallium/auxiliary/util/u_debug_flush.c
+++ b/src/gallium/auxiliary/util/u_debug_flush.c
@@ -46,6 +46,7 @@
#include "util/u_hash_table.h"
#include "util/u_double_list.h"
#include "util/u_inlines.h"
+#include "util/u_string.h"
#include "os/os_thread.h"
#include
@@ -320,8 +321,8 @@ debug_flush_might_flush_cb(void *key, void *value, void
*data)
const char *reason = (const char *) data;
char message[80];
- snprintf(message, sizeof(message),
-"%s referenced mapped buffer detected.", reason);
+ util_snprintf(message, sizeof(message),
+ "%s referenced mapped buffer detected.", reason);
pipe_mutex_lock(fbuf->mutex);
if (fbuf->mapped_sync) {
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/7] vs12 cleanup patches
Hi, These patches include some actual fixes for building target libgl-gdi with scons, and some warning removal (there are a ton left I didn't pursue - mostly truncation warnings and sign warnings). Not related to the patchset, but important for anyone building libgl-gdi (i.e. opengl32.dll) scons 2.3.2 seems broken wrt def files, I opened issue http://scons.tigris.org/issues/show_bug.cgi?id=2966 and used the patch included there to successfully build the dll. Alon Alon Levy (7): gallium/u_math.h: don't redefine INFINITY and NAN in VS2013 glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead gallium/u_debug_flush.c: fix build error for vs12 u_math.h: fix 64 to 32 bit truncation warning wgl: stw_pixelformat_get_info: correct type for index variable glsl: fix inconsistent struct/class warning in vs12 mesa/shaderimage.c: fix inconsistent sign warning src/gallium/auxiliary/util/u_debug_flush.c | 5 +++-- src/gallium/auxiliary/util/u_math.h | 4 ++-- src/gallium/state_trackers/wgl/stw_pixelformat.c | 2 +- src/glsl/glsl_parser.yy | 4 src/glsl/opt_dead_builtin_varyings.cpp | 2 +- src/mesa/main/shaderimage.c | 2 +- 6 files changed, 12 insertions(+), 7 deletions(-) -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] gallium/u_math.h: don't redefine INFINITY and NAN in VS2013
Under VS2013 compiler that is distinguished by _MSC_VER of 1800 those two
are already defined, use the SDK definition.
Another option would have been to undef and use the definitions here - I'm
not sure which is better.
---
This removes warnings, this patch is not actually required to build.
src/gallium/auxiliary/util/u_math.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index ec03e4e..60995d7 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -136,10 +136,10 @@ roundf(float x)
{
return x >= 0.0f ? floorf(x + 0.5f) : ceilf(x - 0.5f);
}
-#endif
#define INFINITY (DBL_MAX + DBL_MAX)
#define NAN (INFINITY - INFINITY)
+#endif
#endif /* _MSC_VER */
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/7] glsl: fix inconsistent struct/class warning in vs12
Remove incorrect struct prefix, ir_variable is a class Signed-off-by: Alon Levy --- src/glsl/opt_dead_builtin_varyings.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glsl/opt_dead_builtin_varyings.cpp b/src/glsl/opt_dead_builtin_varyings.cpp index c2a306e..f98a21f 100644 --- a/src/glsl/opt_dead_builtin_varyings.cpp +++ b/src/glsl/opt_dead_builtin_varyings.cpp @@ -334,7 +334,7 @@ public: } void prepare_array(exec_list *ir, - struct ir_variable **new_var, + ir_variable **new_var, int max_elements, unsigned start_location, const char *var_name, const char *mode_str, unsigned usage, unsigned external_usage) -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/7] wgl: stw_pixelformat_get_info: correct type for index variable
Signed-off-by: Alon Levy
---
src/gallium/state_trackers/wgl/stw_pixelformat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/wgl/stw_pixelformat.c
b/src/gallium/state_trackers/wgl/stw_pixelformat.c
index 1ef302d..7e5561b 100644
--- a/src/gallium/state_trackers/wgl/stw_pixelformat.c
+++ b/src/gallium/state_trackers/wgl/stw_pixelformat.c
@@ -297,7 +297,7 @@ stw_pixelformat_get_extended_count( void )
const struct stw_pixelformat_info *
stw_pixelformat_get_info( int iPixelFormat )
{
- int index;
+ unsigned index;
if (iPixelFormat <= 0) {
return NULL;
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] mesa/shaderimage.c: fix inconsistent sign warning
Signed-off-by: Alon Levy
---
src/mesa/main/shaderimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
index d1e752d..298ede2 100644
--- a/src/mesa/main/shaderimage.c
+++ b/src/mesa/main/shaderimage.c
@@ -383,7 +383,7 @@ validate_image_unit(struct gl_context *ctx, struct
gl_image_unit *u)
void
_mesa_validate_image_units(struct gl_context *ctx)
{
- int i;
+ unsigned i;
for (i = 0; i < ctx->Const.MaxImageUnits; ++i) {
struct gl_image_unit *u = &ctx->ImageUnits[i];
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa/imports.h: VS2013 doesn't provide strcasecmp
From: Alon Levy
Fixed build error at glsl_parser.yy for Visual Studio 2013
Signed-off-by: Alon Levy
---
Thanks for the review. I verified and VS2013 (vs12) doesn't include strcasecmp,
I corrected the file you mentioned, here is a better patch. (this supercedes
the previous patch)
src/mesa/main/imports.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index 9e221cc..06b460d 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -141,6 +141,9 @@ static inline float acoshf(float x) { return logf(x +
sqrtf(x * x - 1.0f)); }
static inline float atanhf(float x) { return (logf(1.0f + x) - logf(1.0f - x))
/ 2.0f; }
static inline int isblank(int ch) { return ch == ' ' || ch == '\t'; }
#define strtoll(p, e, b) _strtoi64(p, e, b)
+#endif
+
+#if defined(_MSC_VER)
#define strcasecmp(s1, s2) _stricmp(s1, s2)
#endif
/*@}*/
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/imports.h: VS2013 doesn't provide strcasecmp
On 07/24/2014 02:12 PM, Alon Levy wrote:
> From: Alon Levy
Forgot to add Ian as cc.
>
> Fixed build error at glsl_parser.yy for Visual Studio 2013
>
> Signed-off-by: Alon Levy
> ---
> Thanks for the review. I verified and VS2013 (vs12) doesn't include
> strcasecmp,
> I corrected the file you mentioned, here is a better patch. (this supercedes
> the previous patch)
>
> src/mesa/main/imports.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
> index 9e221cc..06b460d 100644
> --- a/src/mesa/main/imports.h
> +++ b/src/mesa/main/imports.h
> @@ -141,6 +141,9 @@ static inline float acoshf(float x) { return logf(x +
> sqrtf(x * x - 1.0f)); }
> static inline float atanhf(float x) { return (logf(1.0f + x) - logf(1.0f -
> x)) / 2.0f; }
> static inline int isblank(int ch) { return ch == ' ' || ch == '\t'; }
> #define strtoll(p, e, b) _strtoi64(p, e, b)
> +#endif
> +
> +#if defined(_MSC_VER)
> #define strcasecmp(s1, s2) _stricmp(s1, s2)
> #endif
> /*@}*/
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead
On 07/24/2014 07:50 PM, Emil Velikov wrote:
> On 24/07/14 17:07, Matt Turner wrote:
>> On Thu, Jul 24, 2014 at 5:44 AM, Emil Velikov
>> wrote:
>>> On 23/07/14 22:16, Ian Romanick wrote:
>>>> On 07/22/2014 02:07 PM, Alon Levy wrote:
>>>>> Signed-off-by: Alon Levy
>>>>> ---
>>>>> src/glsl/glsl_parser.yy | 4
>>>>> 1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
>>>>> index faaf438..25370cd 100644
>>>>> --- a/src/glsl/glsl_parser.yy
>>>>> +++ b/src/glsl/glsl_parser.yy
>>>>> @@ -26,6 +26,10 @@
>>>>> #include
>>>>> #include
>>>>>
>>>>> +#ifdef _MSC_VER <= 1800
>>>>> +#define strcasecmp _stricmp
>>>>> +#endif
>>>>> +
>>>>
>>>> glsl_parser.yy should already get the strcasecmp work around from
>>>> src/mesa/main/imports.h.
>>>>
>>> Just a general question - wouldn't it be better if we move some/all these
>>> quirks around the POSIX standard(s) into a header similar to c99_compat ?
>>> ...
>>> before the amount of duplication gets out of hand.
>>
>> Sounds like a good idea to me, although I don't think strcasecmp is part of
>> C99.
>>
> You're absolutely correct. I was thinking about posix_compat.h ("header
> similar to c99_compat") where he can put all the quirks needed for non POSIX
> compliant setups. Unfortunately I don't think I have the time for this atm.
>
> -Emil
>
I can make a patch for just this case as a start.. If anyone has some
clues as to the rest of the non posix parts and how to test that I'm not
screwing anything up I can go for a fuller patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/imports.h: VS2013 doesn't provide strcasecmp
On 07/24/2014 02:12 PM, Alon Levy wrote:
> From: Alon Levy
>
> Fixed build error at glsl_parser.yy for Visual Studio 2013
>
> Signed-off-by: Alon Levy
Not required, my bad, I was looking at an old master, patch
8c879ac1977a265ae513a5569ee3af35dbc6b1aa already does this
> ---
> Thanks for the review. I verified and VS2013 (vs12) doesn't include
> strcasecmp,
> I corrected the file you mentioned, here is a better patch. (this supercedes
> the previous patch)
>
> src/mesa/main/imports.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
> index 9e221cc..06b460d 100644
> --- a/src/mesa/main/imports.h
> +++ b/src/mesa/main/imports.h
> @@ -141,6 +141,9 @@ static inline float acoshf(float x) { return logf(x +
> sqrtf(x * x - 1.0f)); }
> static inline float atanhf(float x) { return (logf(1.0f + x) - logf(1.0f -
> x)) / 2.0f; }
> static inline int isblank(int ch) { return ch == ' ' || ch == '\t'; }
> #define strtoll(p, e, b) _strtoi64(p, e, b)
> +#endif
> +
> +#if defined(_MSC_VER)
> #define strcasecmp(s1, s2) _stricmp(s1, s2)
> #endif
> /*@}*/
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] gallium/u_math.h: don't redefine INFINITY and NAN in VS2013
On 07/28/2014 07:13 PM, Brian Paul wrote:
> On 07/22/2014 03:07 PM, Alon Levy wrote:
>> Under VS2013 compiler that is distinguished by _MSC_VER of 1800 those two
>> are already defined, use the SDK definition.
>>
>> Another option would have been to undef and use the definitions here -
>> I'm
>> not sure which is better.
>> ---
>> This removes warnings, this patch is not actually required to build.
>>
>> src/gallium/auxiliary/util/u_math.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_math.h
>> b/src/gallium/auxiliary/util/u_math.h
>> index ec03e4e..60995d7 100644
>> --- a/src/gallium/auxiliary/util/u_math.h
>> +++ b/src/gallium/auxiliary/util/u_math.h
>> @@ -136,10 +136,10 @@ roundf(float x)
>> {
>> return x >= 0.0f ? floorf(x + 0.5f) : ceilf(x - 0.5f);
>> }
>> -#endif
>>
>> #define INFINITY (DBL_MAX + DBL_MAX)
>> #define NAN (INFINITY - INFINITY)
>> +#endif
>>
>> #endif /* _MSC_VER */
>>
>>
>
> This does not apply to the master branch. Neither does patch 3.
My bad, I was looking at an old branch. This is already fixed in master
by 7ebdc9e48c99a92475b48668284695663e871f7d
>
> -Brian
>
> ___
> 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] [RFC 0/3] Fix several segmentation faults related to depth buffer
Fixes three segmentation faults where it is wrongly assumed the depth buffer's renderbuffer's region is not NULL. 735794 - verified to be fixed by these three patches (these three apply to 7.11 almost cleanly, just the second requires minor changes). Related RHBZs (maybe solved as well, didn't reproduce): 734183 - [abrt] gnome-shell-3.1.4-2.gite7b9933.fc16: prepare_depthbuffer 717140 -[abrt] compiz-0.9.4-2.fc15: prepare_depthbuffer Alon Levy (3): i965: prepare_depthbuffer: fix segfault, rhbz#735794 i965: prepare_depthbuffer: don't update NULL region'ed surface, rhbz#735794 i965: emit_depthbuffer: fix segfault, rhbz#735794 src/mesa/drivers/dri/i965/brw_misc_state.c |7 +-- src/mesa/drivers/dri/i965/brw_wm_surface_state.c |3 +++ 2 files changed, 8 insertions(+), 2 deletions(-) -- 1.7.6.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 1/3] i965: prepare_depthbuffer: fix segfault, rhbz#735794
Also fixes a segfault immediatelly after in the same case, i.e. srb->region is also NULL in the run of virtualbox described in the bug report in the subject. Signed-off-by: Alon Levy --- src/mesa/drivers/dri/i965/brw_misc_state.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c b/src/mesa/drivers/dri/i965/brw_misc_state.c index f7e6e7c..479cf82 100644 --- a/src/mesa/drivers/dri/i965/brw_misc_state.c +++ b/src/mesa/drivers/dri/i965/brw_misc_state.c @@ -204,11 +204,11 @@ static void prepare_depthbuffer(struct brw_context *brw) struct intel_renderbuffer *drb = intel_get_renderbuffer(fb, BUFFER_DEPTH); struct intel_renderbuffer *srb = intel_get_renderbuffer(fb, BUFFER_STENCIL); - if (drb) + if (drb && drb->region) brw_add_validated_bo(brw, drb->region->buffer); if (drb && drb->hiz_region) brw_add_validated_bo(brw, drb->hiz_region->buffer); - if (srb) + if (srb && srb->region) brw_add_validated_bo(brw, srb->region->buffer); } -- 1.7.6.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 2/3] i965: prepare_depthbuffer: don't update NULL region'ed surface, rhbz#735794
--- src/mesa/drivers/dri/i965/brw_wm_surface_state.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c index ad90978..abaed60 100644 --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c @@ -442,6 +442,9 @@ brw_update_renderbuffer_surface(struct brw_context *brw, uint32_t tile_x, tile_y; uint32_t format = 0; + if (irb->region == NULL) + return; + surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 6 * 4, 32, &brw->wm.surf_offset[unit]); -- 1.7.6.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 3/3] i965: emit_depthbuffer: fix segfault, rhbz#735794
Signed-off-by: Alon Levy
---
src/mesa/drivers/dri/i965/brw_misc_state.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 479cf82..f102bc6 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -248,6 +248,9 @@ static void emit_depthbuffer(struct brw_context *brw)
else
len = 5;
+ if (depth_irb && depth_irb->region == NULL)
+ depth_irb = NULL;
+
if (!depth_irb && !stencil_irb) {
BEGIN_BATCH(len);
OUT_BATCH(_3DSTATE_DEPTH_BUFFER << 16 | (len - 2));
--
1.7.6.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 0/3] Fix several segmentation faults related to depth buffer
On Tue, Sep 06, 2011 at 03:11:25PM -0300, Eugeni Dodonov wrote: > On Mon, Sep 5, 2011 at 16:37, Alon Levy wrote: > > > Fixes three segmentation faults where it is wrongly assumed the depth > > buffer's > > renderbuffer's region is not NULL. > > > > 735794 - verified to be fixed by these three patches (these three apply > > to 7.11 almost cleanly, just the second requires minor changes). > > > > Related RHBZs (maybe solved as well, didn't reproduce): > > 734183 - [abrt] gnome-shell-3.1.4-2.gite7b9933.fc16: prepare_depthbuffer > > 717140 -[abrt] compiz-0.9.4-2.fc15: prepare_depthbuffer > > > > Alon Levy (3): > > i965: prepare_depthbuffer: fix segfault, rhbz#735794 > > i965: prepare_depthbuffer: don't update NULL region'ed surface, > >rhbz#735794 > > i965: emit_depthbuffer: fix segfault, rhbz#735794 > > > > src/mesa/drivers/dri/i965/brw_misc_state.c |7 +-- > > src/mesa/drivers/dri/i965/brw_wm_surface_state.c |3 +++ > > 2 files changed, 8 insertions(+), 2 deletions(-) > > > > > Hi Alon, > > those patches fix the crash you are having, but I am wondering why the crash > happened in the first place. E.g., we should not get to the situation where > region is NULL under normal cases. > > From what it looks like, it could happen when GPU was hung for example. > > Could you open a bug on freedesktop.org bugzilla and attach dmesg and > /sys/kernel/debug/dri/0/i915_error_state, so we could look into it further? > I haven't tried to reproduce, sorry, I will probably not get to it this week either. I do have several other display related issues (reverted my patches since, running with the recently updated mesa package in F16), but have not gotten to tracing them. > -- > Eugeni Dodonov ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] X/Graphics DevRoom at FOSDEM 2012? (4-5 February)
On Tue, Sep 13, 2011 at 10:49:33PM +0200, Luc Verhaegen wrote: > (after my short talk here at XDC chicago, let's get this out to > everyone) > > It's time again to start planning for the next FOSDEM. After our poor > showing in 2010 (where in the end openmoko got given half our time, as > we had not managed to schedule more than 3 talks 2 weeks before the > event), I didn't bother organising this for 2011. And this year I am > putting down some hard requirements before I go and talk to the FOSDEM > organizers. > > So... FOSDEM. Not that it needs more introduction... One weekend in > February, 5000+ geeks on a university campus in Brussels (not that > anyone knows exact numbers). 3 main rooms, Tons of DevRooms, 20 or so > talks in parallel, project specific booths. The biggest, and most open > free software event of Europe, probably of the world. > > We have had 5 DevRooms in a row there, and even when we had a 150 seat > room (2008), we were almost at full capacity all the time, and at times > had to refuse entrance to people (for safety reasons). In 2010, when > quite a few people had to be refused, we received remarks along the > lines of: "Why doesn't a project like X have a bigger room?" "This is > the only real opportunity we get to interact with the developers > directly" > > So... After our terrible showing in 2010, i now need more to convince > the FOSDEM organizers that we are worth of a DevRoom, that we can > deliver. So, with a deadline of oktober 1st, i am now asking for 6 > people (basically fill up saturday afternoon) to step up and promise to > hold a talk at FOSDEM, even when their employers end up not paying for > their expenses, even when there is some other conference that might turn > up in the next 5.5 months. > > Of course, these talks should not be just X, anything related to free > software and graphics goes. For example: one of the really cool talks a > few years ago was about a PCI card with an FPGA which did VGA. > > So. Get me something that i can take to the FOSDEM organizers and state > "This time, we will fill our scheduly properly", and we will have > another marvellous FOSDEM in February. > I'd like to talk about Xspice, and about plans for 3d support in spice. Spice is currently limited to qemu virtual machines, Xspice is a Xvnc like server using spice. The architecture is different in that it just implements a few drivers (which link with the spice server library) and uses Xorg binary without any changes. I can talk about the difficulties in doing that (X's select loop, too many apis for input events) 3D support - it's currently being designed. Nothing to show code/demo wise. But I hope to have a design to present by February, and would like to talk about it. > Luc Verhaegen. > ___ > 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] X/Graphics DevRoom at FOSDEM 2012? (4-5 February)
On Tue, Sep 20, 2011 at 12:32:21PM +0200, Luc Verhaegen wrote: > On Tue, Sep 20, 2011 at 12:18:15PM +0300, Alon Levy wrote: > > On Tue, Sep 13, 2011 at 10:49:33PM +0200, Luc Verhaegen wrote: > > > ... > > > deliver. So, with a deadline of oktober 1st, i am now asking for 6 > > > people (basically fill up saturday afternoon) to step up and promise to > > > hold a talk at FOSDEM, even when their employers end up not paying for > > > their expenses, even when there is some other conference that might turn > > > up in the next 5.5 months. > > > > I'd like to talk about Xspice, and about plans for 3d support in spice. > > > > Spice is currently limited to qemu virtual machines, Xspice is a Xvnc like > > server using spice. The architecture is different in that it just implements > > a few drivers (which link with the spice server library) and uses Xorg > > binary > > without any changes. I can talk about the difficulties in doing that (X's > > select loop, too many apis for input events) > > > > 3D support - it's currently being designed. Nothing to show code/demo wise. > > But I > > hope to have a design to present by February, and would like to talk about > > it. > > This sound like a rather redhat specific topic. How certain are you that > redhat is going to send you to FOSDEM, and if they don't, are you coming > regardless? > I came on my own last year (well, Red Hat didn't require me to take vacation, but that's a policy that's still in effect this year as well), and I plan to do the same this year. Also, afaik spice is being used by non Red Hat distributions (ubuntu, debian, arch) so I don't think it's a Red Hat only topic. > So far, only Martin Peres has stepped up and stated "yes! I will be > there!", and he will be happy to give FOSDEM visitors a talk about > Nouveau. > > Luc Verhaegen. > ___ > 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] gallium/test/trivial: make it build
Signed-off-by: Alon Levy --- src/gallium/tests/trivial/Makefile |9 +++-- src/gallium/tests/trivial/quad-tex.c |4 ++-- src/gallium/tests/trivial/tri.c |4 ++-- 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/src/gallium/tests/trivial/Makefile b/src/gallium/tests/trivial/Makefile index 2ed6341..e82 100644 --- a/src/gallium/tests/trivial/Makefile +++ b/src/gallium/tests/trivial/Makefile @@ -11,7 +11,12 @@ INCLUDES = \ -I$(TOP)/src/gallium/winsys \ $(PROG_INCLUDES) -LINKS = \ +ifeq ($(MESA_LLVM),1) +LINKS = $(TOP)/src/gallium/drivers/llvmpipe/libllvmpipe.a +LDFLAGS += $(LLVM_LDFLAGS) +endif + +LINKS += \ $(TOP)/src/gallium/drivers/rbug/librbug.a \ $(TOP)/src/gallium/drivers/trace/libtrace.a \ $(TOP)/src/gallium/drivers/galahad/libgalahad.a \ @@ -46,4 +51,4 @@ $(OBJECTS): %.o: %.c $(CC) -c $(INCLUDES) $(CFLAGS) $(DEFINES) $(PROG_DEFINES) $< -o $@ $(PROGS): %: %.o $(LINKS) - $(CC) $(LDFLAGS) $< $(LINKS) -lm -lpthread -ldl -o $@ + $(CC) $(LDFLAGS) $< $(LINKS) $(LLVM_LIBS) -lm -lpthread -ldl -o $@ diff --git a/src/gallium/tests/trivial/quad-tex.c b/src/gallium/tests/trivial/quad-tex.c index 3a64b1c..6c38b10 100644 --- a/src/gallium/tests/trivial/quad-tex.c +++ b/src/gallium/tests/trivial/quad-tex.c @@ -212,7 +212,7 @@ static void init_prog(struct program *p) p->sampler.mag_img_filter = PIPE_TEX_MIPFILTER_LINEAR; p->sampler.normalized_coords = 1; - surf_tmpl.format = templat.format; + surf_tmpl.format = PIPE_FORMAT_B8G8R8A8_UNORM; /* All drivers support this */ surf_tmpl.usage = PIPE_BIND_RENDER_TARGET; surf_tmpl.u.tex.level = 0; surf_tmpl.u.tex.first_layer = 0; @@ -329,7 +329,7 @@ static void draw(struct program *p) /* vertex element data */ cso_set_vertex_elements(p->cso, 2, p->velem); - util_draw_vertex_buffer(p->pipe, + util_draw_vertex_buffer(p->pipe, p->cso, p->vbuf, 0, PIPE_PRIM_QUADS, 4, /* verts */ diff --git a/src/gallium/tests/trivial/tri.c b/src/gallium/tests/trivial/tri.c index bfd2f3c..656e92e 100644 --- a/src/gallium/tests/trivial/tri.c +++ b/src/gallium/tests/trivial/tri.c @@ -153,7 +153,7 @@ static void init_prog(struct program *p) p->rasterizer.cull_face = PIPE_FACE_NONE; p->rasterizer.gl_rasterization_rules = 1; - surf_tmpl.format = templat.format; + surf_tmpl.format = PIPE_FORMAT_B8G8R8A8_UNORM; surf_tmpl.usage = PIPE_BIND_RENDER_TARGET; surf_tmpl.u.tex.level = 0; surf_tmpl.u.tex.first_layer = 0; @@ -258,7 +258,7 @@ static void draw(struct program *p) /* vertex element data */ cso_set_vertex_elements(p->cso, 2, p->velem); - util_draw_vertex_buffer(p->pipe, + util_draw_vertex_buffer(p->pipe, p->cso, p->vbuf, 0, PIPE_PRIM_TRIANGLES, 3, /* verts */ -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
