Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h

This looks like my fault. It would be nice to have the r300 and nvidia drivers building by default (eg on linux-debug builds), even if they don't create full drivers, so that a single build can get greater coverage. Keith On Wed, 2010-01-06 at 09:09 -0800, Sedat Dilek wrote: > OK. > > That's th

RE: [Patch VIA UniChrome DRM][2/5 Ver1] Add support for video command flush and interface for V4L kernel module

On Thu, 2009-10-08 at 02:35 -0700, brucech...@via.com.tw wrote: > Hello Thomas: > > > If I understand the code correctly, the user-space application prepares > > command buffers directly in AGP, and asks the > > drm module to submit them. We can't allow this for security reasons. The > > user-sp

Re: preventing GPU reset DoS

On Tue, 2009-09-22 at 12:13 -0700, Pauli Nieminen wrote: > Hi! > > I have been thinking GPU reset as possible DoS attack from > user-space.Problem here is that display doesn't work anymore at all if > attacker chooses to run a application that constantly causes GPU hang. > It would be of course id

Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2

On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: > Stephane Marchesin wrote: > > 2009/8/31 Thomas Hellström : > > > > > >>> The problem I see with Xv-API-in-kernel is that of the various hw > >>> constrains on the buffer layout. IMHO this has two solutions: > >>> > >>> a) complicated t

RE: [PATCH] Add modesetting pageflip ioctl and corresponding drm event

No, I'm fine. I don't have the patch in front of me but it doesn't sound like it precludes these types of changes in the future. Keith From: Jesse Barnes [jbar...@virtuousgeek.org] Sent: Tuesday, August 18, 2009 1:23 PM To: Keith Whitwe

RE: [PATCH] Add modesetting pageflip ioctl and corresponding drm event

This seems wrong to me -- the client doesn't need to sleep - all it's going to do is build a command buffer targeting the new backbuffer. There's no problem with that, it should be the preserve of the GPU scheduler (TTM or GEM) to ensure those commands (once submitted) don't get executed until

RE: [PATCH] Add modesetting pageflip ioctl and corresponding drm event

I think the bug in question was because somebody (Jon Smirl??) removed the empty & apparently unused poll implementation from the drm fd, only to discover that the X server was actually polling the fd. If this code adds to, extends or at least doesn't remove the ability to poll the drm fd, it s

Re: Doing better than CS ioctl ?

in the sarea, and updated the context under the lock, and had the > kernel emit it. The sceond one had a bunch of state objects, containing > ranges of registers that were safe to emit. > > Maybe Keith Whitwell can point out why these were a good/bad idea, > not sure if anyone else

Re: TTM page pool allocator

On Wed, 2009-07-22 at 15:35 -0700, Jerome Glisse wrote: > On Wed, 2009-07-22 at 21:13 +0200, Thomas Hellström wrote: > > Jerome Glisse wrote: > > > On Wed, 2009-07-22 at 15:16 +0200, Michel Dänzer wrote: > > > > > >> On Tue, 2009-07-21 at 21:22 +0200, Jerome Glisse wrote: > > >> > > >>> On

Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream

On Fri, 2009-07-17 at 04:37 -0700, Harald Welte wrote: > On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote: > > On Fri, Jul 17, 2009 at 4:36 PM, wrote: > > > To whom it may ceoncern: > > >The following 3 patches are the DRM kernel module that support VIA > > > Chorme9 GFX chipset. T

Re: DRM development process wiki page..

> Major bumps once stuff went into the kernel weren't allowed at all. > You'd need to fork the driver in any case. So we did this once or > twice on drivers in devel trees like mach64. > However upstream first policy should avoid this need. I'd also prefer > to see getparam for new features instead

Re: [PATCH 1/1] Adapt on_each_cpu

On Fri, Aug 1, 2008 at 2:40 AM, Dave Airlie <[EMAIL PROTECTED]> wrote: > >> >> Well, if the overhead of merging upstream is a concern, then how about >> not worrying about bc at all and let people who want to back port deal >> with it? Oh, and what about just keeping the drm drivers in a linux >>

Re: [RFC: 2.6 patch] remove the i830 driver

