headers
bugzilla-daemon | 1 Feb 2012 01:12

[Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

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

--- Comment #8 from Kevin DeKorte <kdekorte <at> yahoo.com> 2012-01-31 16:12:40 PST ---
I had this working yesterday and with the patch in bug #45466 I can get to
compile again.

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
Carl Worth | 1 Feb 2012 01:19
Favicon
Gravatar

[PATCH] glsl: Implement ralloc with talloc

Since talloc has more debugging features than ralloc, such as the
very useful:

	 talloc_report_full(ctx, stdout);

we here conditionally implement ralloc by simply calling directly into
talloc.

NOTE: This commit is simply example code that I used recently, and I
thought I should share in case someone else might find useful. I'm not
proposing pushing it upstream in its current state. If there is any
interest in pushing this upstream, at least the following would need
to be done:

* The hard-coded #define of RALLOC_USE_TALLOC should be removed from
  ralloc.h and some configuration mechanism should instead be provided
  so that the user can choose to build with talloc.

* Said configuration mechanism should also arrange for linking with
  -ltalloc. In the meantime, a user can do:

	LDFLAGS=-ltalloc ./autogen.sh

Some other things could be done that aren't strictly necessary, but
might be nice for cleaner code:

* The three blocks of "#if ! RALLOC_USE_TALLOC" in ralloc.c could be
  reduced to one by simply moving some code around. I didn't do this
  simply to avoid making the patch look more involved than it actually
  is.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Paul | 1 Feb 2012 02:32
Favicon

Re: undefined C++ GLSL symbol error

On 01/31/2012 02:44 PM, Zack Rusin wrote:
> On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:
>>> $ make>log
>>> ar: creating libglapi.a
>>> ar: creating libmesa.a
>>> ar: libmesa.a: Error reading ../../src/glsl/.libs/: Is a directory
>>> ar: creating libmesagallium.a
>>> ar: libmesagallium.a: Error reading ../../src/glsl/.libs/: Is a directory
>>> ar: creating libegl_glx.a
>>> ar: creating libgallium.a
>
> Getting similar error, but my build doesn't finish:
>
> $ make realclean
> $ git clean -fxd
> $ ./autogen.sh --with-gallium-drivers=svga -with-dri-drivers= --enable-xa
> $ make
>   ar: creating libmesa.a
>   ar: ../../src/glsl/.libs/: File format not recognized
>   ranlib: 'libmesa.a': No such file
>   ar: creating libmesagallium.a
>   ar: ../../src/glsl/.libs/: File format not recognized
>   ranlib: 'libmesagallium.a': No such file
> ...
>   make[3]: *** No rule to make target '../../../../src/mesa/libmesagallium.a',
> needed by 'vmwgfx_dri.so'.Stop.
>   make[3]: Leaving directory '/home/zack/src/mesa/gallium/targets/dri-vmwgfx'
>
>> I'll keep looking.
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Brian Paul | 1 Feb 2012 02:34
Favicon

[PATCH 1/2] mesa: use new _mesa_reference_shared_state() function

This cleans up the reference counting of shared context state.
The next patch will use this to fix an actual bug.

NOTE: This is a candidate for the 8.0 branch.
---
 src/mesa/main/context.c |   28 ++++++++++++--------------
 src/mesa/main/shared.c  |   48 +++++++++++++++++++++++++++++-----------------
 src/mesa/main/shared.h  |   11 +++++----
 3 files changed, 49 insertions(+), 38 deletions(-)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index f39cab5..43e7438 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
 <at>  <at>  -939,13 +939,10  <at>  <at>  _mesa_initialize_context(struct gl_context *ctx,
          return GL_FALSE;
    }

-   _glthread_LOCK_MUTEX(shared->Mutex);
-   ctx->Shared = shared;
-   shared->RefCount++;
-   _glthread_UNLOCK_MUTEX(shared->Mutex);
+   _mesa_reference_shared_state(ctx, &ctx->Shared, shared);

    if (!init_attrib_groups( ctx )) {
-      _mesa_release_shared_state(ctx, ctx->Shared);
+      _mesa_reference_shared_state(ctx, &ctx->Shared, NULL);
       return GL_FALSE;
    }
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brian Paul | 1 Feb 2012 02:34
Favicon

[PATCH 2/2] mesa: reference shared state in glPushAttrib(GL_TEXTURE_BIT)

This fixes a dangling texture object pointer bug hit via wglShareLists().
When we push the GL_TEXTURE_BIT state we may push references to the default
texture objects which are owned by the gl_shared_state object.  We don't
want to accidentally delete that shared state while the attribute stack
references shared objects.  So keep a reference to it.

NOTE: This is a candidate for the 8.0 branch.
---
 src/mesa/main/attrib.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 01e7945..1068dd8 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
 <at>  <at>  -47,6 +47,7  <at>  <at> 
 #include "multisample.h"
 #include "points.h"
 #include "polygon.h"
+#include "shared.h"
 #include "scissor.h"
 #include "stencil.h"
 #include "texenv.h"
 <at>  <at>  -165,6 +166,13  <at>  <at>  struct texture_state
     * deleted while saved in the attribute stack).
     */
    struct gl_texture_object *SavedTexRef[MAX_TEXTURE_UNITS][NUM_TEXTURE_TARGETS];
