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

2010-01-06 Thread Keith Whitwell
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 the

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

2009-10-08 Thread Keith Whitwell
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-space

Re: preventing GPU reset DoS

2009-09-22 Thread Keith Whitwell
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 ideal

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

2009-09-01 Thread Keith Whitwell
On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: 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 to

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

2009-08-18 Thread Keith Whitwell
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

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

2009-08-18 Thread Keith Whitwell
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

2009-08-18 Thread Keith Whitwell
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 Whitwell Cc: Kristian

Re: Doing better than CS ioctl ?

2009-08-12 Thread Keith Whitwell
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 remembers that far back. Dave. The first motivation behind

Re: DRM development process wiki page..

2008-08-28 Thread Keith Whitwell
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 of

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

2008-07-15 Thread Keith Whitwell
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. This won't remove all support for i865. It only removes support

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

2008-06-21 Thread Keith Whitwell
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 into IRC is now occurring on the Mesa lists

Re: GEM merging to master

2008-06-13 Thread Keith Whitwell
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))

2008-06-12 Thread Keith Whitwell
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.org/ -

Re: i915 performance, master, i915tex gem

2008-05-20 Thread Keith Whitwell
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

2008-05-20 Thread Keith Whitwell
* 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 way.

Re: i915 performance, master, i915tex gem

2008-05-20 Thread Keith Whitwell
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 it's still got 60% cpu to burn? glxgears

Re: GEM discussion questions

2008-05-20 Thread Keith Whitwell
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 spend time

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
- Original Message From: Ian Romanick [EMAIL PROTECTED] To: DRI dri-devel@lists.sourceforge.net 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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
- Original Message From: Thomas Hellström [EMAIL PROTECTED] To: Stephane Marchesin [EMAIL PROTECTED] Cc: DRI dri-devel@lists.sourceforge.net Sent: Monday, May 19, 2008 9:49:21 AM Subject: Re: TTM vs GEM discussion questions Stephane Marchesin wrote: On 5/18/08, Thomas

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
- Original Message From: Dave Airlie [EMAIL PROTECTED] To: Ian Romanick [EMAIL PROTECTED] Cc: DRI dri-devel@lists.sourceforge.net 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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
- Original Message From: Dave Airlie [EMAIL PROTECTED] To: Jerome Glisse [EMAIL PROTECTED] Cc: Keith Whitwell [EMAIL PROTECTED]; Ian Romanick [EMAIL PROTECTED]; DRI dri-devel@lists.sourceforge.net Sent: Monday, May 19, 2008 12:16:57 PM Subject: Re: TTM vs GEM discussion questions

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
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 understanding of future

i915 performance, master, i915tex gem

2008-05-19 Thread Keith Whitwell
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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
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/vram to do

Re: i915 performance, master, i915tex gem

2008-05-19 Thread Keith Whitwell
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 merging?

2008-05-14 Thread Keith Whitwell
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 Linux.

Re: TTM merging?

2008-05-14 Thread Keith Whitwell
- Original Message From: Jerome Glisse [EMAIL PROTECTED] To: Thomas Hellström [EMAIL PROTECTED] Cc: Dave Airlie [EMAIL PROTECTED]; Keith Packard [EMAIL PROTECTED]; DRI dri-devel@lists.sourceforge.net; Dave Airlie [EMAIL PROTECTED] Sent: Wednesday, May 14, 2008 6:08:55 PM Subject:

Re: fake bufmgr and aperture sizing.

2008-04-16 Thread Keith Whitwell
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 alternative. Flush

Re: Writing a state tracker for Gallium3D/SoftPipe

2008-04-16 Thread Keith Whitwell
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

Re: Gallium: Fix for tgsi_emit_sse2()

2008-04-02 Thread Keith Whitwell
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

Re: Gallium code reorganization

2008-02-15 Thread Keith Whitwell
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 less

Re: redesigning the DRM internal logic..

2008-02-14 Thread Keith Whitwell
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 could just be a

Re: [Mesa3d-dev] Gallium code reorganization

2008-02-14 Thread Keith Whitwell
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 the final layout: - src/mesa - src/gallium

Re: Intel releases 965 documentation under CC license

2008-02-01 Thread Keith Whitwell
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

2008-01-16 Thread Keith Whitwell
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. Here

Re: RFC: render buffer

2008-01-16 Thread Keith Whitwell
Jerome Glisse wrote: On Wed, 2008-01-16 at 17:35 +, 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 buffers may be rendered

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

2007-12-17 Thread Keith Whitwell
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

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

2007-12-17 Thread Keith Whitwell
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. I

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

2007-12-17 Thread Keith Whitwell
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 misleadingly

Re: Proposal for a few minor internal API changes.

2007-12-15 Thread Keith Whitwell
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: Proposal for a few minor internal API changes.

