On Thu, Nov 4, 2010 at 1:53 AM, Clurado cl wrote:
>
> Hi all , its interesting topic ,
>
> Q: simply i want to know is there any way to get Hw Accl 3d with DRI and
> draw it on the screen without x ( also glx ) ?!
>
> my first approach is wayland but my device doesnt support pixel and vector
> sha
On Thu, Nov 4, 2010 at 6:14 AM, Clurado cl wrote:
> Hi, i have build mesa with ./configure --disable-gallium-radeon
> --with-dri-drivers=i915 --enable-gles-overlay --enable-gles1
> i make it and installed it in /usr/lib
>
> the problem is i cant run demos in egl/opengles1 demos from
> mesa.demos.8
On Thu, Nov 4, 2010 at 3:27 PM, xiaoxiaomuyu
wrote:
> with export EGL_PLATFORM=drm, I ran egl/demo2 in ctr+alt+f1 terminal other
> than in Xwindow,
>
> struct pipe_screen *
> i915_screen_create(struct i915_winsys *iws)
> {
> struct i915_screen *is = CALLOC_STRUCT(i915_screen);
>
> if (!is)
>
here : http://www.mesa3d.org/egl.html . DRI2 have x
> surface unlinke dri1 it doesnt have framebuffer surface .
>
> so how it used in wayland ?!
The doc is outdated. I will update it.
> On Wed, Nov 3, 2010 at 11:07 PM, Chia-I Wu wrote:
>>
>> On Thu, Nov 4, 2010 at 1:53 AM, Clura
On Fri, Nov 5, 2010 at 1:34 AM, Clurado cl wrote:
>
>
> On Thu, Nov 4, 2010 at 6:56 AM, Chia-I Wu wrote:
>>
>> On Thu, Nov 4, 2010 at 6:14 AM, Clurado cl wrote:
>> > Hi, i have build mesa with ./configure --disable-gallium-radeon
>> > --with-dri-drivers=i9
meet the criteria
> (0x8)
> libEGL debug: the value (0x0) of attribute 0x3025 did not meet the criteria
> (0x1)
> libEGL debug: the value (0x0) of attribute 0x3040 did not meet the criteria
> (0x8)
> EGLUT: failed to choose a config
>
>
> with EGL_DRIVER=egl_dri2 there i
> dobule buffered RGB ... )
>
> but opengles1 demos still not working.
>
> libEGL debug: EGL user error 0x3004 (EGL_BAD_ATTRIBUTE) in eglChoseConfig
> EGLUT: failed to choose config .
I have no idea then. You might want to try the git version, or try
with a debugger.
>
> On Wed, N
Hi list,
I have spent the weekend adding OpenVG 1.1 support to Vega state
tracker. The new features added include mask layer support, text
support, and a new color transformation stage. The work can be found
at
http://cgit.freedesktop.org/~olv/mesa/log/?h=vega-1.1
vega-1.1 branch is based on
On Wed, Dec 1, 2010 at 12:09 AM, Zack Rusin wrote:
> On Tuesday 30 November 2010 04:51:33 Chia-I Wu wrote:
>> Hi list,
>>
>> I have spent the weekend adding OpenVG 1.1 support to Vega state
>> tracker. The new features added include mask layer support, text
2010/12/9 Kristian Høgsberg :
> 2010/12/9 Jammy Zhou :
>> Hi All,
>>
>> Currently I am doing some experiments with mesa 7.9 driver to check the
>> renderer info of underlying OpenGL and OpenGL ES2.0 drivers to decide which
>> driver to use at runtime. With my code attached, the renderer info for GL
On Fri, Dec 10, 2010 at 10:55 AM, Jammy Zhou wrote:
> 2010/12/9 Chia-I Wu
>> 2010/12/9 Kristian Høgsberg :
>> > 2010/12/9 Jammy Zhou :
>> >> Hi All,
>> >>
>> >> Currently I am doing some experiments with mesa 7.9 driver to check the
>
Hi,
With OpenGL ES coming to desktop, the way the current context/dispatch
is stored, together with the way libGLES*.so is created, causes
several issues[1]. The root of these issues is that the symbols
defined in libGL.so and in libGLES*.so overlaps, and an application
might link to both of them
On Fri, Dec 10, 2010 at 4:01 PM, Jammy Zhou wrote:
> On Fri, Dec 10, 2010 at 3:13 PM, Chia-I Wu wrote:
>> With OpenGL ES coming to desktop, the way the current context/dispatch
>> is stored, together with the way libGLES*.so is created, causes
>> several issues[1]. The ro
On Fri, Dec 10, 2010 at 7:03 PM, Chia-I Wu wrote:
> On Fri, Dec 10, 2010 at 4:01 PM, Jammy Zhou wrote:
>> On Fri, Dec 10, 2010 at 3:13 PM, Chia-I Wu wrote:
>>> With OpenGL ES coming to desktop, the way the current context/dispatch
>>> is stored, together with the
On Mon, Dec 13, 2010 at 12:51 PM, Jakob Bornecrantz
wrote:
> On Sun, Dec 12, 2010 at 6:45 PM, Chia-I Wu wrote:
>> On Fri, Dec 10, 2010 at 7:03 PM, Chia-I Wu wrote:
>>> On Fri, Dec 10, 2010 at 4:01 PM, Jammy Zhou wrote:
>>>> On Fri, Dec 10, 2010 at 3:13 PM, Chia-
2010/12/14 Chia-I Wu :
> 2010/12/13 Kristian Høgsberg :
>> On Sun, Dec 12, 2010 at 12:45 PM, Chia-I Wu wrote:
>>> On Fri, Dec 10, 2010 at 7:03 PM, Chia-I Wu wrote:
>>>> On Fri, Dec 10, 2010 at 4:01 PM, Jammy Zhou wrote:
>>>>> On Fri, Dec 10, 2010 at
2010/12/13 Kristian Høgsberg :
> On Sun, Dec 12, 2010 at 12:45 PM, Chia-I Wu wrote:
>> On Fri, Dec 10, 2010 at 7:03 PM, Chia-I Wu wrote:
>>> On Fri, Dec 10, 2010 at 4:01 PM, Jammy Zhou wrote:
>>>> On Fri, Dec 10, 2010 at 3:13 PM, Chia-I Wu wrote:
>>>>&
I am back at this issue with a second try
http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi
In a nutshell, this branch introduces a new configure option,
--enable-shared-glapi. By default it is disabled and things work as
before. But when it is enabled, all except one (more on this be
Since the same-dispatch-offset-different-glx-opcodes functions are
defined in GLX, glXGetProcAddress should be a better place to handle
them specially than _glapi_get_proc_address is. With that change, I
am quite happy with the current status of shared glapi
http://cgit.freedesktop.org/~olv/mes
On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu wrote:
> Since the same-dispatch-offset-different-glx-opcodes functions are
> defined in GLX, glXGetProcAddress should be a better place to handle
> them specially than _glapi_get_proc_address is. With that change, I
> am quite happy with
On Mon, Jan 10, 2011 at 3:23 PM, Chad Versace wrote:
> I am refactoring the method by which extension strings are handled in
> mesa/main/extensions.c. If there are no objections, regressions, nor
> significantly better refactoring alternatives proposed, then I plan to push
> the patch set on Frida
On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu wrote:
> On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu wrote:
>> Since the same-dispatch-offset-different-glx-opcodes functions are
>> defined in GLX, glXGetProcAddress should be a better place to handle
>> them specially than _glap
=vmware@lists.freedesktop.org] On Behalf Of
> Chia-I Wu [olva...@gmail.com]
> Sent: Sunday, January 16, 2011 9:42
> To: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
>
> On Fri, Dec 31, 2010 at 5:38 PM, Chia-I W
From: Chia-I Wu
GLES can be enabled by running scons with
$ scons gles=yes
When gles=yes is given, the build is changed in three ways. First,
libmesa.a will be built with FEATURE_ES1 and FEATURE_ES2. This makes
DRI drivers and libEGL support and advertise GLES support. Second, GLES
On Thu, Jan 20, 2011 at 11:06 PM, Jakob Bornecrantz
wrote:
> On Sun, Jan 16, 2011 at 10:42 AM, Chia-I Wu wrote:
>> On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu wrote:
>>> On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu wrote:
>>>> Since the same-dispatch-offset-diffe
See also
> http://www.reddit.com/r/programming/comments/eyl75/i_saw_a_book_entitled_die_gnu_autotools_and_i/
> for a laugh. ;-)
Good one :)
> Jose
>
> On Thu, 2011-01-20 at 06:23 -0800, Chia-I Wu wrote:
>> From: Chia-I Wu
>>
>> GLES can be enabled by running scons with
>
On Fri, Jan 21, 2011 at 5:04 PM, Chia-I Wu wrote:
> On Fri, Jan 21, 2011 at 12:18 AM, José Fonseca wrote:
>> Hi Olv,
>>
>> Looks good to me FWIW.
> Thanks.
>> I think we should avoid having opengl32.dll or the ICD loading
>> glapi.dll, but that's not a
On Fri, Jan 28, 2011 at 9:22 AM, Jammy Zhou wrote:
> Just to make sure that this patch was sent out, so replied again here.
>
> Hi Chia-I,
>
> Could you please review this small patch?
Sorry for the slow response. I recently had a surgery and I was not
able to spend much time on my inbox. I will
On Sat, Jan 22, 2011 at 5:31 PM, Krzysztof Smiechowicz wrote:
> Hello,
>
> I'm the maintainer of Mesa port for AROS (www.aros.org). I recently
> backported Mesa 7.10 and noticed a considerable speed regression. After some
> testing I narrowed the problem down to commit:
> 859106f196ade77f59f8787b0
On Tue, Jan 25, 2011 at 10:08 PM, José Fonseca wrote:
> Sorry for the delay. I thought I had replied but didn't.
> On Fri, 2011-01-21 at 01:04 -0800, Chia-I Wu wrote:
>> On Fri, Jan 21, 2011 at 12:18 AM, José Fonseca wrote:
>> > Hi Olv,
>> >
>> > Looks
On Fri, Jan 28, 2011 at 2:08 AM, Alberich de megres
wrote:
> I did configure again, with the same error.
>
> I'm using this configure line:
>
> ./autogen.sh --prefix=$HOME/install --enable-egl --enable-gles2 \
> --enable-gallium-nouveau --with-state-trackers=glx,dri,egl \
> --
On Sat, Jan 29, 2011 at 10:19 PM, Arthur Zhu
wrote:
>
> drmdpy->event_handler->new_drm_screen(&drmdpy->base, name, drmdpy->fd);
>
> Dose there have a chance to call new_sw_screen?
You cannot use swrast with DRM. Judging by the log below, you have an
i915 card. It is best supported by egl_dri2, w
On Sat, Jan 29, 2011 at 4:08 AM, Paulo Zanoni wrote:
>
> Signed-off-by: Paulo Zanoni
> ---
>
> My cmake-fu is not good. Maybe there are better ways to fix this. Suggestions
> are always welcome =D
Thanks for the patch. I've committed a similar fix from Jure Repinc
(bug #33505).
> src/egl/opengl
ed some kind of warnings about package missing or just don't
> check them up to users?
Yeah, something like --enable-egl-dri2 would be helpful. Mind to work
on a patch?
> Best Regards,
> Arthur
>
>
> 2011/1/30 Chia-I Wu
>>
>> On Sat, Jan 29, 2011 at 10:19 PM, Arthur
2011/2/6 Arthur Zhu :
> From 7f26f3b6692a8a8061c0d817388505d4190e88a0 Mon Sep 17 00:00:00 2001
> From: Arthur Zhu
> Date: Mon, 7 Feb 2011 13:50:55 +0800
> Subject: [PATCH] Adding --enable-egl-dri2-x11&drm option.
>
> ---
> configure.ac | 34 +-
> 1 files changed,
On Wed, Feb 16, 2011 at 7:01 AM, Dan Nicholson wrote:
> On Wed, Feb 16, 2011 at 5:37 AM, Jon TURNEY
> wrote:
>> Fix a typo which meant that --enable-shared-glapi didn't actually cause a
>> shared glapi to be built
>>
>> Signed-off-by: Jon TURNEY
>> ---
>> configure.ac | 2 +-
>> 1 files ch
On Mon, Feb 21, 2011 at 8:12 PM, Tom Fogal wrote:
> From: Tom Fogal
>
> Without this, we do not actually respect the request for TLS.
What is your setup? The macro should be defined as part of $(CFLAGS).
It may not be a good practice as the variable is normally considered
a user variable, but m
On Mon, Feb 21, 2011 at 10:39 PM, tom fogal wrote:
> Chia-I Wu writes:
>> On Mon, Feb 21, 2011 at 8:12 PM, Tom Fogal wrote:
>> > From: Tom Fogal
>> >
>> > Without this, we do not actually respect the request for TLS.
>>
On Tue, Feb 22, 2011 at 1:56 AM, Thomas Hellstrom wrote:
> Hi, Chia-I,
>
> Looking at the EGL DRM implementation of swapbuffers, it looks like we're
> sort of ad-hoc attaching the backbuffer as a new scanout surface, using
> drmModeSetCrtc.
>
> I don't think this works very well on all hardware. I
On Wed, Feb 23, 2011 at 5:22 PM, Thomas Hellstrom wrote:
> On 02/22/2011 07:44 PM, Chia-I Wu wrote:
>>
>> On Tue, Feb 22, 2011 at 1:56 AM, Thomas Hellstrom
>> wrote:
>>
>>>
>>> Hi, Chia-I,
>>>
>>> Looking at the EGL DRM implem
On Thu, Feb 24, 2011 at 7:02 PM, Dave Airlie wrote:
> So I don't understand dispatch so well,
>
> but I wrote a new piglit test today and it segfaults with a NULL ptr
> when calling glFramebufferTextureLayerEXT, but runs
> fine with glFramebuferTextureLayer, anyone care to comment where I
> droppe
On Sat, Apr 16, 2011 at 2:20 AM, Matt Turner wrote:
> Hi,
> I'm having trouble running any OpenGL ES programs from mesa-demos. It
> seems to be identical to what was reported here
> http://comments.gmane.org/gmane.comp.video.mesa3d.devel/22575
>
> I'm using a Sandy Bridge system. Direct Rendering
From: Chia-I Wu
It has no user after the removal of st_public. Plus, it has never been
implemented by a pipe driver or winsys.
---
src/gallium/auxiliary/util/u_simple_screen.h |5 -
src/gallium/include/pipe/p_screen.h |7 ---
2 files changed, 0 insertions(+), 12
On Mon, Apr 12, 2010 at 12:37:10PM -0400, Kristian Høgsberg wrote:
> I've been looking into the GLES1/2 support in mesa and trying to
> figure out how to make it work for DRI drivers as well. The current
> approach only works for gallium, and it works by compiling mesa core
> as different state tr
2010/4/25 Kristian Høgsberg :
> On Sat, Apr 24, 2010 at 10:25 AM, Jakob Bornecrantz
>> -PUBLIC const struct st_module st_module_OpenGL_ES1 = {
>> - .api = ST_API_OPENGL_ES1,
>> - .create_api = st_manager_create_api
>> -};
>> +PUBLIC struct st_api *
>> +st_api_create_OpenGL_ES1()
>> +{
>> + re
Hi Jakob,
On Sat, Apr 24, 2010 at 10:25 PM, Jakob Bornecrantz
wrote:
> This Patch series does some minor refactoring in the st_api interface
> and some major one to st/dri.
> The first patch drops the st_module struct from st_api. This is because it
> was overlapping the st_api struct. Both repre
On Tue, Apr 27, 2010 at 6:14 AM, Dan Nicholson wrote:
> On Mon, Apr 26, 2010 at 2:16 PM, Chris Ball wrote:
>> http://tinderbox.x.org/builds/2010-04-26-0020/logs/libGL/#build
>> gmake[3]: *** No rule to make target `depend', needed by `default'. Stop.
>> gmake[2]: *** [../../../progs/egl/eglut/li
On Mon, Apr 26, 2010 at 6:54 PM, Keith Whitwell wrote:
> On Sat, 2010-04-24 at 07:25 -0700, Jakob Bornecrantz wrote:
>> Hi Chia-I et all
>>
>> This Patch series does some minor refactoring in the st_api interface
>> and some major one to st/dri.
>>
>> The first patch drops the st_module struct fro
2010/4/28 Kristian Høgsberg :
> 2010/4/27 Kristian Høgsberg :
> [ I hit send to early there... ]
>> review the patches, or at least just some of them. The overall
>> approach is
>
> 1. Add a API tag to GLcontext so we key off of that.
> 2. Use API-aware constructor where we create GLES1/2 contex
2010/4/29 Kristian Høgsberg :
> 2010/4/28 Chia-I Wu :
>> 2010/4/28 Kristian Høgsberg :
>>> 2010/4/27 Kristian Høgsberg :
>>> [ I hit send to early there... ]
>>>> review the patches, or at least just some of them. The overall
>>>> approach is
&
Hi all,
I've been working on and off for a while on a dispatcher builder called mapi
(multiple-api, in contrary to gl-api). The code is available at
http://cgit.freedesktop.org/~olv/mesa/log/?h=mapi
The motivation is to build a dispatcher for OpenVG. I will give an overview
for mapi in this
On Mon, May 3, 2010 at 12:24 AM, Zack Rusin wrote:
> On Saturday 01 May 2010 15:27:45 Chia-I Wu wrote:
>> I've been working on and off for a while on a dispatcher builder called
>> mapi (multiple-api, in contrary to gl-api). The code is available at
>>
>> http:
On Mon, May 3, 2010 at 11:10 PM, wrote:
> Ok. I removed "-Wl,--as-needed" and now compilation went smooth.However
> when I enable gles1 and gles2 and add es state tracker I got something like
> this:
>
> mklib: Making Linux shared library: libGL.so.1.2
> mklib: Installing libGL.so.1.2 libGL.so.
On Wed, May 5, 2010 at 5:01 AM, Gregory Prisament
wrote:
> Hi,
> I just did a "git pull" and I'm no longer able to build the egl demo apps
> (mesa/progs/egl/opengles1/* and mesa/progs/egl/opengles2/*). These were
> working for me previously.
>
> ES1:
> gcc -g -O2 -Wall -Wmissing-prototypes -std=c
2010/5/2 Chia-I Wu :
> I've been working on and off for a while on a dispatcher builder called mapi
> (multiple-api, in contrary to gl-api). The code is available at
>
> http://cgit.freedesktop.org/~olv/mesa/log/?h=mapi
>
> The motivation is to build a dispatcher for
On Wed, May 5, 2010 at 6:04 PM, Keith Whitwell wrote:
> On Tue, 2010-05-04 at 22:48 -0700, Chia-I Wu wrote:
>> 2010/5/2 Chia-I Wu :
>> > I've been working on and off for a while on a dispatcher builder called
>> > mapi
>> > (multiple-api, in contr
2010/5/5 Chia-I Wu :
> 2010/5/2 Chia-I Wu :
>> I've been working on and off for a while on a dispatcher builder called mapi
>> (multiple-api, in contrary to gl-api). The code is available at
>>
>> http://cgit.freedesktop.org/~olv/mesa/log/?h=mapi
>>
>>
Hi all,
I've updated docs/opengles.html to add a table that should help understand how
the new --enable-gles* options affect the final libraries. It is under the
"Internal Libraries" subsection. JFYI.
--
o...@lunarg.com
___
mesa-dev mailing list
mesa
On Sat, May 8, 2010 at 3:56 AM, Jakob Bornecrantz wrote:
> On Fri, May 7, 2010 at 7:33 PM, Keith Whitwell wrote:
>> On Fri, 2010-05-07 at 10:47 -0700, Jakob Bornecrantz wrote:
>>> 2010/5/7 Kristian Høgsberg :
>>> > 2010/5/7 Jakob Bornecrantz :
>>> > ...
>>> >>> No I understand that. We currently
On Mon, May 10, 2010 at 7:58 PM, Kevin H. Hobbs wrote:
> I run several nightly builds of VTK and ParaView with Mesa from the git
> repository.
>
> My builds for May 6 failed because Mesa failed to build.
>
> Mesa is built with :
>
> # Update Mesa
> echo "Update Mesa"
> cd /home/kevin/mesa
> make r
On Mon, May 10, 2010 at 11:09 PM, Kevin H. Hobbs wrote:
> On 05/10/2010 09:46 AM, Brian Paul wrote:
>>
>> A 'make clean' may be needed. Sometimes when source files move around
>> the 'depend' files don't get properly updated.
>>
>> -Brian
>
>
> I get the same result after 'make clean' err.. at le
On Wed, May 12, 2010 at 4:24 PM, xiaoxiaomuyu
wrote:
> Are they in any branch of mesa? without them i can't compile wayland
> successfully.
I believe they are on Kristian's egl-kms branch
http://cgit.freedesktop.org/~krh/mesa/log/?h=egl-kms
and haven't been upstreamed yet. Please use wayland
2010/5/18 Jakob Bornecrantz :
> 2010/5/17 Kristian Høgsberg :
>> The EGL native platform API is determined at compile time and resolves
>> to Win32, X11 or Symbian at this point. This means that if we want to
>> support XCB or a native DRM implementation, they have to be their platforms
>> and re
2010/5/18 Kristian Høgsberg :
> On Tue, May 18, 2010 at 12:41 PM, Chia-I Wu wrote:
>> 2010/5/18 Jakob Bornecrantz :
>>> 2010/5/17 Kristian Høgsberg :
>>>> The EGL native platform API is determined at compile time and resolves
>>>> to Win32, X11 or Symb
2010/5/18 Kristian Høgsberg :
> 2010/5/18 Chia-I Wu :
>> 2010/5/18 Kristian Høgsberg :
>>> On Tue, May 18, 2010 at 12:41 PM, Chia-I Wu wrote:
>>>> 2010/5/18 Jakob Bornecrantz :
>>>>> 2010/5/17 Kristian Høgsberg :
>>>>>> The EGL
On Wed, May 19, 2010 at 2:48 PM, Jakob Bornecrantz wrote:
> 2010/5/19 Chia-I Wu :
>> 2010/5/18 Kristian Høgsberg :
>>> 2010/5/18 Chia-I Wu :
>>>> 2010/5/18 Kristian Høgsberg :
>>>>> On Tue, May 18, 2010 at 12:41 PM, Chia-I Wu wrote:
>>>>&g
2010/5/28 Kristian Høgsberg :
> 2010/5/27 Brian Paul :
>> Kristian Høgsberg wrote:
>>>
>>> This patch introduces a new extension to allow different ways to
>>> create an EGLDisplay to exist within the same libEGL.so. The new
>>> extension, EGL_MESA_get_display, introduces a new entrypoint:
>>>
>>>
Hi all,
I've got access to a Windows machine recently, and I've spent some time today
to add GDI backend to st/egl. The code can be found at
http://cgit.freedesktop.org/~olv/mesa/log/?h=egl-gdi
The command options I use to build the DLLs are
$ scons statetrackers=egl drivers=softpipe
The
2010/5/28 Kristian Høgsberg :
> 2010/5/28 Chia-I Wu :
> ...
>> The right fix is to define a sensible "xorg/drm" platform which has different
>> EGLNative{Display,Window,Pixmap}Type than the tentative ones as defined in
>> eglplatform.h. The new platform
On Sat, May 29, 2010 at 1:19 AM, Jakob Bornecrantz wrote:
> On Fri, May 28, 2010 at 8:46 AM, Chia-I Wu wrote:
>> I've got access to a Windows machine recently, and I've spent some time today
>> to add GDI backend to st/egl. The code can be found at
>> http://cgi
Hi Jakob,
I like the way the extensions are separated and presented. But I have some
thoughts about the entrypoints and EGL types to use.
To begin with, I think the goal of this series of extensions is to export a
subset of pipe_screen->resource_create, pipe_screen->resource_from_handle, and
pip
On Sun, May 30, 2010 at 6:35 AM, Chia-I Wu wrote:
> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR to be
> queryable, which is stemmed from using EGLImageKHR to represent pipe_resource.
> Using an EGLImageKHR also implies that an implementation must implement
&
2010/6/3 Kristian Høgsberg :
>> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR to
>> be
>> queryable, which is stemmed from using EGLImageKHR to represent
>> pipe_resource.
>> Using an EGLImageKHR also implies that an implementation must implement
>> EGLImage in EGL/GLES
2010/6/3 Chia-I Wu :
> 2010/6/3 Kristian Høgsberg :
>>> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR to
>>> be
>>> queryable, which is stemmed from using EGLImageKHR to represent
>>> pipe_resource.
>>> Using an EGLI
2010/6/3 Kristian Høgsberg :
> 2010/6/3 Chia-I Wu :
>> 2010/6/3 Kristian Høgsberg :
>>>> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR
>>>> to be
>>>> queryable, which is stemmed from using EGLImageKHR to represent
>&
2010/6/4 Jakob Bornecrantz :
>> And also because the use case for it was solved in another way. But in
>> defence of my create_image extension, its quite small and limited in
>> scope. But in Chia-I fav the fact that we lack configs to say which
>> formats we support is a bit sad. But I can also se
2010/6/4 Kristian Høgsberg :
> 2010/6/3 Chia-I Wu :
>> 2010/6/3 Kristian Høgsberg :
>>> 2010/6/3 Chia-I Wu :
>>>> 2010/6/3 Kristian Høgsberg :
>>>>>> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR
>>>>>>
Hi Kristian,
2010/6/4 Kristian Høgsberg :
> Here's an update on the EGL/DRM integration extensions and patches.
> I've updated the patches with the feedback from the discussions on the
> list to the extent that I think is feasible. I think we're pretty
> close to consensus on how to do this, but
2010/6/4 Jakob Bornecrantz :
> Kristian and I discussed this on IRC and I think we got an agreement
> on the way forward. I'll inline the comments below in the spec file.
>
> 2010/6/4 Kristian Høgsberg :
>> ---
>> docs/MESA_image_drm.spec | 101
>> +
>
2010/6/11 Kristian Høgsberg :
> 2010/6/10 Chia-I Wu :
>> Hi Kristian,
>>
>> 2010/6/4 Kristian Høgsberg :
>>> Here's an update on the EGL/DRM integration extensions and patches.
>>> I've updated the patches with the feedback from the discussi
rebase
your work on it. The patch allows me to do some cleanups to st/egl. What do
you think?
--
o...@lunarg.com
From 312d1d2526174277f1cd937b3d1a65d7329557eb Mon Sep 17 00:00:00 2001
From: Chia-I Wu
Date: Thu, 17 Jun 2010 17:14:03 +0800
Subject: [PATCH 1/3] egl: Introduce platform displays inte
2010/6/22 Kristian Høgsberg :
> I think the egl-drm-display branch looks good. The platform display
> patch is definitely good to commit, and I don't see a problem in
> merging the entire egl-drm-display branch either. As I said before, I
> was practically sold on the multi-egl idea, until I real
On Thu, Jun 24, 2010 at 9:30 AM, nobled wrote:
> Debian just tried to build gallium on the FreeBSD and Hurd kernels
> last week and ran into build failures:
> http://bugs.debian.org/585618
>
> The first two (very small) patches should help fix that, so it would be
> awesome
> if they could get in
On Sat, Jul 3, 2010 at 7:38 AM, nobled wrote:
> Fixes the build on Windows.
Applied. Thanks.
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Jul 6, 2010 at 4:39 AM, Lionel Landwerlin wrote:
> I'm trying to build the last Mesa 7.8.2 on top of an Xlib stack.
> What I need, is a software implementation of GLES 2.0 with EGL.
> This is how I configure Mesa :
>
> ./configure --disable-glu --disable-glw --disable-glut --with-driver=xl
On Sun, Jul 11, 2010 at 1:18 AM, Lionel Landwerlin
wrote:
> Thanks for your response, it worked well.
>
> I have another question but first I think I need to give some context.
>
> I'm trying to build an environment on my laptop which mimics what I'm
> going to use on an embedded target. What I ex
On Tue, Jul 13, 2010 at 4:25 PM, Lionel Landwerlin
wrote:
> On Tue, Jul 13, 2010 at 9:40 AM, Chia-I Wu wrote:
>> On Sun, Jul 11, 2010 at 1:18 AM, Lionel Landwerlin
>> wrote:
>>> Thanks for your response, it worked well.
>>>
>>> I have another ques
On Tue, Jul 13, 2010 at 9:57 AM, nobled wrote:
> Fixes a fatal build error when compiling just OpenGL ES libraries, since
> FEATURE_EXT_framebuffer_blit is disabled then, so the BlitFramebuffer
> member doesn't exist.
Is this change enough to make dri_r300 function as a GLES only driver?
To be ho
On Thu, Jul 15, 2010 at 10:26 AM, Brian Paul wrote:
> I've pushed a branch which implements the GL_NV_primitive_restart
> extension (part of GL 3.1).
>
> It currently works for Gallium softpipe and llvmpipe but there's still
> a few loose ends.
>
> The new gallium interface for this isn't finalize
Hi all,
This patch series replaces
st_context::draw_arrays
st_context::draw_elements,
st_context::draw_arrays_instanced
st_context::draw_elements_instanced
st_context::draw_range_elements
by a single
st_context::draw_vbo(struct pipe_context *pipe,
const struct
On Sat, Jul 17, 2010 at 2:28 AM, Jakob Bornecrantz wrote:
> On Fri, Jul 16, 2010 at 11:10 AM, Chia-I Wu wrote:
>> Hi all,
>>
>> This patch series replaces
>>
>> st_context::draw_arrays
>> st_context::draw_elements,
>> st_context::draw_arrays_inst
On Sat, Jul 17, 2010 at 8:38 AM, Brian Paul wrote:
> On Fri, Jul 16, 2010 at 4:42 PM, Jerome Glisse wrote:
>> On 07/16/2010 03:18 PM, Chia-I Wu wrote:
>>>
>>> On Sat, Jul 17, 2010 at 2:28 AM, Jakob Bornecrantz
>>> wrote:
>>>>
>>
re there any plan to implement it?
Does the attached patch work for you? I've had it for a while, but did not
commit it due to the lack of a demo to verify.
--
o...@lunarg.com
From 0f5fbcfaff37fc846d2b4867cfd438c9e11ceb34 Mon Sep 17 00:00:00 2001
From: Chia-I Wu
Date: Fri, 12 Mar 2010 09:54
[change the subject because of typo and it is not about the patch]
On Sun, Jul 18, 2010 at 7:31 PM, Keith Whitwell wrote:
> If we're reorganising these interfaces, there are a couple of things I'd
> like to see done differently. In particular, within your draw_info
> struct there are a couple of
On Wed, Jul 21, 2010 at 10:29 PM, Keith Whitwell wrote:
> On Mon, 2010-07-19 at 00:46 -0700, Chia-I Wu wrote:
>> [change the subject because of typo and it is not about the patch]
>>
>> On Sun, Jul 18, 2010 at 7:31 PM, Keith Whitwell wrote:
>> > If we're reorg
This is the second try for unified draw_vbo call. I again upload the
patches as a branch here
http://cgit.freedesktop.org/~olv/mesa/log/?h=gallium-unified-draw-2
due to the size.
Changes since v1:
- make index buffer a state and add pipe_context::set_index_buffer
- there is a boolean in
On Tue, Jul 27, 2010 at 11:46 PM, Keith Whitwell wrote:
> On Mon, 2010-07-26 at 21:36 -0700, Chia-I Wu wrote:
>> This is the second try for unified draw_vbo call. I again upload the
>> patches as a branch here
>>
>> http://cgit.freedesktop.org/~olv/mesa/log/?h=galli
On Tue, Jul 27, 2010 at 12:36 PM, Chia-I Wu wrote:
> This is the second try for unified draw_vbo call. I again upload the
> patches as a branch here
>
> http://cgit.freedesktop.org/~olv/mesa/log/?h=gallium-unified-draw-2
>
> due to the size.
>
> Changes since v1:
&g
On Sat, Jul 31, 2010 at 7:10 AM, Zack Rusin wrote:
> On Friday 30 July 2010 17:51:21 Jakob Bornecrantz wrote:
>> On 30 jul 2010, at 14.02, Jakob Bornecrantz wrote:
>> > On 30 jul 2010, at 13.32, Brian Paul wrote:
>> >> On 07/30/2010 12:38 PM, Jerome Glisse wrote:
>> >>> Hi Brian,
>> >>>
>> >>> I a
On Tue, Aug 3, 2010 at 6:48 AM, Zack Rusin wrote:
> On Monday 02 August 2010 12:33:50 Chia-I Wu wrote:
>> While studying the draw module, I noticed that multiple primitive
>> decomposers exist: draw_pt_vcache_tmp.h, draw_gs_tmp.h,
>> draw_so_emit_tmp.h, and draw_pt_decompos
601 - 700 of 713 matches
Mail list logo