On Tue, Jul 15, 2008 at 3:35 PM, Simon Farnsworth <[EMAIL PROTECTED]> wrote: > Keith Whitwell wrote: >> >> You can still buy new i865 boards: >> >> http://www.ebuyer.com/product/119412 >> >> So I think this isn't a great idea. >> &

Re: Combining Mesa3D and DRI mailing lists and/or sites? (was: Re: Wrapping up 7.4 (finally))

On Mon, Jun 16, 2008 at 8:31 AM, Timo Jyrinki <[EMAIL PROTECTED]> wrote: > 2008/6/12 Keith Whitwell <[EMAIL PROTECTED]>: >> In reality, what has happened is that most of this has already >> occurred -- whatever 3d driver-related traffic that hasn't been sucked >

Re: GEM merging to master

> If this was a test of just two memory manager implementations, the > benchmarks would speak for themselves. However, there are at least two > driver changes I caught on first review of gallium-i915-current's > i915simple (which I assume is what you were testing, given that the last > tests I've

Re: Combining Mesa3D and DRI mailing lists and/or sites? (was: Re: Wrapping up 7.4 (finally))

On Thu, Jun 12, 2008 at 5:28 PM, Timo Jyrinki <[EMAIL PROTECTED]> wrote: > 2008/6/12 Daniel Stone <[EMAIL PROTECTED]>: >> On Thu, Jun 12, 2008 at 10:49:57AM +0300, Timo Jyrinki wrote: >>> Speaking of which, if you have any ideas how to better interlink and >>> combine: >>> - http://dri.freedesktop

Re: GEM discussion questions

On Tue, May 20, 2008 at 1:29 PM, Thomas Hellström <[EMAIL PROTECTED]> wrote: > Keith Packard wrote: >> On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote: >> >>> The obvious overhead I was referring to is the extra malloc / free. >>> That's why I went on to say "So, now I have to go back and spe

Re: i915 performance, master, i915tex & gem

> * Classic is apparently doing suboptimal syncs that limits its > performance in some cases (gears, teapot and perhaps openarena), > one should not benchmark framerates against classic in those cases. As I said elsewhere, I'd like to get to the bottom of this -- it wasn't always this wa

Re: i915 performance, master, i915tex & gem

> So possibilities are: > - batchbuffer starvation -- has I was going to say 'has this changed significantly' -- and the answer is that it has of course, with the bufmgr_fake changes... I can't tell by quick inspection if these are a likely culprit, but it's certainly a signifcant set of changes

Re: i915 performance, master, i915tex & gem

On Mon, May 19, 2008 at 9:03 PM, Keith Packard <[EMAIL PROTECTED]> wrote: > On Mon, 2008-05-19 at 20:11 +0100, Keith Whitwell wrote: > >> I'm still confused by your test setup... Stepping back from cache >> metaphysics, why doesn't classic pin the hardware, if

Re: i915 performance, master, i915tex & gem

> > glxgears uses 40% of the CPU in both classic and gem. Note that the gem > version takes about 20 seconds to reach a steady state -- the gem driver > isn't clearing the gtt actively and so glxgears gets far ahead of the > gpu. > > My theory is that this shows that using cache-aware copies from a

Re: TTM vs GEM discussion questions

On Mon, May 19, 2008 at 2:06 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote: > On Mon, 19 May 2008 12:16:57 +0100 (IST) > Dave Airlie <[EMAIL PROTECTED]> wrote: >> > >> > For radeon the plan was to return error from superioctl as during >> > superioctl and validation i do know if there is enough gart/

i915 performance, master, i915tex & gem

Just reposting this with a new subject line and less preamble. - Original Message > > Well the thing is I can't believe we don't know enough to do this in some > way generically, but maybe the TTM vs GEM thing proves its not possible. I don't think there's anything particularly wr

Re: TTM vs GEM discussion questions

> > It's not clear to me which of the above the r300 & nv people are aiming at, > but in my opinion the latter is such a significant departure from what we > have > been thinking about that I have always believed it should be addressed by a > new > set of interfaces. > > > > My understandin

Re: TTM vs GEM discussion questions

