Keith Packard wrote:
>I will not be able to comment on unreleased hardware designs and how
>they affect the DRM design. Suffice it to say that this granularity of
>signalling seems unnecessary to me; a single flush operation that was
>signalled at the end of the sequence to free all of these buffe
On Thu, 2007-12-27 at 10:34 +0100, Thomas Hellström wrote:
> This would not be sufficient to optimize the (re-)use of buffers.
Buffers are ready for re-use when they are no longer referenced by the
command stream and when some kind of flush operation has occurred to
remove them from caches or ot
Keith Packard wrote:
>
>In particular, I think that adding what amounts to a state machine to
>the fencing logic is a bad idea -- if the driver needs a state machine
>to complete a particular fence, the driver should implement that state
>machine internally. If the driver has no IRQs to drive that
On Wed, 2007-12-26 at 14:46 +0100, Thomas Hellström wrote:
> Keith Packard wrote:
> > On Tue, 2007-12-25 at 14:24 +0100, Thomas Hellström wrote:
> >
> >
> >> The fence type bits are solely intended to indicate different completion
> >> stages, so if the union of access modes defined as (RWX
Keith Packard wrote:
> On Tue, 2007-12-25 at 14:24 +0100, Thomas Hellström wrote:
>
>
>> The fence type bits are solely intended to indicate different completion
>> stages, so if the union of access modes defined as (RWX) is the
>> same for all fence objects of a particular driver, you're ri
On Tue, 2007-12-25 at 14:24 +0100, Thomas Hellström wrote:
> The fence type bits are solely intended to indicate different completion
> stages, so if the union of access modes defined as (RWX) is the
> same for all fence objects of a particular driver, you're right. Fence
> flushing of a part
Thomas Hellström wrote:
>
> 3) The validation code emits an MI_FLUSH, updates the breadcrumb
> counter, updates the last_write_flush sequence to the current breadcrumb
> number and then emits a new fence object, f_new.
> 4) The validation code dereferences the old fence object pointed to by
> bu
Keith Packard wrote:
> On Sat, 2007-12-22 at 23:40 +0100, Thomas Hellström wrote:
>
>
>> DRM_I915_FENCE_TYPE_READ | DRM_I915_FENCE_TYPE_WRITE | DRM_FENCE_TYPE_EXE
>>
>
> The union of all access modes is always read|write|exe (read from vbos,
> write to back buffer, execute from batch buffer
On Sat, 2007-12-22 at 23:40 +0100, Thomas Hellström wrote:
> DRM_I915_FENCE_TYPE_READ | DRM_I915_FENCE_TYPE_WRITE | DRM_FENCE_TYPE_EXE
The union of all access modes is always read|write|exe (read from vbos,
write to back buffer, execute from batch buffer). Hence, these bits
cannot carry any nove
Keith Packard wrote:
>On Sat, 2007-12-22 at 07:59 +0100, Thomas Hellström wrote:
>
>
>
>>The way I would do this with a small extension to the current
>>implementation is to
>>implement a DRM_I915_FENCE_TYPE_READ fence type and a
>>DRM_I915_FENCE_TYPE_WRITE fence type, which are triggered by t
On Sat, 2007-12-22 at 07:59 +0100, Thomas Hellström wrote:
> The way I would do this with a small extension to the current
> implementation is to
> implement a DRM_I915_FENCE_TYPE_READ fence type and a
> DRM_I915_FENCE_TYPE_WRITE fence type, which are triggered by the
> corresponding buffer obj
Keith Packard wrote:
>On Fri, 2007-12-21 at 13:40 +0100, Thomas Hellström wrote:
>
>
>
>>// Change only the RW flags, and set them to "Write"
>>validate(bo, DRM_BO_FLAG_WRITE , DRM_BO_FLAG_READ | DRM_BO_FLAG_WRITE)
>>Render to buffer object.
>>// Change only the RW flags, and set them to "READ"
On Fri, 2007-12-21 at 13:40 +0100, Thomas Hellström wrote:
> // Change only the RW flags, and set them to "Write"
> validate(bo, DRM_BO_FLAG_WRITE , DRM_BO_FLAG_READ | DRM_BO_FLAG_WRITE)
> Render to buffer object.
> // Change only the RW flags, and set them to "READ"
> validate(bo, DRM_BO_FLAG_RE
Keith Packard wrote:
>Right now, the GPU access mode on a buffer is stored in the buffer
>object itself, which means buffers must always be used in the same way
>with the GPU. However, buffers may be read sometimes (textures) and
>written others (render to texture). It seems like the GPU access mo
Right now, the GPU access mode on a buffer is stored in the buffer
object itself, which means buffers must always be used in the same way
with the GPU. However, buffers may be read sometimes (textures) and
written others (render to texture). It seems like the GPU access mode of
the buffer should be
15 matches
Mail list logo
