format_and_type may return either mesa_format or
mesa_array_format, which needs further decoding since here we do need
a mesa_format. The attached patch unbreaks this — please apply it for
me if reviewed.
Thanks.
Alexander
From 2078c405133b321610a765e43784f30eddd0e722 Mon Sep 17 00:00:00 2001
From
lpha channgel in RGBX formats.
>>
>> More importantly for the next patch is moving the test into its own
>> function for the purpose of exporting the check to the callers.
>>
>> Signed-off-by: Chris Wilson
>> Cc: Jason Ekstrand
>> Cc: Alexander Monakov
>&
g the test into its own
> function for the purpose of exporting the check to the callers.
>
> Signed-off-by: Chris Wilson
> Cc: Jason Ekstrand
> Cc: Alexander Monakov
> Cc: Kristian Høgsberg
> Cc: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/intel_blit.c | 38
I wonder if PBO drawpixels in intel_pixel_draw.c needs the same treatment?
Thanks.
Alexander
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
i965 texture fast upload path did not work in 9.2.x due to this tiling
change, but was improved for 10.0 release series; however, you need to
use GL_UNSIGNED_BYTE format rather than GL_UNSIGNED_INT_8_8_8_8_REV to
hit it. With that, upload on 10.0.x should be almost as fast as on
9.1.x. Funny
Ping. A week ago a few people who looked at the older version of this
patch posted on IRC didn't point out obvious flaws. Can this get a
review please?
On Mon, Nov 4, 2013 at 1:34 AM, Alexander Monakov wrote:
> Hello,
>
> This patch implements accelerated path for glDrawPixels
, didn't measure exactly) since generic path goes via
_mesa_unpack_color_span_float, memcpy, extract_float_rgba.
I don't have commit access so please commit the patch for me if approved.
Thanks.
From 1c469f60799528027abbc08a6ddd02b6b19a5a36 Mon Sep 17 00:00:00 2001
From: Alexander Monakov
On Thu, Sep 5, 2013 at 6:40 PM, Alexander Monakov wrote:
> But it doesn't make sense to call glXUseXFont without a current context.
However ARB_create_context allows to make a context current without an
associated drawable.
___
mesa-dev mail
On Thu, Sep 5, 2013 at 6:25 PM, Maniak, Lukasz wrote:
> Original explanatory text:
>
> Fix for throwing BadDrawable (invalid Pixmap or Window parameter)
> by Xserver when calling XCreatePixmap or fill_bitmap from
> DRI_glXUseXFont.
>
> currentDrawable which came from __glXGetCurren
s://bugs.freedesktop.org/show_bug.cgi?id=62999
> Bugzilla: http://bugs.winehq.org/show_bug.cgi?id=26763
Done. I don't have git write access, can you push it for me?
From e19c1fcfdd72fc3f87908db77808f65be5000843 Mon Sep 17 00:00:00 2001
From: Alexander Monakov
Date: Tue, 2 Apr 2013 01:38
On Mon, Apr 1, 2013 at 11:05 PM, Alexander Monakov wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=47478
> https://bugs.freedesktop.org/show_bug.cgi?id=62999 (dup of the above)
>
> I don't have commit access so please push if OK.
Hm, now I see that MATCH_EXACT is used only
https://bugs.freedesktop.org/show_bug.cgi?id=47478
https://bugs.freedesktop.org/show_bug.cgi?id=62999 (dup of the above)
I don't have commit access so please push if OK.
From 3e23a23ec8a3bc36e13efc7cf95229e9e31955f1 Mon Sep 17 00:00:00 2001
From: Alexander Monakov
Date: Mon, 1 Apr 2013 23:
I feel rather awkward asking, but: why implement this inside of
Gallium, instead of as a standalone {egl,glX}SwapBuffers interceptor
obtaining counter values via GL extensions, such as
ARB_occlusion_query or AMD_performance_monitor? That way Intel (and
Nouveau?) people could also benefit from it.
On Tue, 5 Mar 2013, Jose Fonseca wrote:
> $LIB is a neat idea. But does it work on debian/ubuntu systems, where
> mesa/NVIDIA libGL.so are put in different paths , which are then chosen via
> /etc/ld.so.conf*?
I think Debian installs a symlink to the active libGL in /usr/lib. Not sure
about Ub
On Tue, 5 Mar 2013, Jose Fonseca wrote:
> I expected that when one sets TRACE_LIBGL env var with the path for the true
> libGL.so.1, then apitrace wouldn't be picking up symbols the overlay -- it
> would be taking symbols only from the true libGL.so, there avoiding infinite
> recursion.
... unle
On Mon, 4 Mar 2013, Carl Worth wrote:
> I don't think it should be too hard to get this to work, (though it
> may require a source change to the Steam overlay). I'll do some more
> experiments tomorrow and see if I can't make a concrete recommendation
> to be able to give to Valve as a bug repor
Greetings, Mesa hackers,
I've hacked together a small (~500 sloc) preloadable library that
implements OpenGL offloading by means of GLX forking, similar to
VirtualGL. The basic idea is to track contexts and drawables and
create shadow contexts and pbuffers on the secondary X server,
redirecting al
17 matches
Mail list logo