- Original Message > From: Dave Airlie <[EMAIL PROTECTED]> > To: Jerome Glisse <[EMAIL PROTECTED]> > Cc: Keith Whitwell <[EMAIL PROTECTED]>; Ian Romanick <[EMAIL PROTECTED]>; DRI > > Sent: Monday, May 19, 2008 12:16:57 PM > Subject: Re: TTM v

Re: TTM vs GEM discussion questions

- Original Message > From: Dave Airlie <[EMAIL PROTECTED]> > To: Ian Romanick <[EMAIL PROTECTED]> > Cc: DRI > Sent: Monday, May 19, 2008 4:38:02 AM > Subject: Re: TTM vs GEM discussion questions > > > > > > All the good that's done us and our users. After more than *5 years* of > >

Re: TTM vs GEM discussion questions

- Original Message > From: Thomas Hellström <[EMAIL PROTECTED]> > To: Stephane Marchesin <[EMAIL PROTECTED]> > Cc: DRI > Sent: Monday, May 19, 2008 9:49:21 AM > Subject: Re: TTM vs GEM discussion questions > > Stephane Marchesin wrote: > > On 5/18/08, Thomas Hellström wrote: > > > >

Re: TTM vs GEM discussion questions

- Original Message > From: Ian Romanick <[EMAIL PROTECTED]> > To: DRI > Sent: Monday, May 19, 2008 10:04:09 AM > Subject: Re: TTM vs GEM discussion questions > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ian Romanick wrote: > > | I've read the GEM documentation several time

Re: TTM merging?

- Original Message > From: Jerome Glisse <[EMAIL PROTECTED]> > To: Thomas Hellström <[EMAIL PROTECTED]> > Cc: Dave Airlie <[EMAIL PROTECTED]>; Keith Packard <[EMAIL PROTECTED]>; DRI > ; Dave Airlie <[EMAIL PROTECTED]> > Sent: Wednesday, May 14, 2008 6:08:55 PM > Subject: Re: TTM merging

Re: TTM merging?

> I do worry that TTM is not Linux enough, it seems you have decided that we > can never do in-kernel allocations at any useable speed and punted the > work into userspace, which makes life easier for Gallium as its more like > what Windows does, but I'm not sure this is a good solution for Lin

Re: Writing a state tracker for Gallium3D/SoftPipe

There are three components that you'll need: - state tracker -- which is API dependent - hw driver -- HW dependent (softpipe is an example), which implements the p_context.h interface. - winsys -- which is dependent on API, HW, OS, etc. The winsys is basically the glue that holds it all tog

Re: fake bufmgr and aperture sizing.

> > The problem remains how to avoid this situation completely. I guess the > > drm driver can reserve a global "safe" aperture size, and communicate > > that to the 3D client, but the current TTM drivers don't deal with this > > situation. > > My first idea would probably be your first alterna

Re: Gallium: Fix for tgsi_emit_sse2()

Sorry, this slipped through the net a little... Given how much is hardcoded with rtasm, I'd prefer to use a single calling convention everywhere, whether that's STDCALL or CDECL or something else I don't mind. Probably STDCALL because some compilers are too dumb to use anything else?? In wh

Re: Gallium code reorganization

OK, I found I had to merge rather than rebase in order to get my changes into the new organization -- apologies for the bubble in the history. Keith José Fonseca wrote: > Just to let you know that the first step, file shuffling, is finished. > > The rest will take more time but changes are le

Re: [Mesa3d-dev] Gallium code reorganization

Michel Dänzer wrote: > On Thu, 2008-02-14 at 20:05 +0900, José Fonseca wrote: >> On 2/14/08, Keith Whitwell <[EMAIL PROTECTED]> wrote: >>> José Fonseca wrote: >>> > >>> > 1. Physically separate gallium source code from mesa code. This will be

Re: redesigning the DRM internal logic..

Alex Deucher wrote: > On Feb 13, 2008 9:09 PM, Keith Packard <[EMAIL PROTECTED]> wrote: >> On Wed, 2008-02-13 at 19:22 -0500, Alex Deucher wrote: >> >>> How about a "compat" node for old clients and a "new" render node that >>> handles both new clients and GPGPU? Then the backwards compat stuff >>