+
+   /* We need to keep a reference to the shared state.  That's where the
+    * default texture objects are kept.  We don't want that state to be
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 1 Feb 2012 02:45

[Bug 45420] undefined reference to `LLVMInitializeARMDisassembler'

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

Vinson Lee <vlee <at> freedesktop.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #3 from Vinson Lee <vlee <at> freedesktop.org> 2012-01-31 17:45:38 PST ---
mesa: b0337b679ad4c2feae59215104cfa60b58a619d5 (master)

$ llvm-config --version
2.7

$ scons
[...]
  Linking build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend ...
build/linux-x86_64-debug/gallium/auxiliary/libgallium.a(lp_bld_debug.os): In
function `llvm::InitializeAllAsmPrinters()':
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeMBlazeAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeBlackfinAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeSystemZAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeMSP430AsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeXCoreAsmPrinter'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Paul | 1 Feb 2012 03:05
Picon

Re: [PATCH] mesa: Convert colors if span ChanType and renderbuffer data type don't match

On Tue, Jan 31, 2012 at 4:47 PM, Ian Romanick <idr <at> freedesktop.org> wrote:
> From: Ian Romanick <ian.d.romanick <at> intel.com>
>
> This is a partial revert of f9874fe.  It turns out that the types
> don't always match.  Specifically, this can happen when doing
> glCopyPixels from a float FBO to a RGBA8 FBO.
>
> Signed-off-by: Ian Romanick <ian.d.romanick <at> intel.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45429
> ---
>  src/mesa/swrast/s_span.c |   19 +++++++++++++++----
>  1 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/swrast/s_span.c b/src/mesa/swrast/s_span.c
> index 28f2f3d..422d86c 100644
> --- a/src/mesa/swrast/s_span.c
> +++ b/src/mesa/swrast/s_span.c
>  <at>  <at>  -1321,12 +1321,23  <at>  <at>  _swrast_write_rgba_span( struct gl_context *ctx, SWspan *span)
>          if (rb) {
>             GLchan rgbaSave[MAX_WIDTH][4];
>
> -            if (span->array->ChanType == GL_UNSIGNED_BYTE) {
> -               span->array->rgba = span->array->rgba8;
> +           GLenum datatype;
> +           GLuint comps;
> +
> +           _mesa_format_to_type_and_comps(rb->Format, &datatype, &comps);
> +
> +            /* set span->array->rgba to colors for render buffer's datatype */
> +            if (datatype != span->array->ChanType) {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Paul | 1 Feb 2012 03:05
Picon

Re: [PATCH] mesa: Convert colors if span ChanType and renderbuffer data type don't match

On Tue, Jan 31, 2012 at 7:05 PM, Brian Paul <brian.e.paul <at> gmail.com> wrote:
> On Tue, Jan 31, 2012 at 4:47 PM, Ian Romanick <idr <at> freedesktop.org> wrote:
>> From: Ian Romanick <ian.d.romanick <at> intel.com>
>>
>> This is a partial revert of f9874fe.  It turns out that the types
>> don't always match.  Specifically, this can happen when doing
>> glCopyPixels from a float FBO to a RGBA8 FBO.
>>
>> Signed-off-by: Ian Romanick <ian.d.romanick <at> intel.com>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45429
>> ---
>>  src/mesa/swrast/s_span.c |   19 +++++++++++++++----
>>  1 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/mesa/swrast/s_span.c b/src/mesa/swrast/s_span.c
>> index 28f2f3d..422d86c 100644
>> --- a/src/mesa/swrast/s_span.c
>> +++ b/src/mesa/swrast/s_span.c
>>  <at>  <at>  -1321,12 +1321,23  <at>  <at>  _swrast_write_rgba_span( struct gl_context *ctx, SWspan *span)
>>          if (rb) {
>>             GLchan rgbaSave[MAX_WIDTH][4];
>>
>> -            if (span->array->ChanType == GL_UNSIGNED_BYTE) {
>> -               span->array->rgba = span->array->rgba8;
>> +           GLenum datatype;
>> +           GLuint comps;
>> +
>> +           _mesa_format_to_type_and_comps(rb->Format, &datatype, &comps);
>> +
>> +            /* set span->array->rgba to colors for render buffer's datatype */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Turner | 1 Feb 2012 03:26
Picon

Re: undefined C++ GLSL symbol error

On Tue, Jan 31, 2012 at 8:32 PM, Brian Paul <brianp <at> vmware.com> wrote:
> On 01/31/2012 02:44 PM, Zack Rusin wrote:
>>
>> On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:
>>>>
>>>> $ make>log
>>>> ar: creating libglapi.a
>>>> ar: creating libmesa.a
>>>> ar: libmesa.a: Error reading ../../src/glsl/.libs/: Is a directory
>>>> ar: creating libmesagallium.a
>>>> ar: libmesagallium.a: Error reading ../../src/glsl/.libs/: Is a
>>>> directory
>>>> ar: creating libegl_glx.a
>>>> ar: creating libgallium.a
>>
>>
>> Getting similar error, but my build doesn't finish:
>>
>> $ make realclean
>> $ git clean -fxd
>> $ ./autogen.sh --with-gallium-drivers=svga -with-dri-drivers= --enable-xa
>> $ make
>>  ar: creating libmesa.a
>>  ar: ../../src/glsl/.libs/: File format not recognized
>>  ranlib: 'libmesa.a': No such file
>>  ar: creating libmesagallium.a
>>  ar: ../../src/glsl/.libs/: File format not recognized
>>  ranlib: 'libmesagallium.a': No such file
>> ...
>>  make[3]: *** No rule to make target
(Continue reading)

Permalink | Reply | 6 comments |
headers
Adam Jackson | 1 Feb 2012 04:06
Picon
Favicon

Re: [PATCH] Do not use sched_yield() on Linux

On 1/31/12 12:30 PM, Alan Swanson wrote:
> As discussed back in 2003, sched_yield() on Linux is no longer
> equivalent to other POSIX variations. From a LWN article; "This call
> used to simply move the process to the end of the run queue; now it
> moves the process to the "expired" queue, effectively cancelling the
> rest of the process's time slice. So a process calling sched_yield() now
> must wait until all other runnable processes in the system have used up
> their time slices before it will get the processor again."
>
> However its use on Linux has sneaked back in causing suboptimal
> performance such as reported by Simon Farnsworth on r600g. Use sleep on
> Linux instead.

Any reason why that can't be pthread_cond_wait() instead?  Explicit 
sleeps are a sin.

- ajax
Permalink | Reply | 0 comments |

Gmane