Chia-I Wu writes:
> On Tue, Jan 19, 2010 at 2:40 AM, Brian Paul wrote:
But it's not an application bug.
I could write a GL program that never calls glViewport and still draws
something meaningful before/after window resizing.
>>> If I understand correctly, the application will dra
2010/1/19 Kristian Høgsberg :
[snipped]
>> When we work on code in this area we should also consider the case of
>> using a rendering context that's bound to no window at all. That
>> could be useful for FBO rendering or just compiling shaders, etc.
>> Mesa would probably fail if this were attempt
On Tue, Jan 19, 2010 at 2:45 AM, Brian Paul wrote:
>> This is a corner issue, but suppose two contexts are bound to the same
>> drawable. One of them wants a depth buffer while the other doesn't (or
>> wants a different depth size). There might be a race because one would
>> destroy the depth bu
On Tue, Jan 19, 2010 at 2:40 AM, Brian Paul wrote:
>>> But it's not an application bug.
>>> I could write a GL program that never calls glViewport and still draws
>>> something meaningful before/after window resizing.
>> If I understand correctly, the application will draw to an old buffer if
>> a
On Mon, Jan 18, 2010 at 1:45 PM, Brian Paul wrote:
> Chia-I Wu wrote:
>> On Fri, Jan 15, 2010 at 08:44:27AM -0700, Brian Paul wrote:
>>> Chia-I Wu wrote:
2010/1/15 Michel Dänzer :
Another question I have is, if depth/stencil should be shareable, how
about other buffers like multisam
Chia-I Wu wrote:
> On Fri, Jan 15, 2010 at 08:44:27AM -0700, Brian Paul wrote:
>> Chia-I Wu wrote:
>>> 2010/1/15 Michel Dänzer :
>>> Another question I have is, if depth/stencil should be shareable, how
>>> about other buffers like multisample buffer? (This is a real question that
>>> has
>>> bot
Chia-I Wu wrote:
> On Fri, Jan 15, 2010 at 08:36:55AM -0700, Brian Paul wrote:
If an OpenGL application does not call glViewport upon window resize, is
it consider an application bug?
>>> Yes, the OpenGL viewport isn't automatically adapted on a window resize.
>> But it's not an applicati
On Sat, 2010-01-16 at 10:10 +, Jakob Bornecrantz wrote:
> On 16 jan 2010, at 09.47, Chia-I Wu wrote:
> > On Sat, Jan 16, 2010 at 05:49:44AM +, Jakob Bornecrantz wrote:
> >
> >>> +/* XXX this is WIP! */
> >>> +#define SM_VERSION_MAJOR 0
> >>> +#define SM_VERSION_MINOR 0
> >>> +#define ST_VE
On 16 jan 2010, at 11.47, Chia-I Wu wrote:
> On Sat, Jan 16, 2010 at 10:25:53AM +, Jakob Bornecrantz wrote:
> [snipped]
>>> Both glEGLImageTargetTexture2DOES and vgCreateEGLImageTargetKHR will
>>> take EGLImage as their argument, there needs to be a lookup
>>> function in
>>> st_manager_api to
On Sat, Jan 16, 2010 at 10:25:53AM +, Jakob Bornecrantz wrote:
[snipped]
> >Both glEGLImageTargetTexture2DOES and vgCreateEGLImageTargetKHR will
> >take EGLImage as their argument, there needs to be a lookup
> >function in
> >st_manager_api to return the pipe texture of the image.
> We could ju
On Sat, Jan 16, 2010 at 10:10:17AM +, Jakob Bornecrantz wrote:
> On 16 jan 2010, at 09.47, Chia-I Wu wrote:
> >On Sat, Jan 16, 2010 at 05:49:44AM +, Jakob Bornecrantz wrote:
> >>Here comes a quick review, lot of the things in here are out of date
> >>due to discussions over email so I tried
On Sat, Jan 16, 2010 at 04:32:29AM +, Jakob Bornecrantz wrote:
> I see what the problem is, EGL configurations defer things like
> double buffering to be derived at surface creation time. For GLX
> this is a part of the config from the start. Maybe we should have
> those configureable attribute
On 16 jan 2010, at 10.05, Chia-I Wu wrote:
> On Sat, Jan 16, 2010 at 04:03:52AM +, Jakob Bornecrantz wrote:
>>> I am thinking all resource peeking should be paired with
>>> lock_resource
>>> and unlock_resource. If an extension does not imply access
>>> control, the
>>> sequence might look l
On 16 jan 2010, at 09.47, Chia-I Wu wrote:
> On Sat, Jan 16, 2010 at 05:49:44AM +, Jakob Bornecrantz wrote:
>> Here comes a quick review, lot of the things in here are out of date
>> due to discussions over email so I tried to only comment on bits.
>> A general note is that you seem to have rem
On Sat, Jan 16, 2010 at 04:03:52AM +, Jakob Bornecrantz wrote:
> >I am thinking all resource peeking should be paired with lock_resource
> >and unlock_resource. If an extension does not imply access
> >control, the
> >sequence might look like lock_resource -> increase reference count and
> >st
On Sat, Jan 16, 2010 at 05:49:44AM +, Jakob Bornecrantz wrote:
> Here comes a quick review, lot of the things in here are out of date
> due to discussions over email so I tried to only comment on bits.
> A general note is that you seem to have removed a lot of comments.
> Could you please base
Hi
Here comes a quick review, lot of the things in here are out of date
due to discussions over email so I tried to only comment on bits.
A general note is that you seem to have removed a lot of comments.
Could you please base the a newer version on the st_api.h I sent out.
>
> diff --git a/
On 16 jan 2010, at 02.51, Chia-I Wu wrote:
> On Fri, Jan 15, 2010 at 07:59:08PM +, Jakob Bornecrantz wrote:
>> I don't think that splitting st_visual is a good idea. The
>> framebuffer config needs to be able to tell the renderer if it has
>> stereo, double, depth_stencil in order for it to val
On 16 jan 2010, at 02.31, Chia-I Wu wrote:
> I think we may stick to
>
> st_api and st_context
> st_manager_api and st_framebuffer
>
> Sounds good?
Perfect.
>
> On Fri, Jan 15, 2010 at 05:18:53PM +, Jakob Bornecrantz wrote:
>>> I think all three are important. They should be kept in mind
>>>
On Fri, Jan 15, 2010 at 10:22:43PM +0100, Thomas Hellstrom wrote:
> Don't we also ideally need to catch glReadBuffer / glDrawBuffer
> calls and forward them to the DRI
> state tracker to know whether to request a frontbuffer or not in
> double-buffered mode?
The new st_api allows a state tracker to
On Fri, Jan 15, 2010 at 08:44:27AM -0700, Brian Paul wrote:
> Chia-I Wu wrote:
> >2010/1/15 Michel Dänzer :
> >Another question I have is, if depth/stencil should be shareable, how
> >about other buffers like multisample buffer? (This is a real question that
> >has
> >bothered me for a while. I
On Fri, Jan 15, 2010 at 08:36:55AM -0700, Brian Paul wrote:
> >> If an OpenGL application does not call glViewport upon window resize, is
> >> it consider an application bug?
> > Yes, the OpenGL viewport isn't automatically adapted on a window resize.
> But it's not an application bug.
> I could wr
I think we may stick to
st_api and st_context
st_manager_api and st_framebuffer
Sounds good?
On Fri, Jan 15, 2010 at 05:18:53PM +, Jakob Bornecrantz wrote:
> >I think all three are important. They should be kept in mind
> >while designing
> >the interface. Our versions both have the first
On Fri, Jan 15, 2010 at 07:59:08PM +, Jakob Bornecrantz wrote:
> I don't think that splitting st_visual is a good idea. The
> framebuffer config needs to be able to tell the renderer if it has
> stereo, double, depth_stencil in order for it to validate at
> make_current time. Without having to
Jakob Bornecrantz wrote:
> Hi Chia-I and Luca
>
> you guys are doing great work with the EGL state tracker. So I thought
> it would be a good time to open up a discussion about the way that the
> API state trackers talk to the EGL, dri and other co state trackers.
>
> I have attached a proposed
On 15 jan 2010, at 04.05, Chia-I Wu wrote:
> Hi,
>
> A separate mail for comments to st_api.h.
>
>> struct st_visual
>> {
>> enum pipe_format color_format;
>> enum pipe_format stencil_format;
>> enum pipe_format depth_format;
>> enum pipe_format accum_format;
>>
>> boolean double_buffer;
On 15 jan 2010, at 02.48, Chia-I Wu wrote:
> On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz
> wrote:
>> you guys are doing great work with the EGL state tracker. So I
>> thought it
>> would be a good time to open up a discussion about the way that the
>> API
>> state trackers talk to the
Chia-I Wu wrote:
> 2010/1/15 Michel Dänzer :
>> On Fri, 2010-01-15 at 12:05 +0800, Chia-I Wu wrote:
enum st_framebuffer_attachment {
ST_SURFACE_FRONT_LEFT,
ST_SURFACE_BACK_LEFT,
ST_SURFACE_FRONT_RIGHT,
ST_SURFACE_BACK_RIGHT,
ST_SURFACE_DEPTH_STENCIL,
>>>
Michel Dänzer wrote:
> On Fri, 2010-01-15 at 16:32 +0800, Chia-I Wu wrote:
>> 2010/1/15 Michel Dänzer :
>>> On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote:
On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz
wrote:
> Some things that needs to worked out about this interface is h
On Fri, 2010-01-15 at 11:08 +0100, Christoph Bumiller wrote:
> On 15.01.2010 09:52, Michel Dänzer wrote:
> > On Fri, 2010-01-15 at 16:32 +0800, Chia-I Wu wrote:
> >
> >> 2010/1/15 Michel Dänzer :
> >>
> >>> On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote:
> >>>
> On Fri, Ja
On 15.01.2010 09:52, Michel Dänzer wrote:
> On Fri, 2010-01-15 at 16:32 +0800, Chia-I Wu wrote:
>
>> 2010/1/15 Michel Dänzer :
>>
>>> On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote:
>>>
On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz
wrote:
> Som
2010/1/15 Michel Dänzer :
> On Fri, 2010-01-15 at 16:43 +0800, Chia-I Wu wrote:
>> 2010/1/15 Michel Dänzer :
>> > On Fri, 2010-01-15 at 12:05 +0800, Chia-I Wu wrote:
>> >>
>> >> > enum st_framebuffer_attachment {
>> >> > ST_SURFACE_FRONT_LEFT,
>> >> > ST_SURFACE_BACK_LEFT,
>> >> > ST_SURFA
On Fri, 2010-01-15 at 16:43 +0800, Chia-I Wu wrote:
> 2010/1/15 Michel Dänzer :
> > On Fri, 2010-01-15 at 12:05 +0800, Chia-I Wu wrote:
> >>
> >> > enum st_framebuffer_attachment {
> >> >ST_SURFACE_FRONT_LEFT,
> >> >ST_SURFACE_BACK_LEFT,
> >> >ST_SURFACE_FRONT_RIGHT,
> >> >ST_SURFA
On Fri, 2010-01-15 at 16:32 +0800, Chia-I Wu wrote:
> 2010/1/15 Michel Dänzer :
> > On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote:
> >> On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz
> >> wrote:
> >> > Some things that needs to worked out about this interface is how to
> >> > handle
>
2010/1/15 Michel Dänzer :
> On Fri, 2010-01-15 at 12:05 +0800, Chia-I Wu wrote:
>>
>> > enum st_framebuffer_attachment {
>> > ST_SURFACE_FRONT_LEFT,
>> > ST_SURFACE_BACK_LEFT,
>> > ST_SURFACE_FRONT_RIGHT,
>> > ST_SURFACE_BACK_RIGHT,
>> > ST_SURFACE_DEPTH_STENCIL,
>> > };
>> In my ver
2010/1/15 Michel Dänzer :
> On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote:
>> On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz wrote:
>> > Some things that needs to worked out about this interface is how to handle
>> > glViewport vs DRI2, since the code in glViewport needs to force a update
On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote:
> On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz wrote:
>
> > Some things that needs to worked out about this interface is how to handle
> > glViewport vs DRI2, since the code in glViewport needs to force a update of
> > the buffers in DRI2
On Fri, 2010-01-15 at 12:05 +0800, Chia-I Wu wrote:
>
> > enum st_framebuffer_attachment {
> >ST_SURFACE_FRONT_LEFT,
> >ST_SURFACE_BACK_LEFT,
> >ST_SURFACE_FRONT_RIGHT,
> >ST_SURFACE_BACK_RIGHT,
> >ST_SURFACE_DEPTH_STENCIL,
> > };
> In my version, there is no depth/stencil att
Hi,
A separate mail for comments to st_api.h.
> struct st_visual
> {
>enum pipe_format color_format;
>enum pipe_format stencil_format;
>enum pipe_format depth_format;
>enum pipe_format accum_format;
>
>boolean double_buffer;
> };
As the st_context is able to validate the st_fr
missing attachment...
From 04b5664c798fe81319d6e22e2b47268fd90c0252 Mon Sep 17 00:00:00 2001
From: Chia-I Wu
Date: Wed, 13 Jan 2010 17:57:35 +0800
Subject: [PATCH] gallium: Add st_api.h.
---
src/gallium/include/state_tracker/st_api.h | 278
1 files changed, 278 inse
On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz wrote:
> you guys are doing great work with the EGL state tracker. So I thought it
> would be a good time to open up a discussion about the way that the API
> state trackers talk to the EGL, dri and other co state trackers.
I started some work yes
Hi Chia-I and Luca
you guys are doing great work with the EGL state tracker. So I thought
it would be a good time to open up a discussion about the way that the
API state trackers talk to the EGL, dri and other co state trackers.
I have attached a proposed interface to be used between the d
42 matches
Mail list logo