Re: [Mesa3d-dev] Gallium code reorganization

José Fonseca wrote: > I'll dedicate some time now to reorganize gallium's code & build process. > This is > stuff which has been discussed internally at TG several times, but this time I > want to get it done. > > My objectives are: > - leaner and more easy to understand/navigate source tree >

Re: Intel releases 965 documentation under CC license

Philipp Klaus Krause wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > It seems Intel has released complete documentation for the 965: > http://intellinuxgraphics.com/documentation.html Hmm, some of the tables seem to be a bit messed up (presumably after the conversion to pdf). Still

Re: RFC: render buffer

Jerome Glisse wrote: > On Wed, 2008-01-16 at 17:35 +0000, Keith Whitwell wrote: >> Pretty much every buffer is potentially a render target, for instance >> all texture buffers when generating mipmaps, etc. >> >> In the example above, different parts of individual buf

Re: RFC: render buffer

Jerome Glisse wrote: > Hi all, > > There have been discussion on irc and elsewhere about the need or not > of an object describing a render buffer (could be scan-out buffer or > or other specialized card render buffer: color buffer, zbuffer, ...). > This would mostly act as a wrapper around BO. >

Re: [PATCH] Rename inappropriately named 'mask' fields to 'proposed_flags' instead.

Keith Packard wrote: > commit 32acf53eefa64cd41cc9bf45705b0825fc8a0eef > Author: Keith Packard <[EMAIL PROTECTED]> > Date: Sun Dec 16 20:16:50 2007 -0800 > > Rename inappropriately named 'mask' fields to 'proposed_flags' instead. > > Flags pending validation were stored in a mislead

Re: [PATCH] Change drm_bo_type_dc to drm_bo_type_device and comment usage of this value.

Keith, This looks good to me too. Keith Keith Packard wrote: > commit 9856a00ee5e6de30ba3040749583b2eafdf2dfc1 > Author: Keith Packard <[EMAIL PROTECTED]> > Date: Sun Dec 16 22:00:45 2007 -0800 > > Change drm_bo_type_dc to drm_bo_type_device and comment usage of this > value. > >

Re: [PATCH] Clean up and document drm_ttm.c APIs. drm_bind_ttm -> drm_ttm_bind.

Keith Packard wrote: > Here are some proposed cleanups and documentation for the drm_ttm.c APIs. > > One thing I didn't change was the name of drm_ttm_fixup_caching, which is > clearly a badly named function. Can anyone explain why you wouldn't just > always use drm_ttm_unbind instead? The only di

Re: Proposal for a few minor internal API changes.

Keith Packard wrote: > On Sat, 2007-12-15 at 10:59 -0700, Brian Paul wrote: > >> Could a temporary/dummy parameter be added for a while? Callers that >> weren't updated would get an error/warning about too few arguments. >> Then remove the dummy at some point in the future. > > We could change

Re: Proposal for a few minor internal API changes.

Keith Packard wrote: > I'm writing up some documentation for internal DRM interfaces and came > across a couple of interface inconsistencies that seem like they should > get fixed before they start getting used a lot more. If these look like > good changes, I'll continue to search out other similar

Re: Memory manager, sub allocator & partial validation

Jerome Glisse wrote: > Hi, > > I am wondering if allowing user to ask for partial validation > (ie only validate a part of a bo object) might be usefull in > case of userspace sub allocator and likely in others case when > you know for instance that you only need to access a small part > of a bo.

Re: i915: wait for buffer idle before writing relocations

as it could allow mapping a state pool buffer to add new states as required by the application, but not require a fence as the old ones won't be interfered with. Keith - Original Message From: Keith Packard <[EMAIL PROTECTED]> To: Keith Whitwell <[EMAIL PROTECTED]>

Re: i915: wait for buffer idle before writing relocations

Keith Packard wrote: > On Fri, 2007-12-07 at 11:15 +0000, Keith Whitwell wrote: >> Keith, >> >> Thomas has just left for two weeks of (well deserved!) holiday, so he >> may be slow to respond. > > Thanks for taking the time to have a look while he's away;