2007-12-15 Thread Keith Whitwell
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 the

Re: Memory manager, sub allocator partial validation

2007-12-12 Thread Keith Whitwell
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. Such

Re: i915: wait for buffer idle before writing relocations

2007-12-10 Thread Keith Whitwell
Keith Packard wrote: On Fri, 2007-12-07 at 11:15 +, 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; we're finishing up the 965 TTM work

Re: i915: wait for buffer idle before writing relocations

2007-12-10 Thread Keith Whitwell
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] Cc: [EMAIL PROTECTED]; dri-devel dri-devel

Re: i915: wait for buffer idle before writing relocations

2007-12-07 Thread Keith Whitwell
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

Re: DRI2 and lock-less operation

2007-11-28 Thread Keith Whitwell
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-space, just

Re: DRI2 and lock-less operation

2007-11-28 Thread Keith Whitwell
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

2007-11-28 Thread Keith Whitwell
Michel Dänzer wrote: On Wed, 2007-11-28 at 09:30 +, 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 and glXCopySubBufferMESA - and thus have to happen

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

2007-11-28 Thread Keith Whitwell
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 drawable lock is

Re: Clip Lists

2007-11-28 Thread Keith Whitwell
Stephane Marchesin wrote: On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Stephane Marchesin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] writes: I fail to see how this works with a lockless design. How do you ensure

Re: Clip Lists

2007-11-28 Thread Keith Whitwell
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* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED

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

2007-11-28 Thread Keith Whitwell
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 in control of the process. That entity

Re: DRI2 and lock-less operation

2007-11-27 Thread Keith Whitwell
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, Keith Packard [EMAIL PROTECTED] wrote: ... I

Re: DRI2 and lock-less operation

2007-11-26 Thread Keith Whitwell
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 lost context emit it before the batchbuffer.. The way

Re: DRI2 and lock-less operation

2007-11-22 Thread Keith Whitwell
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 guessing the

Re: mapped cached memory and pre-fetching.

2007-11-01 Thread Keith Whitwell
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 little at AGP caching issues and there was an issue

Re: intel hw and caching interface to TTM..

2007-10-30 Thread Keith Whitwell
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 slower

Re: [patch] post superioctl inteface removal.

2007-10-18 Thread Keith Whitwell
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 pinned

Re: Merging DRI interface changes

2007-10-12 Thread Keith Whitwell
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: 3) Share buffers with a reference counting scheme. When a client

Re: Merging DRI interface changes

2007-10-11 Thread Keith Whitwell
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 reviewed the changes a

Re: Merging DRI interface changes

2007-10-11 Thread Keith Whitwell
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-overlapping portions

Re: Merging DRI interface changes

2007-10-11 Thread Keith Whitwell
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 doesn't really obey the GLX spec. The renderbuffers

Re: [patch] post superioctl inteface removal.

2007-10-09 Thread Keith Whitwell
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 something more

Re: Initial 915 superioctl patch.

2007-10-08 Thread Keith Whitwell
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

Re: Initial 915 superioctl patch.

2007-10-08 Thread Keith Whitwell
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... Or any reasonably complex game might use 256

Re: DRI2 Design Wiki Page

2007-10-04 Thread Keith Whitwell
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 Michel Daenzer. Relative to the design I

Re: DRI2 Design Wiki Page

2007-10-04 Thread Keith Whitwell
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 DRI driver discovers that the front buffer has changed

Re: DRI2 Design Wiki Page

2007-10-04 Thread Keith Whitwell
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 resizing). Why

Re: drm: Branch 'master'

2007-09-26 Thread Keith Whitwell
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:54 2007

XDS: Intel i965 docs

2007-09-19 Thread Keith Whitwell
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

Re: Vblanks, CRTCs and GLX, oh my!

2007-09-18 Thread Keith Whitwell
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 the

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

2007-09-17 Thread Keith Whitwell
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

TTM BOF topics

2007-08-28 Thread Keith Whitwell
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

Re: DRM enhancements document

2007-08-02 Thread Keith Whitwell
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 for power

Re: Merging DRI changes

2007-06-14 Thread Keith Whitwell
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 think

Re: drm-ttm-cleanup-branch

2007-05-17 Thread Keith Whitwell
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 into the DRM sooner

Re: R200 minor cleanups

2007-05-15 Thread Keith Whitwell
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 common

Re: R300 cleanup questions

2007-05-15 Thread Keith Whitwell
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. */ /* #define RADEON_VTXFMT_A */ #ifdef

Re: R300 cleanup questions

2007-05-09 Thread Keith Whitwell
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 HW_VBOS

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

2007-05-04 Thread Keith Whitwell
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 with

Re: Lockups with Googleearth

2007-03-06 Thread Keith Whitwell
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

