[Mesa-dev] Current tinderbox regression (r300)
http://tinderbox.x.org/builds/2010-07-12-0013/logs/libGL/#build r300_render.c: In function 'r300_blitter_draw_rectangle': r300_render.c:1064: error: expected ';' before ')' token vap_cntl_status |= R300_VC_32BIT_SWAP); http://cgit.freedesktop.org/mesa/mesa/commit/?id=78e8a8765f435bf0902d62afbcb3b8d68a0b716f -- Chris Ball One Laptop Per Child ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] pipebuffer: Use pipe_condvar instead of ifdef'd sys_yield()
I've looked and tested at your whole patch series.
As you said, condvars and barriers work now on windows albeit slowly;
which is a big improvement over not working at all as before.
However, after a more careful look to the pipebuffer change I realized
that it is counterproductive. The busy loop only happens when destroying
the context (i.e., typically once per application, often never if the
app invokes exit() before detroying the context). Your change optimizes
this unimportant case, at the expense of grabing a lock and using an
condition variables whenever the number of fences reaches zero, which is
much more often.
Note that during typical operation there is no busy loop -- pipebuffer
invokes the fence_finish() callback which should do something sensible
like waiting for an IRQ, or something like that.
Actually, even when destroying the fenced buffer manager the busy loop
never actually happens in practice. The lines
while(fenced_manager_check_signalled_locked(fenced_mgr, TRUE))
;
will destroy everything. The code looks as it is probably due to
historical reasons (in particular it's very tricky on windows to unload
the OpenGL driver DLL in some circumstances such as Ctrl+C and there was
a time where we tried to destroy the screen when contexts were still
active, but that has been fixed since).
So the code
/* Wait on outstanding fences */
while (fenced_mgr->num_fenced) {
pipe_mutex_unlock(fenced_mgr->mutex);
#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) ||
defined(PIPE_OS_SOLARIS)
sched_yield();
#endif
pipe_mutex_lock(fenced_mgr->mutex);
while(fenced_manager_check_signalled_locked(fenced_mgr, TRUE))
;
}
could be replaced by
/* Wait on outstanding fences */
if (fenced_mgr->num_fenced) {
while(fenced_manager_check_signalled_locked(fenced_mgr, TRUE))
;
}
without any loss. (Unless there is an active thread, which means the
fenced_bufmgr_destroy() shouldn't be happening at all.)
So I'll apply your patch series, except the pipebuffer change.
Jose
On Tue, 2010-07-06 at 10:45 -0700, nobled wrote:
> Well, that's why I sent the "Implement pipe_condvar on win32" and "on
> Windows Vista" patches first. With the first patch, the pipebuffer
> code will do on Windows exactly what it already does right now on
> Unix-- unlock the mutex, wait for other threads, then try to lock it
> again. pipe_condvar on Windows (or any other platform) will *work*, it
> just won't be very efficient.
>
> On Tue, Jul 6, 2010 at 6:46 AM, José Fonseca wrote:
> > The patch looks good, but we don't support pipe_condvar on Windows yet.
> > I'd prefer to see the commit deferred until we do.
> >
> > Any takers to implement pipe_condvar on Windows? There's even a nice
> > tutorial on http://locklessinc.com/articles/pthreads_on_windows/
> >
> > Jose
> >
> > On Mon, 2010-07-05 at 09:53 -0700, nobled wrote:
> >> This way there's fewer ifdef's *and* less busy-waiting.
> >> ---
> >> .../auxiliary/pipebuffer/pb_buffer_fenced.c| 19
> >> +++
> >> 1 files changed, 7 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
> >> b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
> >> index d6cf640..db3617e 100644
> >> --- a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
> >> +++ b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
> >> @@ -34,13 +34,6 @@
> >> */
> >>
> >>
> >> -#include "pipe/p_config.h"
> >> -
> >> -#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) ||
> >> defined(PIPE_OS_SOLARIS)
> >> -#include
> >> -#include
> >> -#endif
> >> -
> >> #include "pipe/p_compiler.h"
> >> #include "pipe/p_defines.h"
> >> #include "util/u_debug.h"
> >> @@ -81,6 +74,7 @@ struct fenced_manager
> >> * Following members are mutable and protected by this mutex.
> >> */
> >> pipe_mutex mutex;
> >> + pipe_condvar zero_fenced;
> >>
> >> /**
> >> * Fenced buffer list.
> >> @@ -307,6 +301,8 @@
> >> LIST_DEL(&fenced_buf->head);
> >> assert(fenced_mgr->num_fenced);
> >> --fenced_mgr->num_fenced;
> >> + if (fenced_mgr->num_fenced == 0)
> >> + pipe_condvar_broadcast(fenced_mgr->zero_fenced);
> >>
> >> LIST_ADDTAIL(&fenced_buf->head, &fenced_mgr->unfenced);
> >> ++fenced_mgr->num_unfenced;
> >> @@ -1008,13 +1004,10 @@ fenced_bufmgr_destroy(struct pb_manager *mgr)
> >>
> >> /* Wait on outstanding fences */
> >> while (fenced_mgr->num_fenced) {
> >> - pipe_mutex_unlock(fenced_mgr->mutex);
> >> -#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) ||
> >> defined(PIPE_OS_SOLARIS)
> >> - sched_yield();
> >> -#endif
> >> - pipe_mutex_lock(fenced_mgr->mutex);
> >>while(fenced_manager_check_signalled_locked(fenced_mgr, TRUE))
> >> ;
> >> + if (fenced_mgr->num_fenced)
> >> + pipe_condvar_wait(fenced_mgr->zero_fenced, fenced_mgr->mutex);
> >> }
> >>
> >> #ifdef DEBUG
> >> @@ -1023,
Re: [Mesa-dev] Bug in _mesa_meta_GenerateMipmap
Maciej Cencora wrote: Hi, while working on failing piglit tests I've stumbled on a problem with _mesa_meta_GenerateMipmap. The function creates new texture images for lower mipmap levels, but during call to glTexImage the format and type are hardcoded to GL_RGBA and GL_UNSIGNED_BYTE respectivily. And that's where the problem arise because base image (the one that other levels are generated from) could have other format and type specified (in failing test texturing/gen-teximage these are GL_RGBA, GL_FLOAT). The result is that for base image MESA_FORMAT_ARGB is chosen and for next levels it's MESA_FORMAT_RGBA_REV. Of course such texture with images of different formats is invalid and will be missampled by GPU. As the fix is not straightforward for me (not sure where to get format and type from, since the gl_texture_image doesn't hold them) could someone more familiar with core mesa take a look at this? Which driver are you using? I suspect the problem is the driver's ChooseTextureFormat() callback is using more than the 'internalFormat' parameter to choose the actual hardware format (i.e. it's also using the format/type params). Later, when we're building the mipmap we don't know the format/type params used for creating the base image so we just use GL_RGBA/GL_UNSIGNED_BYTE. We could save those original params when glTexImage2D() is called to create the base image, but that would be of no use if the base image was created with glCopyTexImage2D(). We might just be able to "poke" in the actual format for the new image to override whatever was chosen. I'll try to write a patch later... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29024] New: gallium build failure: can't find llvm headers
https://bugs.freedesktop.org/show_bug.cgi?id=29024 Summary: gallium build failure: can't find llvm headers Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: nob...@dreamwidth.org Trying to build a git checkout from today on Ubuntu Maverick with the --enable-gallium-llvm option the build fails with this: gcc -c -o state_tracker/st_cb_feedback.o state_tracker/st_cb_feedback.c -DFEATURE_GL=0 -I../../include -I../../src/mesa -I../../src/mapi -I../../src/gallium/include -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0207 In file included from ../../src/gallium/auxiliary/draw/draw_pipe.h:37, from state_tracker/st_cb_feedback.c:54: ../../src/gallium/auxiliary/draw/draw_private.h:50:36: error: llvm-c/ExecutionEngine.h: No such file or directory In file included from ../../src/gallium/auxiliary/draw/draw_pipe.h:37, from state_tracker/st_cb_feedback.c:54: ../../src/gallium/auxiliary/draw/draw_private.h:267: error: expected specifier-qualifier-list before 'LLVMExecutionEngineRef' make[2]: *** [state_tracker/st_cb_feedback.o] Error 1 It looks like it it's missing the -I from `llvm --cflags` in there: -I/usr/lib/llvm-2.7/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC Without --enable-gallium-llvm that file builds fine. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] Current tinderbox regression (r300)
I will fix it when I get off the clock. Should be trivial. Posting from a mobile, pardon my terseness. ~ C. On Jul 12, 2010 7:23 AM, "Chris Ball" wrote: http://tinderbox.x.org/builds/2010-07-12-0013/logs/libGL/#build r300_render.c: In function 'r300_blitter_draw_rectangle': r300_render.c:1064: error: expected ';' before ')' token vap_cntl_status |= R300_VC_32BIT_SWAP); http://cgit.freedesktop.org/mesa/mesa/commit/?id=78e8a8765f435bf0902d62afbcb3b8d68a0b716f -- Chris Ball One Laptop Per Child ___ 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] Current tinderbox regression (r300)
On Mon, Jul 12, 2010 at 3:02 PM, Corbin Simpson wrote: > I will fix it when I get off the clock. Should be trivial. > The build fix is trivial. Also, FWIW, that new clear function doesn't take into account non-tcl chips and should probably use a passthrough vertex shader rather than disabling PVS on tcl chips. Alex > Posting from a mobile, pardon my terseness. ~ C. > > On Jul 12, 2010 7:23 AM, "Chris Ball" wrote: > > http://tinderbox.x.org/builds/2010-07-12-0013/logs/libGL/#build > > r300_render.c: In function 'r300_blitter_draw_rectangle': > r300_render.c:1064: error: expected ';' before ')' token > > vap_cntl_status |= R300_VC_32BIT_SWAP); > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=78e8a8765f435bf0902d62afbcb3b8d68a0b716f > > -- > Chris Ball > One Laptop Per Child > ___ > 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Bug in _mesa_meta_GenerateMipmap
Dnia poniedziałek 12 lipca 2010 o 20:31:42 Brian Paul napisał(a): > Maciej Cencora wrote: > > Hi, > > > > while working on failing piglit tests I've stumbled on a problem with > > _mesa_meta_GenerateMipmap. The function creates new texture images for > > lower mipmap levels, but during call to glTexImage the format and type > > are hardcoded to GL_RGBA and GL_UNSIGNED_BYTE respectivily. And that's > > where the problem arise because base image (the one that other levels > > are generated from) could have other format and type specified (in > > failing test texturing/gen-teximage these are GL_RGBA, GL_FLOAT). > > The result is that for base image MESA_FORMAT_ARGB is chosen and for > > next levels it's MESA_FORMAT_RGBA_REV. Of course such texture with > > images of different formats is invalid and will be missampled by GPU. > > > > As the fix is not straightforward for me (not sure where to get format > > and type from, since the gl_texture_image doesn't hold them) could > > someone more familiar with core mesa take a look at this? > > Which driver are you using? > > I suspect the problem is the driver's ChooseTextureFormat() callback > is using more than the 'internalFormat' parameter to choose the actual > hardware format (i.e. it's also using the format/type params). Later, > when we're building the mipmap we don't know the format/type params > used for creating the base image so we just use GL_RGBA/GL_UNSIGNED_BYTE. > > We could save those original params when glTexImage2D() is called to > create the base image, but that would be of no use if the base image > was created with glCopyTexImage2D(). > > We might just be able to "poke" in the actual format for the new image > to override whatever was chosen. I'll try to write a patch later... > > -Brian I'm using r300 driver. As you suspect the radeonChooseTextureFormat (radeon_texture.c) function takes into account format and type to avoid unnecessary conversions in TexImage callback. Regards, Maciej ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29029] New: mesa-demos scons build fails
https://bugs.freedesktop.org/show_bug.cgi?id=29029 Summary: mesa-demos scons build fails Product: Mesa Version: git Platform: Other OS/Version: Windows (All) Status: NEW Severity: normal Priority: medium Component: Demos AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: nob...@dreamwidth.org Mesa demos git checkout: 97af09dccce27cf80b421d41449c9776aec8af6d OS: Windows XP SP3 Compiler: MSVC 10.0 (aka Visual Studio C++ 2010) The error message is different each time, and usually the text is almost completely garbled, but the scons build on Windows always fails trying to link arbfslight.exe, complaining about X number of 'unresolved externals' (the number of them keeps changing from build to build). For example: scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... Linking build\windows-x86-debug\demos\arbfplight.exe ... Linking build\windows-x86-debug\demos\arbfslight.exe ... arbfplight.obj : error LNK2019: unresolved external symbol __imp__glewInit referenced in function _main arbfplight.obj : error LNK2001: unresolved external symbol __impglewProgramLocalParameter4fvARB arbfplight.obj : error LNK2001: unresolved external symbol __impglewDeleteProgramsARB arbfplight.obj : error LNK2001: unresolved external symbol __impglewGetProgramLocalParameterdvARB arbfplight.obj : error LNK2001: unresolved external symbol __impglewProgramLocalParameter4dARB arbfplight.obj : error LNK2001: unresolved external symbol __impglewIsProgramARB arbfplight.obj : error LNK2001: unresolved external symbol __impglewProgramStringARB arbfplight.obj : error LNK2001: unresolved external symarbfsligbol __impglewBindProgramARB ahrtb.objf p: leirgrhotr. obLjN : error LNK2001: unresolKv2e0d1 9e:xternal symbol __impglewGenProgra musnArReBs obluvieldd \ewxitnedronwasl- xs8y6m-bdoelb ug\_dem_oism\pa_rb_fgplleiwgIhnitt. exre : effaetraeln cererodr in f uncLNtKi 1o120: n9 unre s_main olved externaarlbsf slight.obj : error LNK2001: unresolved external symbol __impglewUniform3fvARB arbfslight.obj : error LNK2001: unresolved external symbol __impglewUseProgramObjectARB arbfslight.obj : error LNK2001: unresolved external symbol __impglewUniform4fvARB arbfslight.obj : error Lscons: *** [build\windows-x86-debug\demos\arbfplight.exe] Error 1120 NK2001: unresolved external symbol __impglewGetUniformLocationARB arbfslight.obj : error LNK2001: unresolved external symbol __impglewLinkProgramARB arbfslight.obj : error LNK2001: unresolved external symbol __impglewAttachObjectARB arbfslight.obj : error LNK2001: unresolved external symbol __impglewCreateProgramObjectARB arbfslight.obj : error LNK2001: unresolved external symbol __impglewCompileShaderARB arbfslight.obj : error LNK2001: unresolved external symbol __impglewShaderSourceARB arbfslight.obj : error LNK2001: unresolved external symbol __impglewCreateShaderObjectARB build\windows-x86-debug\demos\arbfslight.exe : fatal error LNK1120: 11 unresolved externals scons: *** [build\windows-x86-debug\demos\arbfslight.exe] Error 1120 scons: building terminated because of errors. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] Bug in _mesa_meta_GenerateMipmap
Maciej Cencora wrote:
Dnia poniedziałek 12 lipca 2010 o 20:31:42 Brian Paul napisał(a):
Maciej Cencora wrote:
Hi,
while working on failing piglit tests I've stumbled on a problem with
_mesa_meta_GenerateMipmap. The function creates new texture images for
lower mipmap levels, but during call to glTexImage the format and type
are hardcoded to GL_RGBA and GL_UNSIGNED_BYTE respectivily. And that's
where the problem arise because base image (the one that other levels
are generated from) could have other format and type specified (in
failing test texturing/gen-teximage these are GL_RGBA, GL_FLOAT).
The result is that for base image MESA_FORMAT_ARGB is chosen and for
next levels it's MESA_FORMAT_RGBA_REV. Of course such texture with
images of different formats is invalid and will be missampled by GPU.
As the fix is not straightforward for me (not sure where to get format
and type from, since the gl_texture_image doesn't hold them) could
someone more familiar with core mesa take a look at this?
Which driver are you using?
I suspect the problem is the driver's ChooseTextureFormat() callback
is using more than the 'internalFormat' parameter to choose the actual
hardware format (i.e. it's also using the format/type params). Later,
when we're building the mipmap we don't know the format/type params
used for creating the base image so we just use GL_RGBA/GL_UNSIGNED_BYTE.
We could save those original params when glTexImage2D() is called to
create the base image, but that would be of no use if the base image
was created with glCopyTexImage2D().
We might just be able to "poke" in the actual format for the new image
to override whatever was chosen. I'll try to write a patch later...
-Brian
I'm using r300 driver. As you suspect the radeonChooseTextureFormat
(radeon_texture.c) function takes into account format and type to avoid
unnecessary conversions in TexImage callback.
Here's a patch to try. Totally untested.
-Brian
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index c548e10..4af916f 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -2439,6 +2439,15 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
}
}
+ /* Force the new/dest image to have the same actual format
+ * as the src image.
+ */
+ {
+ struct gl_texture_image *newImage =
+_mesa_get_tex_image(ctx, texObj, faceTarget, dstLevel);
+ newImage->TexFormat = srcImage->TexFormat;
+ }
+
/* limit sampling to src level */
_mesa_TexParameteri(target, GL_TEXTURE_BASE_LEVEL, srcLevel);
_mesa_TexParameteri(target, GL_TEXTURE_MAX_LEVEL, srcLevel);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] dri/r300: test for FEATURE defines
Fixes a fatal build error when compiling just OpenGL ES libraries, since
FEATURE_EXT_framebuffer_blit is disabled then, so the BlitFramebuffer
member doesn't exist.
---
src/mesa/drivers/dri/radeon/radeon_fbo.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c
b/src/mesa/drivers/dri/radeon/radeon_fbo.c
index 5174850..0597d42 100644
--- a/src/mesa/drivers/dri/radeon/radeon_fbo.c
+++ b/src/mesa/drivers/dri/radeon/radeon_fbo.c
@@ -609,6 +609,7 @@ radeon_validate_framebuffer(GLcontext *ctx, struct
gl_framebuffer *fb)
void radeon_fbo_init(struct radeon_context *radeon)
{
+#if FEATURE_EXT_framebuffer_object
radeon->glCtx->Driver.NewFramebuffer = radeon_new_framebuffer;
radeon->glCtx->Driver.NewRenderbuffer = radeon_new_renderbuffer;
radeon->glCtx->Driver.BindFramebuffer = radeon_bind_framebuffer;
@@ -617,7 +618,10 @@ void radeon_fbo_init(struct radeon_context *radeon)
radeon->glCtx->Driver.FinishRenderTexture = radeon_finish_render_texture;
radeon->glCtx->Driver.ResizeBuffers = radeon_resize_buffers;
radeon->glCtx->Driver.ValidateFramebuffer = radeon_validate_framebuffer;
+#endif
+#if FEATURE_EXT_framebuffer_blit
radeon->glCtx->Driver.BlitFramebuffer = _mesa_meta_BlitFramebuffer;
+#endif
}
--
1.6.3.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29033] New: can't build dri drivers with just GLES
https://bugs.freedesktop.org/show_bug.cgi?id=29033
Summary: can't build dri drivers with just GLES
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: nob...@dreamwidth.org
Building with `./configure --enable-gles-overlay --disable-opengl' fails when
it tries to link the radeon dri driver. It looks like the missing references
are in src/mesa/main/api_exec.c, and based on the comment in the code it's a
known problem?
---
/bin/bash ../../../../../bin/mklib -o radeon_dri.so.tmp -noprefix -linker 'gcc'
-ldflags '' \
../common/utils.o ../common/vblank.o ../common/dri_util.o
../common/xmlconfig.o ../../common/driverfuncs.o ../common/texmem.o
../common/drirenderbuffer.o ../common/dri_metaops.o radeon_context.o
radeon_ioctl.o radeon_screen.o radeon_state.o radeon_state_init.o radeon_tex.o
radeon_texstate.o radeon_tcl.o radeon_swtcl.o radeon_maos.o radeon_sanity.o
radeon_blit.o radeon_bo_legacy.o radeon_common_context.o radeon_common.o
radeon_cs_legacy.o radeon_dma.o radeon_debug.o radeon_fbo.o radeon_lock.o
radeon_mipmap_tree.o radeon_pixel_read.o radeon_queryobj.o radeon_span.o
radeon_texture.o radeon_tex_copy.o radeon_tex_getimage.o radeon_tile.o
../../../../../src/mesa/libmesa.a -lselinux -ldrm -lexpat -lm -lpthread
-ldl -ldrm_radeon -ldrm
mklib: Making Linux shared library: radeon_dri.so.tmp
gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM
-DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX
-DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV
-DHAVE_LIBDRM_RADEON=1 -I/usr/include/libdrm -DFEATURE_GL=0 -o
radeon_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o
radeon_dri.so.tmp -lselinux -ldrm -lexpat -lm -lpthread -ldl -ldrm_radeon
-ldrm
radeon_dri.so.tmp: undefined reference to `driDispatchRemapTable'
radeon_dri.so.tmp: undefined reference to `_mesa_map_static_functions'
collect2: ld returned 1 exit status
make[6]: *** [radeon_dri.so] Error 1
---
/* This is shared across all APIs but We define this here since
* desktop GL has the biggest remap table. */
int driDispatchRemapTable[driDispatchRemapTable_size];
/**
* Map the functions which are already static.
*
* When a extension function are incorporated into the ABI, the
* extension suffix is usually stripped. Mapping such functions
* makes sure the alternative names are available.
*
* Note that functions mapped by _mesa_init_remap_table() are
* excluded.
*/
void
_mesa_map_static_functions(void)
{
/* Remap static functions which have alternative names and are in the ABI.
* This is to be on the safe side. glapi should have defined those names.
*/
_mesa_map_function_array(MESA_alt_functions);
}
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] dri/nouveau: test for FEATURE defines
BlitFramebuffer only exists if FEATURE_EXT_framebuffer_blit is enabled. --- src/mesa/drivers/dri/nouveau/nouveau_driver.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/nouveau/nouveau_driver.c b/src/mesa/drivers/dri/nouveau/nouveau_driver.c index 4ec864c..6452fe2 100644 --- a/src/mesa/drivers/dri/nouveau/nouveau_driver.c +++ b/src/mesa/drivers/dri/nouveau/nouveau_driver.c @@ -138,5 +138,7 @@ nouveau_driver_functions_init(struct dd_function_table *functions) functions->DrawPixels = _mesa_meta_DrawPixels; functions->CopyPixels = _mesa_meta_CopyPixels; functions->Bitmap = _mesa_meta_Bitmap; +#if FEATURE_EXT_framebuffer_blit functions->BlitFramebuffer = _mesa_meta_BlitFramebuffer; +#endif } -- 1.6.3.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Merging mesa-2d-registers
Hey, this is relatively simple: Mesa GPU instructions had no way of representing 2D register arrays which was especially painful for things like geometry shaders. It's the same thing Gallium supported for a while meaning INPUT[index1][index2] syntax. So for example gl_PositionIn[index] becomes INPUT[index][gl_PositionIn], so the first index is the index within the array and the second identifies the semantic of the array. This merge finally brings working ARB_geometry_shader4 to Mesa3D! For drivers that use Gallium3D the change means absolutely nothing (of course besides the fact that if the driver had implemented Gallium's geometry shader interface then it gets ARB_geometry_shader4 support for free). There's a nice example called bezier in demos/src/glsl/bezier.c that uses geometry shaders to render a bezier curve. Oh, and also both llvmpipe and softpipe drivers support geometry shaders. z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