Re: i915: wait for buffer idle before writing relocations

Keith, Thomas has just left for two weeks of (well deserved!) holiday, so he may be slow to respond. In the meantime, have you considered how this will interact with userspace buffer pools? I know you guys aren't using them at this point, but I'm of the opinion that they are an important faci

Re: Swapbuffers [was: Re: DRI2 and lock-less operation]

Stephane Marchesin wrote: > On 11/28/07, *Keith Whitwell* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > In my ideal world, the entity which knows and cares about cliprects > should be the one that does the swapbuffers, or at least is i

Re: Clip Lists

Stephane Marchesin wrote: > > > On 11/28/07, *Keith Whitwell* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Stephane Marchesin wrote: > > > > > > On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann* &

Re: Clip Lists

Stephane Marchesin wrote: > > > On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann* <[EMAIL PROTECTED] > > wrote: > > "Stephane Marchesin" <[EMAIL PROTECTED] > > writes: > > > I fail to see how this works with a lockless design. How

Swapbuffers [was: Re: DRI2 and lock-less operation]

Kristian Høgsberg wrote: > On Nov 27, 2007 11:48 AM, Stephane Marchesin > <[EMAIL PROTECTED]> wrote: >> On 11/22/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > ... >>> It's all delightfully simple, but I'm starting to reconsider whether >>> the "lockless" bullet point is realistic. Note, the

Re: DRI2 and lock-less operation

Michel Dänzer wrote: > On Wed, 2007-11-28 at 09:30 +0000, Keith Whitwell wrote: >> Kristian Høgsberg wrote: >> >>> Another problem is that it's not just swapbuffer - anything that >>> touches the front buffer have to respect the cliprects - glCopyPixels >&g

Re: DRI2 and lock-less operation

Kristian Høgsberg wrote: > Another problem is that it's not just swapbuffer - anything that > touches the front buffer have to respect the cliprects - glCopyPixels > and glXCopySubBufferMESA - and thus have to happen in the kernel. These don't touch the real swapbuffer, just the fake one. Hence

Re: DRI2 and lock-less operation

Kristian Høgsberg wrote: > On Nov 27, 2007 2:30 PM, Keith Packard <[EMAIL PROTECTED]> wrote: > ... >>> I both cases, the kernel will need to >>> know how to activate a given context and the context handle should be >>> part of the super ioctl arguments. >> We needn't expose the contexts to user-s

Re: DRI2 and lock-less operation

Packard <[EMAIL PROTECTED]> Cc: Jerome Glisse <[EMAIL PROTECTED]>; Dave Airlie <[EMAIL PROTECTED]>; dri-devel@lists.sourceforge.net; Keith Whitwell <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2007 8:44:48 PM Subject: Re: DRI2 and lock-less operation On Nov 27, 2007 2:30 PM,

Re: DRI2 and lock-less operation

Kristian Høgsberg wrote: > On Nov 22, 2007 4:23 AM, Keith Whitwell <[EMAIL PROTECTED]> wrote: > ... >>> My guess for one way is to store a buffer object with the current state >>> emission in it, and submit it with the superioctl maybe, and if we have >&

Re: DRI2 and lock-less operation

Dave Airlie wrote: >> I'm trying to figure out how context switches acutally work... the DRI >> lock is overloaded as context switcher, and there is code in the >> kernel to call out to a chipset specific context switch routine when >> the DRI lock is taken... but only ffb uses it... So I'm guessin

Re: Radeon state handling

Jerome Glisse wrote: > Hi all, > > While playing with modesetting & ttm i have put some thought on how we send > things to card. And i would like to test the following scheme: > -split card state into a bunch of separate chunk (z state, fog state, ...) > -the driver build the state it want and reg

Re: mapped cached memory and pre-fetching.

Thomas Hellström wrote: > Dave Airlie wrote: > >> On 10/31/07, Thomas Hellström <[EMAIL PROTECTED]> wrote: >> >> >>> Dave Airlie wrote: >>> >>> On 10/31/07, Thomas Hellström <[EMAIL PROTECTED]> wrote: > Dave, > > When starting out with TTM i did look a l

