Re: [Mesa-dev] [PATCH 2/2] pb_bufmgr_cache: add is_buffer_busy hook and use it instead of non-blocking map

2011-02-13 Thread Dave Airlie
>>    if(buf->base.base.size < size) >>       return 0; >> >> @@ -242,13 +240,10 @@ pb_cache_is_buffer_compat(struct pb_cache_buffer >> *buf, >>    if(!pb_check_usage(desc->usage, buf->base.base.usage)) >>       return 0; >> >> -   map = pb_map(buf->buffer, PB_USAGE_DONTBLOCK, NULL); >> -   if (!ma

Re: [Mesa-dev] [PATCH 2/2] pb_bufmgr_cache: add is_buffer_busy hook and use it instead of non-blocking map

2011-02-13 Thread Marek Olšák
On Mon, Feb 14, 2011 at 8:12 AM, Marek Olšák wrote: > This is cleaner and implementing the hook is optional. > --- > src/gallium/auxiliary/pipebuffer/pb_bufmgr.h |4 > src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c | 11 +++ > 2 files changed, 7 insertions(+), 8 dele

[Mesa-dev] [PATCH 2/2] pb_bufmgr_cache: add is_buffer_busy hook and use it instead of non-blocking map

2011-02-13 Thread Marek Olšák
This is cleaner and implementing the hook is optional. --- src/gallium/auxiliary/pipebuffer/pb_bufmgr.h |4 src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c | 11 +++ 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/src/gallium/auxiliary/pipebuffer/pb_bufmg

[Mesa-dev] [PATCH 1/2] gallium: add usage parameter to pipe_buffer_create

2011-02-13 Thread Marek Olšák
And set a reasonable buffer usage flag everywhere instead of just PIPE_USAGE_DEFAULT. --- src/gallium/auxiliary/util/u_blit.c|1 + src/gallium/auxiliary/util/u_gen_mipmap.c |1 + src/gallium/auxiliary/util/u_index_modify.c|3 ++ src/gallium/auxiliary/ut

Re: [Mesa-dev] [PATCH v3] mesa: Optionally build a dricore support library (v3)

2011-02-13 Thread Christopher James Halse Rogers
On Sat, 2011-02-12 at 15:19 +0100, Sedat Dilek wrote: > Hi, > > here on radeon RV250 I can only use swrast DRI driver. > > [ Xorg.log ] > ... > [ 3354.432] (EE) AIGLX error: Calling driver entry point failed > [ 3354.432] (EE) AIGLX: reverting to software rendering > ... > > My autogen-line lo

Re: [Mesa-dev] A question about TGSI->LLVM IR conversion

2011-02-13 Thread Jose Fonseca
You're seeing the expected result. gallivm current implementation is geared towards TGSI -> CPU SIMD processing for both draw and llvmpipe modules. SSE has 128 bits, therefore, in SOA mode, it can process four instances of a TGSI shader. This is defined in src/gallium/auxiliary/gallivm/lp_bld_

Re: [Mesa-dev] A question about TGSI->LLVM IR conversion

2011-02-13 Thread Jerome Glisse
On Sun, Feb 13, 2011 at 2:45 PM, Christian König wrote: > Hi, > > I'm currently playing around a bit with the TGSI->LLVM IR conversion > found in the llvmpipe/gallivm driver. While doing so I managed to hock > into the r600g shader generation a call to lp_build_tgsi_soa and dumping > the resulting

Re: [Mesa-dev] [PATCH 0/6] Mesa/Gallium vertex array state optimizations

2011-02-13 Thread Marek Olšák
On Sun, Feb 13, 2011 at 8:45 PM, Keith Whitwell wrote: > Marek, > > These patches look good, but have you covered the case where the > application is changing the contents of vertex arrays without > rebinding/notifying GL in any way? > > eg. an app could do: > > memcpy(varray, foo, ...); > gl

[Mesa-dev] A question about TGSI->LLVM IR conversion

2011-02-13 Thread Christian König
Hi, I'm currently playing around a bit with the TGSI->LLVM IR conversion found in the llvmpipe/gallivm driver. While doing so I managed to hock into the r600g shader generation a call to lp_build_tgsi_soa and dumping the resulting LLVM IR additionally to the TGSI and R600 assembler representation.

Re: [Mesa-dev] [PATCH 0/6] Mesa/Gallium vertex array state optimizations

2011-02-13 Thread Keith Whitwell
Marek, These patches look good, but have you covered the case where the application is changing the contents of vertex arrays without rebinding/notifying GL in any way? eg. an app could do: memcpy(varray, foo, ...); glDrawArrays(...); memcpy(varray, bar, ...); glDrawArrays(...); wi