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
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
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
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
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
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
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
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
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
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
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
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
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/
-
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
* 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.
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
- 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
- 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
- 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
- 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
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
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
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
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
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.
- 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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
Brian Paul wrote:
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
1 - 100 of 1368 matches
Mail list logo