Re: intel hw and caching interface to TTM..

Dave Airlie wrote: >> Dave, I'd like to see the flag DRM_BO_FLAG_CACHED really mean cache-coherent >> memory, that is cache coherent also while visible to the GPU. There are HW >> implementations out there (Poulsbo at least) where this option actually seems >> to work, althought it's considerably s

Re: [patch] post superioctl inteface removal.

Jerome Glisse wrote: > Keith Whitwell wrote: >> Thomas Hellström wrote: >> >>> Hi, Eric. >>> >>> Eric Anholt wrote: >>> >> >> ... >> >> >>>> Can you clarify the operation being done where you move sca

Re: [patch] post superioctl inteface removal.

Thomas Hellström wrote: > Hi, Eric. > > Eric Anholt wrote: ... >> Can you clarify the operation being done where you move scanout buffers >> before unpinning them? That seems contradictory to me -- how are you >> scanning out while the object is being moved, and how are you >> considering it pi

Re: Merging DRI interface changes

Michel Dänzer wrote: > On Fri, 2007-10-12 at 10:19 +0100, Keith Whitwell wrote: >> Michel Dänzer wrote: >>> On Thu, 2007-10-11 at 18:44 -0400, Kristian Høgsberg wrote: >>>> On 10/11/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: >>>> >>>>

Re: Merging DRI interface changes

Michel Dänzer wrote: > On Thu, 2007-10-11 at 18:44 -0400, Kristian Høgsberg wrote: >> On 10/11/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: >> >>> 3) Share buffers with a reference counting scheme. When a client >>> notices the buffer needs a res

Re: Merging DRI interface changes

Kristian Høgsberg wrote: > On 10/11/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: >> Brian Paul wrote: > ... >>> If two GLX clients render to the same double-buffered GLX window, each >>> is going to have a different/private back color buffer, right? That

Re: Merging DRI interface changes

Allen Akin wrote: > On Thu, Oct 11, 2007 at 10:35:28PM +0100, Keith Whitwell wrote: > | Suppose 2 clients render to the same backbuffer... > > The (rare) cases in which I've seen this used, the clients are aware of > one another, and restrict their rendering to non-overlappi

Re: Merging DRI interface changes

Brian Paul wrote: > Keith Whitwell wrote: >> Brian Paul wrote: >>> Kristian Høgsberg wrote: >>>> Hi, >>>> >>>> I have this branch with DRI interface changes that I've been >>>> threatening to merge on several occasions: >&

Re: Merging DRI interface changes

Brian Paul wrote: > Kristian Høgsberg wrote: >> Hi, >> >> I have this branch with DRI interface changes that I've been >> threatening to merge on several occasions: >> >> http://cgit.freedesktop.org/~krh/mesa/log/?h=dri2 >> >> I've just rebased to todays mesa and it's ready to merge. Ian >> revi

Re: [patch] post superioctl inteface removal.

Dave Airlie wrote: >> Dave, >> As mentioned previously to Eric, I think we should keep the single >> buffer validate interface with the exception that the hint >> DRM_BO_HINT_DONT_FENCE is implied, and use that instead of the set pin >> interface. We can perhaps rename it to drmBOSetStatus or somet

Re: Initial 915 superioctl patch.

Dave Airlie wrote: > >> On Monday, October 8, 2007 10:13 am Keith Whitwell wrote: >>> Neither 42 nor 256 are very good - the number needs to be dynamic. >>> Think about situations where an app has eg. one glyph per texture and >>> is doing font rendering...

Re: Initial 915 superioctl patch.

Neither 42 nor 256 are very good - the number needs to be dynamic. Think about situations where an app has eg. one glyph per texture and is doing font rendering... Or any reasonably complex game might use >256 textures in a frame. Sorry for topposting -- webmail. Keith - Original Messa

Re: DRI2 Design Wiki Page

Keith Whitwell wrote: > Kristian Høgsberg wrote: >> On 10/4/07, Keith Packard <[EMAIL PROTECTED]> wrote: >>> On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote: >>> >>>> There is an issue with the design, though, related to how and when the &g

Re: DRI2 Design Wiki Page

