Hi,
Does bypass_vs_clip_and_viewport influence vertex fetch?
I thought vertex transform engine is behind vertex shader, that means,
bypass_vs_clip_and_viewport will not impact vertex fetch.
But when I debug glClear issue on r500 gallium driver, if driver disable
VTE, the color data can't be fetch
can also implement the operation by filling a furface,
which one is prefered?
Could you please tell me the difference between mesa/state tracker and
gallium/state tracker?
Cooper
On Tue, Aug 18, 2009 at 6:49 AM, Keith Whitwell wrote:
> On Tue, 2009-08-18 at 05:25 -0700, Cooper Yuan wr
I see! Thank you all.
On Tue, Aug 18, 2009 at 8:18 AM, Brian Paul wrote:
> Cooper Yuan wrote:
>
>> I got it, thanks! Actually, in function st_init_clear(), if I set
>> bypass_vs_clip_and_viewport as 0, things get better.
>> Another question is about the function clear
Do you implement scaling and CSC in one pixel shader?
Cooper
On Fri, Sep 18, 2009 at 1:44 AM, Younes Manton wrote:
> On Thu, Sep 17, 2009 at 1:26 PM, Corbin Simpson
> wrote:
> > On 09/17/2009 10:21 AM, Younes Manton wrote:
> >> On Thu, Sep 17, 2009 at 12:43 PM, Zack Rusin wrote:
> >>> Hey,
> >
Great!
probably libXvMCg3dvl.so can load device dependent xvmc driver dynamics
according to current device, for example, libnouveau_dri.so and
libradeon_dri.so.
btw, the context and screen are related to DRI, I am changing them to DRI2
in order to use gallium 3d functions.
Cooper
On Mon, Sep 21, 2
Hi All,
The dri1 client files in mesa/src/driclient provide some useful interfaces,
I want to know is there a need to provide similar interfaces for dri2
client?
Cooper
--
Come build with us! The BlackBerry® Developer Con
great!
so gallium/auxiliary/vl generate libvl.a,
and gallium/state_trackers/xorg/xvmc generate libxvmctracker.a
and state_trackers/g3dvl is useless.
are they right?
>From which directory to create libxvmcg3dvl.so which will be loaded by xvmc
wrapper?
are you going to move winsys/g3dvl to winsys/x
line 133:
info->input_semantic_name[reg] = (ubyte)fulldecl->Semantic.SemanticName;
Cooper
On Mon, Sep 28, 2009 at 6:01 PM, Keith Whitwell wrote:
> On Mon, 2009-09-28 at 02:56 -0700, Cooper Yuan wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 99e1745af9a6a1fe1ebc65
aha, good enough, these bits should be cleared if ps doesn't use frag.pos.
Cooper
On Tue, Sep 29, 2009 at 3:16 PM, Andre Maasikas wrote:
> it was not cleared anywhere else afaics
>
> Andre
>
>
> --
> Come build with us!
Hi Brian,
for non-mipmap case, the value of LastLevel might be wrong. because the
function st_finalize_texture() might be called from non-mipmap case.
The MaxLevel is related to log2(texture width), for non-mipmap case, I think
the LastLevel should be the same as BaseLevel.
Cooper
On Tue, Sep 29
how about this patch, considering both mipmap and non-mipmap cases.
Cooper
On Wed, Sep 30, 2009 at 12:49 PM, Cooper Yuan wrote:
> Hi Brian,
>
> for non-mipmap case, the value of LastLevel might be wrong. because the
> function st_finalize_texture() might be called from non-mipmap
11 matches
Mail list logo
