[updated patch attached]
Hmm, yes. Although that has been bumped recently it could be changed to
dynamic, though, but as Dave says,
we need to impose some kind of limit to avoid DOS.
Poulsbo is still using a buffer list from user-space, and there's an
internal kernel array that imposes this lim
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 mig
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 us
On Monday, October 8, 2007 2:14 pm 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
> 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 textures in a f
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 textures in a frame.
nal Message
From: Jesse Barnes <[EMAIL PROTECTED]>
To: Dave Airlie <[EMAIL PROTECTED]>
Cc: dri-devel@lists.sourceforge.net
Sent: Monday, October 8, 2007 6:04:42 PM
Subject: Re: Initial 915 superioctl patch.
I don't know if 42 is better than 256... do we have any measurements
tha
On Sunday, October 7, 2007 4:26 pm Dave Airlie wrote:
> > At a high level, I'm wondering if something like this could be made
> > more generic... It seems like other GPUs will need similar
> > relocation processing so maybe the DRM should grow some generic
> > reloc processing code? Much of this
>
> At a high level, I'm wondering if something like this could be made more
> generic... It seems like other GPUs will need similar relocation processing
> so maybe the DRM should grow some generic reloc processing code? Much of
> this stuff seems fairly generic, so maybe it wouldn't be that har
On Thursday, October 4, 2007 8:55 pm Dave Airlie wrote:
>
Overall, looks nice.
At a high level, I'm wondering if something like this could be made more
generic... It seems like other GPUs will need similar relocation processing
so maybe the DRM should grow some generic reloc processing code? Mu
Okay this is my first public efforts at the i915 driver superioctl.
Please review and give out about anything I missed, I'm sure the error
handling needs "some work". But I thought I'd get it out there..
I have a Mesa side to this in my personal mesa tree (i915-superioctl
branch) but I just
11 matches
Mail list logo
