Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thomas Hellström wrote:
> | Ian Romanick wrote:
> |> Jerome Glisse wrote:
> |> | On Mon, 19 May 2008 12:04:16 -0700
> |> | Ian Romanick <[EMAIL PROTECTED]> wrote:
> |> |
> |> |> The GLX spec says, basically, that the results
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Hellström wrote:
| Ian Romanick wrote:
|> Jerome Glisse wrote:
|> | On Mon, 19 May 2008 12:04:16 -0700
|> | Ian Romanick <[EMAIL PROTECTED]> wrote:
|> |
|> |> The GLX spec says, basically, that the results of changes to a shared
|> |> object in
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jerome Glisse wrote:
> | On Mon, 19 May 2008 12:04:16 -0700
> | Ian Romanick <[EMAIL PROTECTED]> wrote:
> |
> |> The GLX spec says, basically, that the results of changes to a shared
> |> object in context A are guaranteed to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerome Glisse wrote:
| On Mon, 19 May 2008 12:04:16 -0700
| Ian Romanick <[EMAIL PROTECTED]> wrote:
|
|> The GLX spec says, basically, that the results of changes to a shared
|> object in context A are guaranteed to be visible to context B when
|> cont
On Mon, 19 May 2008 12:04:16 -0700
Ian Romanick <[EMAIL PROTECTED]> wrote:
>
> The GLX spec says, basically, that the results of changes to a shared
> object in context A are guaranteed to be visible to context B when
> context B binds the object. It leaves a lot of slack for changes to
> show u
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
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
>> caching the buffer allocations and doing other things to make it fast
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 17:27 -0700, Ian Romanick wrote:
|
|> Apps are using and will increasingly use the glMapBuffer path. With the
|> information currently at hand, doing the alloc/copy/upload/free in the
|> driver might be the
On Mon, 2008-05-19 at 17:27 -0700, Ian Romanick wrote:
> Apps are using and will increasingly use the glMapBuffer path. With the
> information currently at hand, doing the alloc/copy/upload/free in the
> driver might be the win. Great. It's way too soon to box ourselves
> into that route. If w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote:
|
|> It depends on the hardware. In the second approach the driver has no
|> opportunity to do something "smart" if the copy path isn't the fast
|> path. Applications are b
On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote:
> It depends on the hardware. In the second approach the driver has no
> opportunity to do something "smart" if the copy path isn't the fast
> path. Applications are being tuned more for the hardware where the copy
> path isn't the fast path
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 10:25 -0700, Ian Romanick wrote:
|
|> glBindBuffer(GL_ARRAY_BUFFER, my_buf);
|> GLfloat *data = glMapBufferData(GL_ARRAY_BUFFER, GL_READ_WRITE);
|> if (data == NULL) {
|> /* fail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerome Glisse wrote:
| On Mon, 19 May 2008 10:25:16 -0700
| Ian Romanick <[EMAIL PROTECTED]> wrote:
|
|> | Does in GL3 object must be unmapped before being use ? IIRC this
what is
|> | required in current GL 1.x and GL 2.x. If so i think i can still
us
On Mon, 2008-05-19 at 20:22 +0200, Thomas Hellström wrote:
> I think the point here is when the buffer in 1) is mapped write-combined
> which IMHO is the obvious approach,
> the caches aren't affected at all.
write-combining only wins if you manage to get writes to the same cache
line to line up
Keith Packard wrote:
> On Mon, 2008-05-19 at 10:25 -0700, Ian Romanick wrote:
>
>
>> glBindBuffer(GL_ARRAY_BUFFER, my_buf);
>> GLfloat *data = glMapBufferData(GL_ARRAY_BUFFER, GL_READ_WRITE);
>> if (data == NULL) {
>> /* fail */
>> }
>>
>> /* Fill in buffer
On Mon, 2008-05-19 at 10:25 -0700, Ian Romanick wrote:
> glBindBuffer(GL_ARRAY_BUFFER, my_buf);
> GLfloat *data = glMapBufferData(GL_ARRAY_BUFFER, GL_READ_WRITE);
> if (data == NULL) {
> /* fail */
> }
>
> /* Fill in buffer data */
>
> glUnmapBuf
On Mon, 19 May 2008 10:25:16 -0700
Ian Romanick <[EMAIL PROTECTED]> wrote:
>
> | Does in GL3 object must be unmapped before being use ? IIRC this what is
> | required in current GL 1.x and GL 2.x. If so i think i can still use VRAM
> | as cache ie i put their object which are barely never mapped
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerome Glisse wrote:
| Thanks Ian to stress current and future usage, i was really hopping that
| with GL3 buffer object mapping would have vanish but i guess as you said
| that the fire-and-forget path never get optimized.
I think various drivers ha
On Mon, 19 May 2008 02:22:00 -0700
Ian Romanick <[EMAIL PROTECTED]> wrote:
>
> There is also a bunch of up-and-coming GL functionality that you may not
> be aware of that changes this picture a *LOT*.
>
> - - GL_EXT_texture_buffer_object allows a portion of a buffer object to be
> used to back a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 00:14 -0700, Ian Romanick wrote:
|
|> - - I'm pretty sure that the read_domain = GPU, write_domain = CPU case
|> needs to be handled. I know of at least one piece of hardware with a
|> kooky command buffer
On Mon, 2008-05-19 at 00:14 -0700, Ian Romanick wrote:
> - - I'm pretty sure that the read_domain = GPU, write_domain = CPU case
> needs to be handled. I know of at least one piece of hardware with a
> kooky command buffer that wants to be used that way.
Oh, so mapping the same command buffer fo
21 matches
Mail list logo