Re: [PATCH] R300 early Z cleanup

2007-02-26 Thread Keith Whitwell
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, but it

Re: [PATCH] R300 early Z cleanup

2007-02-26 Thread Keith Whitwell
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 address of early Z to r300_reg.h and use it. Jerome Glisse helped me

Re: mesa: Branch 'master'

2007-01-17 Thread Keith Whitwell
Stephane Marchesin wrote: Keith Whitwell wrote: configs/linux-dri-debug | 16 1 files changed, 16 insertions(+) New commits: diff-tree 3bfbe63806cee1c44da2625daf069b719f2a6097 (from 747c9129c0b592941b14c290ff3d8ab22ad66acb) Author: Keith Whitwell [EMAIL PROTECTED

Re: [r300] VBO broken by changes in mesa

2006-11-21 Thread Keith Whitwell
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 progress on the i915 at least, can you retry over

Re: i915: Xserver crash and restart fails

2006-11-21 Thread Keith Whitwell
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 Xserver

Re: [r300] VBO broken by changes in mesa

2006-11-18 Thread Keith Whitwell
Rune Petersen wrote: Hi, A patch for making sure VBO's are mapped breaks r300: http://marc.theaimsgroup.com/?l=mesa3d-cvsm=116364446305536w=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 change wouldn't

Re: [r300] partly working fragment.position patch

2006-11-02 Thread Keith Whitwell
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 (not with legal means at least) the constant you got with _mesa_add_unnamed_constant. Ah

Re: [r300] partly working fragment.position patch

2006-10-31 Thread Keith Whitwell
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 _mesa_add_unnamed_constant. Ah right. I missed that. I think there exist

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

2006-10-20 Thread Keith Whitwell
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 path in normal operation except for a single command - MI_FLUSH, which is shared between the architectures. In normal operation

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

2006-10-20 Thread Keith Whitwell
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, Keith Whitwell wrote: All of your other wierd problems, like

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

2006-10-18 Thread Keith Whitwell
This is all a little confusing as the driver doesn't really use that path in normal operation except for a single command - MI_FLUSH, which is shared between the architectures. In normal operation the hardware does the validation for us for the bulk of the command stream. If there were

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

2006-10-14 Thread Keith Whitwell
Your drm module is out of date. Keith Ryan Richter wrote: I have a new Intel 965G board, and I'm trying to get DRI working. Direct rendering is enabled, but all GL programs crash immediately. The message 'DRM_I830_CMDBUFFER: -22' is printed on the tty, and the kernel says:

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

2006-10-14 Thread Keith Whitwell
Arjan van de Ven wrote: On Sat, 2006-10-14 at 09:55 +0100, Keith Whitwell wrote: Your drm module is out of date. Since the reporter is using the latest brand spanking new kernel, that is highly unlikely unless something else in the software universe is assuming newer-than-brand-spanking

Re: [r300] partly working fragment.position patch

2006-10-09 Thread Keith Whitwell
Roland Scheidegger wrote: Keith Whitwell wrote: Now I remember why I can't use radeon-dri.drawable, at least not directly when the shader code is added: When the window size changes the constants have to be updated. Is there a way for the driver to update a constant after construction

Re: [r300] partly working fragment.position patch

2006-10-08 Thread Keith Whitwell
Rune Petersen wrote: Keith Whitwell wrote: Rune Petersen wrote: Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: I hit a problem constructing this: - In order to do range mapping in the vertex shader (if I so choose) I will need a constant (0.5), but how to add it? I

Re: [r300] partly working fragment.position patch

2006-10-05 Thread Keith Whitwell
Rune Petersen wrote: Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: I hit a problem constructing this: - In order to do range mapping in the vertex shader (if I so choose) I will need a constant (0.5), but how to add it? I think this might work similar to what is used

Re: [r300] partly working fragment.position patch

2006-09-23 Thread Keith Whitwell
Rune Petersen wrote: It turns out I missed something obvious... The parameters are passed correctly, I have just not transformed the vertex.position to the fragment.position I guess that's the viewport transformation, or maybe a perspective divide followed by viewport transformation. But I

Re: [r300] partly working fragment.position patch

2006-09-23 Thread Keith Whitwell
Rune Petersen wrote: Keith Whitwell wrote: Rune Petersen wrote: It turns out I missed something obvious... The parameters are passed correctly, I have just not transformed the vertex.position to the fragment.position I guess that's the viewport transformation, or maybe a perspective divide

Re: tnl trouble, how can you do hw state changes depending on the primitive being rendered

2006-09-22 Thread Keith Whitwell
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger wrote: Roland Scheidegger wrote: I thought there was a mechanism that allowed the driver to be notified at glBegin (or similar) time. It seems like you ought to be able to emit some extra state at that

  1   2   3   4   5   6   7   8   9   10   >