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 d
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
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, 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() c
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 wrote:
>
> > 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
On Mon, Mar 1, 2010 at 3:02 PM, Jerome Glisse wrote:
> 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
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 b
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 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
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 acco
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 introduc
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 Gliss
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 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 p
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 (pr
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
On Sun, 2010-02-28 at 21:35 -0800, Corbin Simpson wrote:
> On Sun, Feb 28, 2010 at 9:15 PM, Dave Airlie wrote:
> > On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt wrote:
> >> On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
> >>> Hi,
> >>>
> >>> I am a bit puzzled, how a pipe driver shoul
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 render
On Sun, Feb 28, 2010 at 9:15 PM, Dave Airlie wrote:
> On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt 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
>
On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt 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 one
>>
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 render
21 matches
Mail list logo
