Hi Atif,
Could you share the link to the webpage and zoom bi-weekly meeting?
Regards,
Ilyes
On Fri, Oct 15, 2021, 08:27 Atif Zafar wrote:
> Hello:
>
> I represent the RISC-V GPU effort at the RISC-V Foundation and would like
> to engage with the MESA team to see if anyone may be interested in
LVMpipe online? I'm quite interested :)
Ilyes
> Roland
>
>
> Am 17.06.2015 um 14:21 schrieb Ilyes Gouta:
> > Hi,
> >
> > On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov > <mailto:drago.iva...@gmail.com>> wrote:
> >
> > Wonderful
Hi,
On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov
wrote:
> Wonderful Marek. Many thanks to you all. I hope till the end of the year
> we will have OGL 4.3 in Mesa.
>
Is LLVMpipe (and software rasterziation) also supported?
Ilyes
>
> On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák wrote:
>
>
Signed-off-by: Ilyes Gouta
---
src/egl/main/Makefile.am | 6 ++
src/gallium/targets/egl-static/Makefile.am | 7 +++
2 files changed, 13 insertions(+)
diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makefile.am
index ca5257a..e71b57f 100644
--- a/src/egl/main
Signed-off-by: Ilyes Gouta
---
src/egl/main/egldisplay.c | 7 ++-
src/egl/main/egldisplay.h | 1 +
src/gallium/state_trackers/egl/common/egl_g3d.c | 6 ++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/egl/main/egldisplay.c
Defining EGLNativeWindowType as a pointer on a IDirectFBSurface
enables for configuring EGL to render into a double-buffered
surface which could be offscreen but also primary (visible).
Signed-off-by: Ilyes Gouta
---
include/EGL/eglplatform.h | 6 ++
1 file changed, 6 insertions(+)
diff
Signed-off-by: Ilyes Gouta
---
src/gallium/winsys/sw/Makefile.am | 4 +
src/gallium/winsys/sw/directfb/Makefile.am | 31 +++
.../winsys/sw/directfb/directfb_sw_winsys.c| 280 +
.../winsys/sw/directfb/directfb_sw_winsys.h| 35
Signed-off-by: Ilyes Gouta
---
src/gallium/state_trackers/egl/Makefile.am | 9 +
src/gallium/state_trackers/egl/common/native.h | 3 +
.../state_trackers/egl/directfb/native_directfb.c | 585 +
3 files changed, 597 insertions(+)
create mode 100644 src
Signed-off-by: Ilyes Gouta
---
configure.ac | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 1c9d606..d74ec94 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1496,7 +1496,7 @@ dnl
AC_ARG_WITH([egl-platforms
NO_CONTEXT, NULL);
surface = eglCreateWindowSurface(display, config[0], pSurface, NULL);
eglMakeCurrent(display, surface, surface, context);
in order to embed a mesa/EGL rendering into a target surface which could
subsequently serve as a source for further processing.
Ilyes Gouta (6):
configure.a
Hi,
+1 for more debugging ease, especially on remote targets.
-Ilyes
On Nov 7, 2012 9:06 PM, "Paul Berry" wrote:
> In situations where an OpenGL function has several equivalent names, Mesa
> currently does not follow a consistent standard for which name is used.
> For example, the function glDi
Hi Dave,
On Thu, Oct 25, 2012 at 11:22 PM, Dave Airlie wrote:
> On Thu, Oct 25, 2012 at 11:12 PM, Jose Fonseca wrote:
>> Gallium interface seems a good place to cleanly separate state tracking from
>> rendering. Everything is already done for you -- you just need to insert RPC
>> between Mesa
Hi,
On Thu, Oct 25, 2012 at 7:40 PM, Ian Romanick wrote:
> On 10/25/2012 02:01 AM, Ilyes Gouta wrote:
>>
>> Hi,
>>
>> Alright, I'm pursuing this idea about splitting mesa into two
>> components, where state tracking happens on the host processor,
>> wh
ing. The two
>> parts would be communicating via a RPC mechanism and sharing the
>> textures and render target buffers. The CPUs are in an AMP
>> configuration.
>>
>> Do you know if the code base (most importantly the data structure) is
>> already designed to ach
ffers. The CPUs are in an AMP
configuration.
Do you know if the code base (most importantly the data structure) is
already designed to achieve this? Has this been done before?
Best regards,
-Ilyes
On Thu, Oct 25, 2012 at 2:34 AM, Kenneth Graunke wrote:
> On 10/24/2012 02:44 PM, Ilyes Gou
Hi,
I'm rather new to mesa and would like to ask if there is still a pure s/w
rendering path for the OpenGL|ES 1.1 pipeline in mesa; that's not LLVM
based (gallium) but just plain C?
If yes, what's it status vs. GLES and is there any additional dependencies?
Thanks,
-Ilyes
_
Hi,
A "Mesa/Gallium state of the art and perspectives" would be awesome!
-Ilyes
On Oct 1, 2011 2:14 PM, "Luc Verhaegen" wrote:
> So far we have:
> * Martin Peres - Nouveau
> * Alon Levy - Xspice
> * Chris Wilson - Cairo
> * Kai Uwe Behrmann - Colormanagement with compositors.
> * Daniel Vetter -
Hi,
Come on guys, we need a "Wayland state of the art" talk! Please :)
-Ilyes
On Sep 26, 2011 8:45 AM, "Luc Verhaegen" wrote:
> On Mon, Sep 26, 2011 at 09:14:05AM +0200, Luc Verhaegen wrote:
>> On Mon, Sep 26, 2011 at 09:09:57AM +0200, Kai-Uwe Behrmann wrote:
>> > Am 26.09.11, 07:21 +0200 schrie
2011 05:37 AM, Alex Deucher wrote:
>>>
>>> On Fri, Aug 26, 2011 at 4:11 AM, Chia-I Wu wrote:
>>>>
>>>> On Fri, Aug 26, 2011 at 3:52 PM, Ilyes Gouta
>>>> wrote:
>>>>>
>>>>> Thanks a lot Chia-l,
>>>>&g
Thank you guys for the information!
-Ilyes
On Fri, Aug 26, 2011 at 4:36 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/26/2011 05:37 AM, Alex Deucher wrote:
>> On Fri, Aug 26, 2011 at 4:11 AM, Chia-I Wu wrote:
>>> On Fri, Aug
accelerated rendering?
Thanks a lot,
-Ilyes
On Fri, Aug 26, 2011 at 4:24 AM, Chia-I Wu wrote:
> On Fri, Aug 26, 2011 at 3:39 AM, Ilyes Gouta wrote:
>> Hi,
>>
>> Is there any document describing the current status of the EGL & GLES
>> 1.x implementation for X11?
&
Hi,
Is there any document describing the current status of the EGL & GLES
1.x implementation for X11?
I've got already some code compiling and running but I'd like to have
a clear idea on the currently implemented feature set (w/ details if
possible, per driver?) and any future plan to beef it up
22 matches
Mail list logo
