On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
Hi,
I am a bit puzzled, how a pipe driver should handle
draw callback failure ? On radeon (pretty sure nouveau
or intel hit the same issue) we can only know when one
of the draw_* context callback is call if we can do
the rendering or
On Sun, 2010-02-28 at 21:35 -0800, Corbin Simpson wrote:
On Sun, Feb 28, 2010 at 9:15 PM, Dave Airlie airl...@gmail.com wrote:
On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt b...@zhasha.com wrote:
On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
Hi,
I am a bit puzzled, how a
On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
Hi,
I am a bit puzzled, how a pipe driver should handle
draw callback failure ? On radeon (pretty sure nouveau
or intel hit the same issue) we can only know when one
of the
On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote:
On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
Hi,
I am a bit puzzled, how a pipe driver should handle
draw callback failure ? On radeon (pretty sure
On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote:
On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote:
On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
Hi,
I am a bit puzzled, how a pipe driver should
On Mon, Mar 01, 2010 at 12:55:09PM +0100, Jerome Glisse wrote:
So you don't like the pipe_context::validate() of Jose ? My
taste goes to the pipe_context::validate() and having state
tracker setting the proper flag according to the API they
support (GL_OUT_OF_MEMORY for GL), this means just
On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote:
On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote:
On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote:
On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
Falling back to CPU rendering, while respecting the OpenGL spec, is
likely going to be unusably slow in most cases and thus not really
better for real usage than just not rendering.
I think the only way to have an usable fallback mechanism is to do
fallbacks with the GPU, by automatically
On Mon, Mar 01, 2010 at 01:40:37PM +0100, Olivier Galibert wrote:
On Mon, Mar 01, 2010 at 12:55:09PM +0100, Jerome Glisse wrote:
So you don't like the pipe_context::validate() of Jose ? My
taste goes to the pipe_context::validate() and having state
tracker setting the proper flag according
On Mon, Mar 01, 2010 at 12:24:19PM +, Keith Whitwell wrote:
On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote:
On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote:
On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote:
On Mon, 2010-03-01 at 03:21 -0800, José Fonseca
On Mon, Mar 01, 2010 at 02:57:08PM +0100, Jerome Glisse wrote:
validate function i have in mind as virtualy a zero cost (it will
boil down to a bunch of add followed by a test) and what validate
would do would be done by draw operation anyway.
Not would, will. You have no way to be sure
On Mon, Mar 01, 2010 at 03:24:51PM +0100, Olivier Galibert wrote:
On Mon, Mar 01, 2010 at 02:57:08PM +0100, Jerome Glisse wrote:
validate function i have in mind as virtualy a zero cost (it will
boil down to a bunch of add followed by a test) and what validate
would do would be done by draw
On Mon, Mar 1, 2010 at 3:02 PM, Jerome Glisse gli...@freedesktop.orgwrote:
On Mon, Mar 01, 2010 at 12:24:19PM +, Keith Whitwell wrote:
On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote:
On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote:
On Mon, Mar 01, 2010 at 11:46:08AM
On Mon, Mar 01, 2010 at 04:21:45PM +0100, Marek Olšák wrote:
On Mon, Mar 1, 2010 at 3:02 PM, Jerome Glisse gli...@freedesktop.orgwrote:
On Mon, Mar 01, 2010 at 12:24:19PM +, Keith Whitwell wrote:
On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote:
On Mon, 2010-03-01 at 03:55
On Mon, Mar 01, 2010 at 04:08:32PM +0100, Jerome Glisse wrote:
Do you have solution/proposal/idea on how to handle the situation
i am describing ?
I've been looking at gallium from far away, but it seems to me you
have two independant issues:
- informing the caller of errors in atomic draw()
On Mon, 2010-03-01 at 06:24 -0800, Olivier Galibert wrote:
On Mon, Mar 01, 2010 at 02:57:08PM +0100, Jerome Glisse wrote:
validate function i have in mind as virtualy a zero cost (it will
boil down to a bunch of add followed by a test) and what validate
would do would be done by draw
On Mon, 2010-03-01 at 07:33 -0800, Olivier Galibert wrote:
On Mon, Mar 01, 2010 at 04:08:32PM +0100, Jerome Glisse wrote:
Do you have solution/proposal/idea on how to handle the situation
i am describing ?
I've been looking at gallium from far away, but it seems to me you
have two
Wow, this really got a lot of discussion.
I don't really care *where* the sanity code is, but it just seems
horribly wrong that it's got to be duplicated between per-hook
per-driver in a library that purports simplified drivers with reduced
LOCs. I suppose it's unavoidable to a degree as long as
On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
Hi,
I am a bit puzzled, how a pipe driver should handle
draw callback failure ? On radeon (pretty sure nouveau
or intel hit the same issue) we can only know when one
of the draw_* context callback is call if we can do
the rendering or
On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt b...@zhasha.com wrote:
On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
Hi,
I am a bit puzzled, how a pipe driver should handle
draw callback failure ? On radeon (pretty sure nouveau
or intel hit the same issue) we can only know when
On Sun, Feb 28, 2010 at 9:15 PM, Dave Airlie airl...@gmail.com wrote:
On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt b...@zhasha.com wrote:
On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
Hi,
I am a bit puzzled, how a pipe driver should handle
draw callback failure ? On radeon
21 matches
Mail list logo