Kristian Høgsberg wrote: > On 10/4/07, Keith Packard <[EMAIL PROTECTED]> wrote: >> On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote: >> >>> There is an issue with the design, though, related to how and when the >>> DRI driver discovers that the front buffer has changed (typically >>> resi

Re: DRI2 Design Wiki Page

Kristian Høgsberg wrote: > Hi, > > I wrote up the DRI2 design on a wiki page here: > > http://wiki.x.org/wiki/DRI2 > > It's the result of the discussions we had during my redirected > rendering talk and several follow up discussions with Keith Whitwell > and

Re: drm: Branch 'master'

Alan Hourihane wrote: > linux-core/drm_drv.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > New commits: > diff-tree 6671ad1917698b6174a1af314b63b3800d75248c (from > 03c47f1420bf17a1e0f2b86be500656ae5a4c95b) > Author: Alan Hourihane <[EMAIL PROTECTED]> > Date: Wed Sep 26 15:38:

XDS: Gallium slides

Gallium slides from XDS (including all the typos) now available at: http://www.tungstengraphics.com/wiki/index.php/Gallium3D Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studi

XDS: Intel i965 docs

Just FYI, one of the things that came up at xds is that Intel is now making a scrubbed version of the i965 docs available under NDA. Dave Airlie has been working with them at redhat, for instance. Keith - This SF.net email

Re: Vblanks, CRTCs and GLX, oh my!

Jesse Barnes wrote: > Both the generic DRM vblank-rework and Intel specific pipe/plane > swapping have uncovered some vblank related problems which we discussed > at XDS last week. Unfortunately, no matter what we do (including > the "do nothing" option), some applications will break some of th

ttm --- dealing with (more) limited memory pools

I've got a couple of things that are bothering me if we're looking at finalizing the TTM interface in the near term. Specifically I'm concerned that we don't have a recoverable way to deal with out-of-memory situations. Consider a driver that tries to submit whole frames of q3, which is runnin

TTM BOF topics

Looks like we've got a slot at XDS to talk about all our adventures with buffer management and plans for the future. It might make the session more productive if we do a little groundwork first... If you've been working with TTM and have things you'd like to talk about, please reply to this em

Re: DRM enhancements document

Michel Dänzer wrote: > On Thu, 2007-08-02 at 17:44 +0200, Jerome Glisse wrote: >> Btw i think that some GPU can wait on vblank using cmd ie you >> don't need to ask the card to emit irq you just insert a cmd in >> stream which stall further cmd execution until vblank happen, >> this might be good f

Re: Merging DRI changes

Kristian Høgsberg wrote: > Hi, > > I've finished the changes to the DRI interface that I've been talking > about for a while (see #5714). Ian had a look at the DRI driver side > of things, and ACK'ed those changes. I've done the X server changes > now plus a couple of GLX module cleanups, and I t

Re: drm-ttm-cleanup-branch

Dave Airlie wrote: > On 5/9/07, Thomas Hellström <[EMAIL PROTECTED]> wrote: >> Dave Airlie wrote: I'll try it out as soon as there is time. >>> I've just tested glxgears and a few mesa tests on it and it seems to >>> be working fine >>> >>> We should probably think about pulling this over

Re: R300 cleanup questions

Keith Whitwell wrote: > Oliver McFadden wrote: >> I'd like some input on the VBO stuff in r300. In r300_context.h we have the >> following. >> >> /* KW: Disable this code. Driver should hook into vbo module >> * directly, see i965 driver for example

Re: R200 minor cleanups

Oliver McFadden wrote: > My thoughts are, we should unify the really common stuff... but I don't think > it's possible to unify r200_tex.c and r300_tex.c. The hardware is different, > and > the file would end up with an #ifdef on every 3rd line; it doesn't make sense > here. > > Just for really c

Re: R300 cleanup questions

Oliver McFadden wrote: > I'd like some input on the VBO stuff in r300. In r300_context.h we have the > following. > > /* KW: Disable this code. Driver should hook into vbo module > * directly, see i965 driver for example. > */ > /* #define RADEON_VTXFMT_A */ > #ifdef RADEON_VTXFMT_A > #define H

Re: [RFC] [PATCH] DRM TTM Memory Manager patch

Keith Packard wrote: >> OTOH, letting DRM resolve the deadlock by unmapping and remapping shared >> buffers in the correct order might not be the best one either. It will >> certainly mean some CPU overhead and what if we have to do the same with >> buffer validation? (Yes for some operations w

Re: Lockups with Googleearth

Adam K Kirchhoff wrote: > Michel Dänzer wrote: >> On Tue, 2007-03-06 at 04:32 -0500, Adam K Kirchhoff wrote: >> >>> commit 09e4df2c65c1bca0d04c6ffd076ea7808e61c4ae causes the lockup.. If >>> I'm reading the git log properly this is right after the merge from >>> vbo-0.2. However, commit 47d4

Re: [PATCH] R300 early Z cleanup

Jerome Glisse wrote: > On 2/26/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: >> Jerome Glisse wrote: >> > On 2/26/07, Roland Scheidegger <[EMAIL PROTECTED]> wrote: >> >> Christoph Brill wrote: >> >>> Attached is a mini-patch to add the a

Re: [PATCH] R300 early Z cleanup

Jerome Glisse wrote: > On 2/26/07, Roland Scheidegger <[EMAIL PROTECTED]> wrote: >> Christoph Brill wrote: >>> Attached is a mini-patch to add the address of early Z to r300_reg.h >>> and use it. Jerome Glisse helped me with this patch. Thanks. :-) >> Not really related directly to the patch itself

Re: mesa: Branch 'master'

Stephane Marchesin wrote: > Keith Whitwell wrote: >> configs/linux-dri-debug | 16 >> 1 files changed, 16 insertions(+) >> >> New commits: >> diff-tree 3bfbe63806cee1c44da2625daf069b719f2a6097 (from >> 747c9129c0b592941b14c290ff3d8ab22ad6

Re: i915: Xserver crash and restart fails

Tino Keitel wrote: > On Fri, Nov 17, 2006 at 22:12:09 +0100, Tino Keitel wrote: >> Hi folks, >> >> I use the TV application MythTV that uses OpenGL to draw its GUI. Since >> a while I can crash my Xserver very easy just by switching to the >> workspace that shows the MythTV GUI. A restart of the Xs

Re: [r300] VBO broken by changes in mesa

Rune Petersen wrote: > Keith Whitwell wrote: >> I've fixed some typo's in this code - with luck this should be solved now? > > sorry no... > > If you can't find in the next day, would you mind disabling it for 6.5.2 > release? OK, I've made some progr

Re: [r300] VBO broken by changes in mesa

Rune Petersen wrote: > Hi, > > A patch for making sure VBO's are mapped breaks r300: > > http://marc.theaimsgroup.com/?l=mesa3d-cvs&m=116364446305536&w=2 > > It would appear we "just" need to add _ae_(un)map_vbos() the right > places in radeon_vtxfmt_a.c. Rune, my expectation was that the chang

Re: [r300] partly working fragment.position patch

Rune Petersen wrote: > Keith Whitwell wrote: >> Rune Petersen wrote: >>> Keith Whitwell wrote: >>>> Roland Scheidegger wrote: >>>>> Keith Whitwell wrote: >>>>> I think Rune is rather refering to the fact that you can't change

Re: [r300] partly working fragment.position patch

Rune Petersen wrote: > Keith Whitwell wrote: >> Roland Scheidegger wrote: >>> Keith Whitwell wrote: >>> I think Rune is rather refering to the fact that you can't change (not >>> with "legal" means at least) the constant you got with >>

Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)

Ryan Richter wrote: > On Fri, Oct 20, 2006 at 06:51:01PM +0100, Keith Whitwell wrote: >> Ryan Richter wrote: >>> On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote: >>>> Ryan Richter wrote: >>>>> On Wed, Oct 18, 2006 at 07:54:41AM +0100,

Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)

Ryan Richter wrote: > On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote: >> Ryan Richter wrote: >>> On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote: >>>> This is all a little confusing as the driver doesn't really use that >>

  1   2   3   4   5   6   7   8   9   10   >