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 of changes to a
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 up
-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
| context
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 be visible
-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 context A
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.
~ In
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
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 for
-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, 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
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
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 (like
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 */
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 data */
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
-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
use
-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 */
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.
It
-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 being
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
-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
21 matches
Mail list logo
