On Mon, Mar 15, 2010 at 9:35 AM, Luca Barbieri wrote:
> ---
> src/gallium/drivers/nv40/nv40_transfer.c | 181
> --
> 1 files changed, 0 insertions(+), 181 deletions(-)
> delete mode 100644 src/gallium/drivers/nv40/nv40_transfer.c
>
> diff --git a/src/gallium/drivers
On Sat, Mar 13, 2010 at 1:29 PM, Luca Barbieri wrote:
> Currently the nv30 and nv40 Gallium drivers are very similar, and
> contain about 5000 lines of essentially duplicate code.
>
> I prepared a patchset (which can be found at
> http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unificatio
On Mon, Feb 8, 2010 at 11:51 PM, Luca Barbieri wrote:
>> Map/unmap make it all the way to the user's program, and there will
>> likely be cases where user code maps/unmaps a buffer multiple times
>> before drawing. The current transfer semantics can handle that with
>> zero-copy if the state track
On Mon, Feb 8, 2010 at 10:24 PM, Luca Barbieri wrote:
>> By making transfers context-private and non-shareable, it becomes
>> possible for a driver to implement interleaved drawing and dma-uploads
>> within a single command buffer.
>
> While we do this, how about removing transfer map and unmap fu
On Fri, Jan 22, 2010 at 11:41 AM, Keith Whitwell wrote:
> Christoph,
>
> The vertex usage issue is a bug and can be fixed.
>
> It sounds like you're really asking for another flag that indicates the
> expected lifetime of the buffer. That sounds orthogonal to the ones we
> already have describi
On Mon, Jan 18, 2010 at 9:10 PM, Chia-I Wu wrote:
> On Tue, Jan 19, 2010 at 7:58 AM, Luca Barbieri wrote:
>> The XImage backend keeps a transfer permanently and map/unmaps to do
>> modifications.
>> However, Gallium transfers can be implemented by making and keeping a
>> copy of the surface, flus
On Tue, Jan 12, 2010 at 9:44 AM, Keith Whitwell wrote:
> On Tue, 2010-01-12 at 06:33 -0800, Roland Scheidegger wrote:
>> >>>
>> >>> Profile 7 (2009)6 (2008)
>> 5
>> >>> (2006)4 (2004)3 (2003)2 (2002) 1
>> (2000)
>> >>> Fragment Sh
On Mon, Dec 21, 2009 at 3:02 AM, Corbin Simpson
wrote:
> So, yet another thing that r300 sucks balls at: NPOT textures. We've
> been talking it over on IRC, and here's the options.
>
> 1) Don't do NPOT. Stop advertising PIPE_CAP_NPOT, refuse to accept
> non-NPOT dimensions on textures. This sucks
On Mon, Dec 14, 2009 at 11:42 AM, Corbin Simpson
wrote:
> As far as immediate verts, why don't we just add support to r300g to switch
> to immediate mode for small VBOs?
>
> Posting from a mobile, pardon my terseness. ~ C.
That was what I was thinking for Nouveau, silently create a user
buffer fo
On Thu, Dec 10, 2009 at 3:34 PM, Zack Rusin wrote:
> On Thursday 10 December 2009 15:14:46 Younes Manton wrote:
>> OK, so we seem to be on the same page here, pipe_context will get some
>> more functions. That's what I was originally asking about, will
>> pipe_context g
On Thu, Dec 10, 2009 at 3:03 PM, Zack Rusin wrote:
> On Thursday 10 December 2009 14:35:47 Younes Manton wrote:
>> Well how do we keep the compute state seperate from the 3D state, and
>> how do you mix the two?
>
> It's really the same state. You bind a compute
On Thu, Dec 10, 2009 at 11:44 AM, Zack Rusin wrote:
> On Thursday 10 December 2009 11:25:48 Younes Manton wrote:
>> On Thu, Dec 10, 2009 at 5:32 AM, Zack Rusin wrote:
>> > On Wednesday 09 December 2009 20:30:56 Igor Oliveira wrote:
>> >> Hi Zack,
>> >&
On Thu, Dec 10, 2009 at 5:32 AM, Zack Rusin wrote:
> On Wednesday 09 December 2009 20:30:56 Igor Oliveira wrote:
>> Hi Zack,
>>
>> 1) agreed. OpencCL is a complete different project and should exist in
>> a different repository.
>> 1.1) Well use Gallium as CPU backend is a software dilemma:
>> "Al
On Tue, Dec 8, 2009 at 9:55 AM, michal wrote:
> This branch simplifies pipe/p_format.h by making enum pipe_format what
> it should have been -- an enum.
>
> As a result there is no extra information encoded in it and one needs to
> use auxiliary/util/u_format.h to get that info instead. Linking to
Is there anything in the spec or mesa internals that say this isn't
allowed? I was trying to fix what seems like an unrelated HW errata
with no luck, but it might as well be used if it's useful. I'll apply
if no one raises any concerns.
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/stat
On Mon, Nov 9, 2009 at 2:35 PM, Keith Whitwell wrote:
> On Sat, 2009-11-07 at 16:47 -0800, Younes Manton wrote:
>> Module: Mesa
>> Branch: pipe-video
>> Commit: e57f7b7b107c610fa2d7f149f3441c2b4a9600cb
>> URL:
>> http://cgit.fre
I'd just like to add that if other interfaces will exist in the future
(I recall pipe_2d_context being floated at one time) and state
trackers want to use them without initializing a pipe_context
needlessly and want to reuse the rest of the DRM winsys then the
relevent parts of this patch (or compa
On Tue, Oct 27, 2009 at 3:33 PM, José Fonseca wrote:
> Yes. Younes, I really think it is better to crystallize this in a
> separate branch until it reaches a point where the interfaces are
> crystallized. The master branch is not always perfect, but it should
> always near a state were a release c
On Tue, Oct 27, 2009 at 3:11 PM, Zack Rusin wrote:
> Younes,
>
> sorry for the slow response, we've been a bit busy lately.
> I can't say that I'm a huge fan of this patch. I've been thinking about it
> lately and essentially I'd like to reiterate what I said initially about the
> pipe_video_conte
Hi Thomas,
I'd like to make these changes to make it possible to use the DRM
state tracker interface with contexts other than pipe_context. Nouveau
is the only public driver that does DRI1 from what I can see, but I've
been told that there are some closed drivers that also depend on these
interfac
On Thu, Oct 15, 2009 at 8:54 PM, Corbin Simpson
wrote:
> URL:
> http://cgit.freedesktop.org/~csimpson/mesa/log/?h=gallium-blitter
>
> So, with r600g right around the corner, I'd like to do something about
> this blitter/no blitter thing.
Just wondering, how can you get hardware clear/copy on R600
On Mon, Oct 12, 2009 at 11:58 AM, José Fonseca wrote:
> Younes,
>
> I've finally took a good look to your changes. Again, I don't know
> enough about video to comment on the details, so comments below focus
> more on shape than the content.
>
> Overall the interfaces look sane to me. The point I'
On Thu, Oct 1, 2009 at 11:29 AM, Michel Dänzer wrote:
> On Thu, 2009-10-01 at 16:16 +0100, José Fonseca wrote:
>> On Thu, 2009-10-01 at 07:44 -0700, Michel Dänzer wrote:
>> > From: Michel Dänzer
>> >
>> > Asks the driver to map the texture storage directly or return NULL if
>> > that's
>> > not
On Mon, Sep 28, 2009 at 8:42 AM, José Fonseca wrote:
>
> Younes,
>
> Large changes like this should be rehearsed in a feature branch, to
> allow for more review and experimentation while keeping master from
> getting too broken.
>
> I hadn't time to review pipe_video_context yet, but a few quick c
On Thu, Sep 17, 2009 at 2:29 PM, Zack Rusin wrote:
> On Thursday 17 September 2009 13:21:45 Younes Manton wrote:
>> On Thu, Sep 17, 2009 at 12:43 PM, Zack Rusin wrote:
>> > Hey,
>> >
>> > I'm going to start adding XvMC acceleration to the Gallium's
On Wed, Sep 23, 2009 at 9:40 AM, Cooper Yuan wrote:
> 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?
It would be nice if this code was in it's own lib since Mesa isn't the
on
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,
>>>
>>> I'm going to start adding XvMC acceleration to the Gallium's xorg state
>
On Thu, Sep 17, 2009 at 12:43 PM, Zack Rusin wrote:
> Hey,
>
> I'm going to start adding XvMC acceleration to the Gallium's xorg state
> tracker.
> I'd like to move src/xvmc to src/gallium/state_trackers/xorg/xvmc and run the
> standard Mesa3D indent command on both g3dvl and xvmc.
>
> I'm by no m
On Sat, Aug 22, 2009 at 1:52 AM, Luo Jinghua wrote:
> Fix assertion in nv04_surface_fill() and glxgears works on nv40 again.
> ---
> src/gallium/drivers/nv04/nv04_surface_2d.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/drivers/nv04/nv04_surface_2d
On Sun, Jul 26, 2009 at 11:19 AM, Nicolai Hähnle wrote:
> I apologize for the last mail, since it's tone was probably too inflammatory
> (I leave final judgement on that to others).
>
> Bottom line: I believe TGSI is good for *communicating* programs, but it's
> needlessly complicated for *transfor
On Fri, Jun 19, 2009 at 11:39 AM, Kaspar Bumke wrote:
> Yeah that was me on your blog. Thanks for answering here.
>
> I found your work very interesting and would like to continue where
> you left of. I do not have alot of experience, but I can make up for
> it with available time (a year!) and ent
On Mon, Jun 15, 2009 at 11:59 AM, kasbah wrote:
>
>
> Corbin Simpson wrote:
>>
>> we have a state tracker/winsys combo called g3dvl (Gallium3D Video
>> Layer) which can be used for XvMC. VDPAU support would require beefing
>> this layer up to the point of being able to decode h.264, Theora, etc.
>>
On Sat, May 16, 2009 at 3:44 AM, Eric Valette wrote:
> Younes Manton wrote:
>
>>> However, I have a permanent, always reproducible crash running xbmc
>>
>> Mesa driver is not stable or ready for end users so things like this
>> are normal at the moment.
>
&
On Fri, May 15, 2009 at 6:10 PM, Eric Valette wrote:
> Hi,
>
> I've been running nouveau driver for about 8 month now and did not find
> any serious problem except selecting OpenGL instead of Xrender as the
> rendering backend was causing the kde 4 window manager to crash at startup.
>
> I saw tha
On Fri, Apr 17, 2009 at 2:22 PM, Thomas Hellstrom wrote:
> Ideally this flushing would've been done in the various map operations within
> the pipe driver as you say, but
> unfortunately these map operations are screen operations, so the pipe driver
> doesn't know which context to flush in a mul
Hi Thomas,
I don't understand why this code is necessary in the state tracker. My
understanding is you want to flush and synchronize as necessary for
read/write before mapping buffers, but isn't that something the pipe
driver should already be doing to insure correctness? We do this in
nouveau in
On Wed, Apr 1, 2009 at 3:52 AM, Thomas Hellstrom wrote:
> Ian Romanick wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> thellst...@vmware.com wrote:
>>
>>> From: Thomas Hellstrom
>>>
>>> /*
>>> @@ -186,23 +183,20 @@ static int driBindContext(__DRIcontext *pcp,
>>> */
>>>
On Sat, Apr 11, 2009 at 9:06 AM, Dee Sharpe
wrote:
> So, this means I'll have to port the winsys for intel & radeon in
> addition to a generic winsys for the OS if I want to use Intel & AMD
> chipsets???
Each driver/API/OS combo needs a Winsys. Radeon/OpenGL/,
Intel/OpenGL/, etc.
It might be eas
2009/4/9 Zou, Nanhai :
>>-Original Message-
>>From: stephane.marche...@gmail.com [mailto:stephane.marche...@gmail.com] On
>>Behalf Of Stephane Marchesin
>>Sent: 2009年4月9日 15:20
>>To: Zou, Nanhai
>>Cc: Corbin Simpson; Denis Martinez; mesa3d-dev@lists.sourceforge.net
>>Subject: Re: [Mesa3d-de
On Sat, Mar 21, 2009 at 9:02 PM, Dave Airlie wrote:
> I'm just wondering if anyone has already tackled this in any driver, and
> how this could work best. Does Gallium provide surface accessors for
> textures like spans?
>
> I'm sort of thinking I keep two buffers objects, one sw only and one for
On Mon, Mar 16, 2009 at 6:26 AM, Keith Whitwell wrote:
> On Sat, 2009-03-14 at 17:21 -0700, Younes Manton wrote:
> Ugh, sorry about this. I'm not sure how I didn't pick these up - I must
> have had these drivers disabled in my build without realizing it. Sorry
> for the
On Sat, Feb 21, 2009 at 11:32 PM, Ben Skeggs wrote:
> On Fri, 2009-02-20 at 10:17 +0100, Michel Dänzer wrote:
>> On Thu, 2009-02-19 at 23:58 -0800, Ben Skeggs wrote:
>> > Module: Mesa
>> > Branch: master
>> > Commit: 63a3a3762c8e1a67666d36b35fdb0ada8e4b7d08
>> > URL:
>> > http://cgit.freedeskt
On Sat, Feb 7, 2009 at 4:11 AM, David Harr wrote:
> When I run
>
> make linux-cell
>
> it compiles for quite a while, then I start getting lots of weird errors, like
>
> spu_per_fragment_op.c: In function 'spu_fallback_fragment_ops':
> spu_per_fragment_op.c: error: 'struct pipe_alpha_state' has no
On Tue, Jan 20, 2009 at 4:07 AM, Xavier Bestel wrote:
> Sorry to get in the way, but if at some point in the pipe everything can
> be done in hardware or shaders, maybe drivers should expose what they
> can accelerate to let the app handle the rest (some smart frameworks
> like gstreamer could tak
On Mon, Jan 19, 2009 at 4:08 PM, Corbin Simpson
wrote:
> Well, it occurs to me that almost all video decoding's done in a
> pipeline, and we don't want to do any steps in software between hardware
> steps. It also occurs to me that there's a big disconnect between the
> actual video format, and th
I've been taking a look at VDPAU and how to support it on cards with
and without hardware support and I have some thoughts. The VDPAU API
lets the client pass off the entire video bitstream and takes care of
the rest of the decoding pipeline. This is fine if you have hardware
that can handle that,
On Mon, Jan 12, 2009 at 5:04 AM, Keith Whitwell wrote:
>
>
> On Sun, 2009-01-11 at 23:00 -0800, Ben Skeggs wrote:
>> Module: Mesa
>> Branch: gallium-0.2
>> Commit: df266471b1f0eae54cf23fd59a741fa3be9b93df
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=df266471b1f0eae54cf23fd59a741
On Sat, Sep 6, 2008 at 7:56 PM, José Fonseca
<[EMAIL PROTECTED]> wrote:
> On Fri, Sep 5, 2008 at 3:59 AM, Younes Manton <[EMAIL PROTECTED]> wrote:
>> Also, it would be nice if the mapping interface allowed for mapping a
>> subset of a buffer, and accepted a PIP
I've been working with Gallium for the last 3-4 months on the XvMC
state tracker and I want to bring up some additions that I think are
worthwhile, since I hear there might be some interface changes soon.
I think there need to be more texture usage flags, along the lines of
D3D's static and dynami
I needed this to test some XvMC related stuff.
diff --git a/src/gallium/auxiliary/util/p_tile.c
b/src/gallium/auxiliary/util/p_tile.c
index 1bf0d72..2b6db43 100644
--- a/src/gallium/auxiliary/util/p_tile.c
+++ b/src/gallium/auxiliary/util/p_tile.c
@@ -441,6 +441,46 @@ a8_get_tile_rgba(ubyte *src,
[Just realized that mesa-dev might be slightly more on topic for
DRI-specific issues. See below. Thanks.]
On Thu, Jul 10, 2008 at 12:22 PM, Younes Manton <[EMAIL PROTECTED]> wrote:
> I'm trying to get the HW winsys stuff set up for XvMC and have some questions.
>
> Is th
On Fri, Jun 6, 2008 at 6:12 AM, José Fonseca
<[EMAIL PROTECTED]> wrote:
> On Fri, Jun 6, 2008 at 10:47 AM, Younes Manton <[EMAIL PROTECTED]> wrote:
>> As an aside, is there any preferred directory structure people would
>> like to see for state trackers? Right now
On Wed, Jun 4, 2008 at 8:30 PM, Brian Paul
<[EMAIL PROTECTED]> wrote:
> Dave Airlie wrote:
> > Stephane wrote:
>>> Hi Brian,
>>>
>>> It seems like people are mostly concerned about gallium stability
>>> right now. How stable wioll the interfaces be in the future ? Maybe if
>>> you could tell us, t
53 matches
Mail list logo
