Hi Xavier,
On Sun, 2010-02-21 at 11:29 -0800, Xavier Chantry wrote:
Since commit c6509f89 , scons dri=no drivers=softpipe (or llvmpipe) no
longer works.
It does show a warning at the beginning :
warning: trace pipe driver disabled: skipping build of xlib libGL.so
But it does not stop
On Mon, 22 Feb 2010 08:38:49 -0800, Brian Paul bri...@vmware.com wrote:
Starting a new thread on this...
Here's a proposal of things to remove from the Mesa tree.
GLU:
glu/mini
glu/mesa
GLUT:
glut/fbdev
glut/ggi
glut/directfb
glut/dos
glut/mini
glut/os2
non-DRI drivers:
The cache manager stores buffers with a reference count that dropped to 0.
pipe_reference asserts in this case on debug builds,
so use pipe_reference_init instead.
---
src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
A return of 0 means the fence is signalled.
---
.../auxiliary/pipebuffer/pb_buffer_fenced.c|2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
index
On Mon, 2010-02-22 at 06:34 -0800, José Fonseca wrote:
On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
Hi José,
the attached patch fixes incorrect swizzles in u_format.csv. There are
basically just 2 drivers which depend on the swizzles in this table:
llvmpipe and r300g. Since
Good catch of the fence_signalled
negated logic.
This was actually mentioned on IRC by Maarten Maathuis (who was
working on adding pipebuffer support to the nv50 driver).
Thanks to him :)
--
Download Intel#174;
On Tue, 2010-02-23 at 12:27 -0800, Brian Paul wrote:
José Fonseca wrote:
On Mon, 2010-02-22 at 06:34 -0800, José Fonseca wrote:
On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
Hi José,
the attached patch fixes incorrect swizzles in u_format.csv. There are
basically just 2
On Tue, Feb 23, 2010 at 10:18 AM, José Fonseca jfons...@vmware.com wrote:
But there is another thing that we can do: take out trace from the scons
options and always built it, as there are so many state trackers and
winsys that rely on it for debug building, and trace can really build
anywhere
While keeping up-to-date the nouveau mesa driver (either classic or
gallium), or doing regression testing, the big majority of my rebuilds
resulted in segfaults.
I am not talking about autogen or configure detection. I believe this
also works automatically in other projects and doesn't with mesa,
+ if (flags PIPE_BUFFER_USAGE_UNSYNCHRONIZED) {
This should be:
if (!(flags PIPE_BUFFER_USAGE_UNSYNCHRONIZED)) {
Sorry for this.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself.
On Tue, Feb 23, 2010 at 1:29 PM, Xavier Chantry
chantry.xav...@gmail.com wrote:
While keeping up-to-date the nouveau mesa driver (either classic or
gallium), or doing regression testing, the big majority of my rebuilds
resulted in segfaults.
I am not talking about autogen or configure
I am basically ok with anything that would let me correctly convert the
format description into hardware-specific bits with *no* workarounds (for
both vertex data and samplers).
On Tue, Feb 23, 2010 at 6:20 PM, José Fonseca jfons...@vmware.com wrote:
On Mon, 2010-02-22 at 06:34 -0800, José
Hi list,
We at LunarG are working on resource sharing between EGL and its rendering and
non-rendering APIs. The resource sharing is at the driver level and it enables
us to properly support various EGLImage extensions for EGL/OpenGL|ES/OpenVG as
well as OpenMax's OMX_UseEGLImage.
We would like
On Tue, Feb 23, 2010 at 18:05, Chia-I Wu olva...@gmail.com wrote:
Hi list,
We at LunarG are working on resource sharing between EGL and its rendering and
non-rendering APIs. The resource sharing is at the driver level and it
enables
us to properly support various EGLImage extensions for
On Wed, Feb 24, 2010 at 11:25 AM, Stephane Marchesin
stephane.marche...@gmail.com wrote:
On Tue, Feb 23, 2010 at 18:05, Chia-I Wu olva...@gmail.com wrote:
Hi list,
We at LunarG are working on resource sharing between EGL and its rendering
and
non-rendering APIs. The resource sharing is at
On Tue, Feb 23, 2010 at 9:38 PM, Chia-I Wu olva...@gmail.com wrote:
This patch series moves
src/mesa/dispatch.c to src/glapi/glapi_dispatch.c and
src/glapi/dispatch.h to src/mesa/dispatch.h.
As can be seen in sources.mak, dispatch.c is actually a glapi source file.
And
although not
Hi, friends:
Sorry for my junior level question first, but I don't know where I can get
it been answered. I have post it to dri-devel list but nobody seems
interested, so I hope anyone here can help me.
As I know, DMA/CommandParser can provide asynchronous execuation of graphics
commands with
On Tue, Feb 23, 2010 at 21:06, Westermann Fu westerman...@gmail.com wrote:
Hi, friends:
Sorry for my junior level question first, but I don't know where I can get
it been answered. I have post it to dri-devel list but nobody seems
interested, so I hope anyone here can help me.
As I know,
Thanks very much
As the example when FIFO is full, maybe the 17th or 33th vertex will wait
for there is room again, so the block happens, I agree. But for correctness,
need software special handling? I mean after each time a triangle is feeding
to GPU, then, should software wait for some status
On Tue, Feb 23, 2010 at 22:54, Westermann Fu westerman...@gmail.com wrote:
Thanks very much
As the example when FIFO is full, maybe the 17th or 33th vertex will wait
for there is room again, so the block happens, I agree. But for correctness,
need software special handling? I mean after each
Please review! Attached patch marks compressed formats as unsupported and
unsupported texture formats will now fail to validate. This makes the command
stream checker happier preventing the following kernel output:
radeon :01:00.0: texture bo too small (256 256 4 0 - 262144 have 94208)
21 matches
Mail list logo
