Re: [Mesa-dev] Please bring back __GL_FSAA_MODE

On Fri, 11 Jan 2019 at 13:05, Tom Butler wrote: > In particular I'm looking to get FSAA working in older games via wine, mostly > they don't support antialiasing which is a shame because there's plenty of > GPU power going to waste which could be fixing the jaggles. On nvidia > __GL_FSAA_MODE

Re: [Mesa-dev] last call for autotools

On Fri, 14 Dec 2018 at 15:42, Gert Wollny wrote: > Am Freitag, den 14.12.2018, 01:19 -0500 schrieb Ilia Mirkin: > > meson is not at a point where it Just Works. It ... sometimes works. > > The fact that everyone has scripts which wrap meson is a symptom of > > that. I don't feel good about

Re: [Mesa-dev] [PATCH] mesa: Inherit texture view multi-sample information from the original texture images.

On 27 March 2018 at 18:57, Brian Paul wrote: > LGTM. I guess we probably don't have much piglit coverage for texture_view > + MSAA. > > Reviewed-by: Brian Paul > I've pushed this, thanks for the review. A piglit test should be straightforward, but I'll

[Mesa-dev] [PATCH] mesa: Inherit texture view multi-sample information from the original texture images.

fer object, the resulting FBO is incomplete because the sample counts don't match. Signed-off-by: Henri Verbeet <hverb...@gmail.com> --- src/mesa/main/teximage.c| 20 ++-- src/mesa/main/teximage.h| 8 src/mesa/main/textureview.c | 12 3 files changed, 26 i

[Mesa-dev] WineConf 2018

I hope this won't be considered spam, in which case I'd like to apologise in advance. The annual Wine conference will this year take place from Friday June 29 until Sunday July 1, in The Hague, The Netherlands. In the interest of outreach to other projects, and since I believe Wine would be

Re: [Mesa-dev] [PATCH] radeonsi: always initialize max_forced_staging_uploads

On 28 November 2017 at 20:20, Marek Olšák wrote: > Most of the corruption goes away if I flush IBs after every command. > This suggests that the staging upload is done in one context while > drawing is done in another context. The solution is to flush all > contexts before

Re: [Mesa-dev] [PATCH] vulkan/wsi: Avoid waiting indefinitely for present completion in x11_manage_fifo_queues().

On 24 October 2017 at 20:13, Fredrik Höglund <fred...@kde.org> wrote: > On Tuesday 24 October 2017, Henri Verbeet wrote: >> On 24 October 2017 at 16:11, Fredrik Höglund <fred...@kde.org> wrote: >> >> @@ -934,9 +938,18 @@ x11_manage_fifo_queues(void *state

Re: [Mesa-dev] [PATCH] vulkan/wsi: Avoid waiting indefinitely for present completion in x11_manage_fifo_queues().

On 24 October 2017 at 20:31, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 17 October 2017 at 15:18, Henri Verbeet <hverb...@gmail.com> wrote: >> Note that the usage of xcb_poll_for_special_event() requires a version >> of libxcb that includes commit fad81b6342210

Re: [Mesa-dev] [PATCH] vulkan/wsi: Avoid waiting indefinitely for present completion in x11_manage_fifo_queues().

On 24 October 2017 at 16:11, Fredrik Höglund wrote: >> @@ -934,9 +938,18 @@ x11_manage_fifo_queues(void *state) >> >>while (chain->last_present_msc < target_msc) { >> xcb_generic_event_t *event = >> -xcb_wait_for_special_event(chain->conn,

[Mesa-dev] [PATCH] vulkan/wsi: Avoid waiting indefinitely for present completion in x11_manage_fifo_queues().

-off-by: Henri Verbeet <hverb...@gmail.com> --- This applies on top of "vulkan/wsi: Free the event in x11_manage_fifo_queues()." --- src/vulkan/wsi/wsi_common_x11.c | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/src/vulkan/wsi/wsi_common_x1

Re: [Mesa-dev] [PATCH] blob: Use intptr_t instead of ssize_t

On 13 October 2017 at 19:44, Jason Ekstrand wrote: > ssize_t is a GNU extension and is not available on Windows or MacOS. Not to argue against the patch in any way, but ssize_t is POSIX. ___ mesa-dev mailing list

Re: [Mesa-dev] [Mesa-stable] [PATCH] vulkan/wsi: Free the event in x11_manage_fifo_queues().

On 13 October 2017 at 19:23, Emil Velikov wrote: > Please give it time for Vulkan devs to take a look. > Sure, I'm in no particular hurry. Henri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org

[Mesa-dev] [PATCH] vulkan/wsi: Free the event in x11_manage_fifo_queues().

Cc: mesa-sta...@lists.freedesktop.org Signed-off-by: Henri Verbeet <hverb...@gmail.com> --- I should still have commit access. --- src/vulkan/wsi/wsi_common_x11.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c index e

Re: [Mesa-dev] [PATCH v2 1/1] radeonsi: Use libdrm to get chipset name

On 11 June 2017 at 21:56, Marek Olšák <mar...@gmail.com> wrote: > On Sun, Jun 11, 2017 at 8:25 PM, Henri Verbeet <hverb...@gmail.com> wrote: >> As someone downstream of this, I have to say I find the "family" names >> much more informative than whatever market

Re: [Mesa-dev] [PATCH v2 1/1] radeonsi: Use libdrm to get chipset name

On 7 June 2017 at 21:54, Marek Olšák wrote: > On Wed, Jun 7, 2017 at 2:07 AM, Marek Olšák wrote: >> On Wed, Jun 7, 2017 at 12:21 AM, Samuel Li wrote: >>> @@ -790,6 +790,15 @@ static const char* r600_get_device_vendor(struct >>>

Re: [Mesa-dev] [PATCH] Allow setting GL_TEXTURE_COMPARE_MODE on a sampler object without ARB_shadow support.

On 26 June 2015 at 17:38, Brian Paul bri...@vmware.com wrote: Digging up the patch from March for reference: This fixes a GL error warning on r200 in Wine. The GL_ARB_sampler_objects extension does not specify a dependency on GL_ARB_shadow or GL_ARB_depth_texture for this value. Just set the

Re: [Mesa-dev] [v4 PATCH 05/10] mesa: helper function for scissor box of gl_framebuffer

On 27 May 2015 at 19:05, Kenneth Graunke kenn...@whitecape.org wrote: If you're using vim, this will give you the correct settings for Mesa: if has(autocmd) au BufNewFile,BufRead */mesa/* set expandtab tabstop=8 softtabstop=3 shiftwidth=3 endif setlocal is more appropriate than set for

Re: [Mesa-dev] [PATCH 08/16] st/nine: Change x86 FPU Control word on device creation as on wined3d and windows

On 25 April 2015 at 09:58, Axel Davy axel.d...@ens.fr wrote: static void nine_setup() { fpu_control_t c; _FPU_GETCW(c); /* clear the control word */ c = _FPU_RESERVED; /* enable interrupts (d3d9 doc, wine tests) */ c |= _FPU_MASK_IM | _FPU_MASK_DM | _FPU_MASK_ZM |

Re: [Mesa-dev] [PATCH 08/16] st/nine: Change x86 FPU Control word on device creation as on wined3d and windows

On 24 April 2015 at 22:09, Axel Davy axel.d...@ens.fr wrote: +static void nine_setup_fpu(void) +{ +#if defined(__GNUC__) (defined(__i386__) || defined(__x86_64__)) +WORD cw; +__asm__ volatile (fnstcw %0 : =m (cw)); +cw = (cw ~0xf3f) | 0x3f; +__asm__ volatile (fldcw %0 : :

Re: [Mesa-dev] [Piglit] DSA for core profile only? (was Re: [PATCH 2/2] arb_direct_state_access: New test for GetCompressedTextureImage.)

On 18 February 2015 at 00:46, Ilia Mirkin imir...@alum.mit.edu wrote: Wine maybe? (They're compat-only for now, although some work is being done to support core, but that might only be for their D3D10+ layer.) The current plan for Wine is just to add support for core profiles. There may be a

Re: [Mesa-dev] [PATCH 07/43] st/nine: Fix use of D3DSP_NOSWIZZLE

On 30 January 2015 at 21:34, Axel Davy axel.d...@ens.fr wrote: @@ -2778,7 +2778,7 @@ sm1_parse_get_param(struct shader_translator *tx, DWORD *reg, DWORD *rel) *rel = (1 31) | ((D3DSPR_ADDR D3DSP_REGTYPE_SHIFT2) D3DSP_REGTYPE_MASK2) |

Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine

On 19 November 2014 00:26, Emil Velikov emil.l.veli...@gmail.com wrote: From a quick look at MSDN it seems to me that going the DDI (like) route would require substantial rework on the wine side. How much contribution from wine can we expect ? Would you have the chance to help with

Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine

On 19 November 2014 01:55, Marek Olšák mar...@gmail.com wrote: Before we start discussing what we can do about the OpenGL API overhead, we must get rid of the on-demand shader compilation. It's unacceptable to compile shaders when we should be rendering. This is one of the things that Nine

Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine

On 17 November 2014 21:05, Emil Velikov emil.l.veli...@gmail.com wrote: - GL extensions I feel that it's a bit too much to shoot the project down, because it does not introduce GL extensions that will be useful. To clarify, that's not what I said. It's mostly just that I'd like to see some

Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine

On 14 November 2014 16:21, Ilia Mirkin imir...@alum.mit.edu wrote: To the best of my knowledge, wine has no intent on merging anything related to nine/st. That's a bit broader than I'd put it, but yes, in it's current form this is not something we'd merge.

Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine

On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. I.e., anything dealing with

Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine

On 14 November 2014 17:37, Ilia Mirkin imir...@alum.mit.edu wrote: Dave Airlie's virgl work is creating a gallium driver which actually uses OpenGL for hardware. I'm not sure how far he is, but I believe he has enough for GL3. This could be a way forward towards *only* using gallium (since

Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine

On 14 November 2014 17:42, Jose Fonseca jfons...@vmware.com wrote: [...] We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach

Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine

On 14 November 2014 17:52, Axel Davy axel.d...@ens.fr wrote: Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL. As for me, I contributed only since a few months ago, and was able to implement a lot of things quite easily, for exemple: . Respect the number of

Re: [Mesa-dev] Suboptimal code generation

On 14 November 2014 18:50, Ilia Mirkin imir...@alum.mit.edu wrote: I can't speak for the radeon guys, but I know I sure would love to see any reports of poor code being generated by nouveau in response to legitimate-seeming TGSI (or GLSL). In some cases, a simple optimization can be added to

Re: [Mesa-dev] Suboptimal code generation

On 14 November 2014 20:41, Roland Scheidegger srol...@vmware.com wrote: That looks quite ok to me. Slightly suboptimal maybe but quite reasonable - you can't really expect optimal code always. (With the proposal to nuke cnd from tgsi though you'd just generate the same in any case probably.)

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

I'd like to say up front that while I could imagine that perhaps some of my comments on radeonsi could be perceived as harsh, it's not my intention to pick on radeonsi or anyone working on radeonsi in particular. I just think radeonsi / r600g is probably the best comparison inside Mesa for a

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

On 21 August 2014 04:56, Michel Dänzer mic...@daenzer.net wrote: On 21.08.2014 04:29, Henri Verbeet wrote: For whatever it's worth, I have been avoiding radeonsi in part because of the LLVM dependency. Some of the other issues already mentioned aside, I also think it makes it just painful

Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

On 20 August 2014 20:13, Kenneth Graunke kenn...@whitecape.org wrote: I've also heard stories from friends of mine who use radeonsi that they couldn't get new GL features or compiler fixes unless they upgrade both Mesa /and/ LLVM, and that LLVM was usually either not released or not available

Re: [Mesa-dev] [PATCH 1/2] i965/fs: Optimize conditional discards.

On 19 August 2014 02:50, Kenneth Graunke kenn...@whitecape.org wrote: +/* Returns a conditional modifier that negates the condition. */ +enum brw_conditional_mod +brw_negate_cmod(uint32_t cmod) +{ + switch (cmod) { + case BRW_CONDITIONAL_Z: + return BRW_CONDITIONAL_NZ; + case

Re: [Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE

On 24 July 2014 16:55, Marek Olšák mar...@gmail.com wrote: the hardware supports 16 constant buffers. I'm not sure what the constant registers are, but they cannot have anything to do with the Probably the old CFILE constants, of which there actually only were 256, and which IIRC were removed

[Mesa-dev] [PATCH 1/2] st/mesa: Handle disabled draw buffers in st_Clear().

This fixes piglit arb_draw_buffers-rt0_none on AMD CEDAR. No piglit regressions on the same hardware. Signed-off-by: Henri Verbeet hverb...@gmail.com --- src/mesa/state_tracker/st_cb_clear.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/src/mesa

[Mesa-dev] [PATCH 2/2] st/mesa: Only use idx after validating it in st_manager_add_color_renderbuffer().

In particular, we don't want it to be -1. In practice this is probably unlikely to be an issue, since Attachment[-1] should still be a valid memory location, and the code only reads it. No piglit regressions on AMD CEDAR. Signed-off-by: Henri Verbeet hverb...@gmail.com --- src/mesa/state_tracker

Re: [Mesa-dev] [PATCH 1/2] st/mesa: Handle disabled draw buffers in st_Clear().

On 25 December 2013 14:17, Marek Olšák mar...@gmail.com wrote: This looks good, but it's only papering over the real problem, which is that st/mesa doesn't bind NULL colorbuffers and skips them instead. For example, if DRAWBUFFER0 is NONE, st/mesa binds DRAWBUFFER1 to cb[0], but then all

Re: [Mesa-dev] glBlitFramebuffer and sRGB vs piglit

On 16 December 2013 01:37, Marek Olšák mar...@gmail.com wrote: Hi everybody, There is an inconsistence in the piglit glBlitFramebuffer tests. If both src and dst are sRGB, piglit expects this from glBlitFramebuffer: if (dst.num_samples == 1 src.num_samples 1) { enable the sRGB-linear

[Mesa-dev] [PATCH 1/1] i915: Add support for gl_FragData[0] reads.

Similar to 556a47a2621073185be83a0a721a8ba93392bedb, without this reading from gl_FragData[0] would cause a software fallback. Bugzilla: https://bugs.winehq.org/show_bug.cgi?id=33964 Signed-off-by: Henri Verbeet hverb...@gmail.com Cc: 10.0 9.2 9.1 mesa-sta...@lists.freedesktop.org --- src/mesa

Re: [Mesa-dev] context sharing of framebuffer objects

On 30 September 2013 02:18, Dave Airlie airl...@gmail.com wrote: So this led me to look at the spec and the mesa code, and I noticed it appears at some point maybe around 3.1 that FBOs are no longer considered shared objects at least in core profile, but mesa always seems to share them, just

Re: [Mesa-dev] [PATCH] glx: Initialize OpenGL version to 1.0

On 3 September 2013 13:19, Rico Schüller kgbric...@web.de wrote: So yes, we agree here, the version number needs to be fixed. The simplest one is to just change the number. I'm fine with it. I have no strong opinion about it. Though I think it should be consistent across all initialization

Re: [Mesa-dev] [PATCH] r600g: fix color exports when we have no CBs

On 28 August 2013 12:17, Marek Olšák mar...@gmail.com wrote: Yeah, st/mesa also compiles shaders on the first use, so we've got 3 places to fix: Wine, st/mesa, the driver. For what it's worth, while Wine definitely has some room for improvement in this regard, in some cases we don't get the

[Mesa-dev] [PATCH 1/1] r600g: Implement the new float comparison instructions for Cayman as well.

I assume this should have been part of commit 7727fbb7c5d64348994bce6682e681d6181a91e9. This (obviously) fixes a lot tests. Signed-off-by: Henri Verbeet hverb...@gmail.com --- src/gallium/drivers/r600/r600_shader.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [Mesa-dev] [PATCH 1/1] mesa: Properly set the fog scale (gl_Fog.scale) to +INF when fog start and end are equal.

On 22 August 2013 00:31, Ian Romanick i...@freedesktop.org wrote: Section 2.1.1 (Floating-point computation) says: The result of providing a value that is not a floating-point number to such a command is unspecified, but must not lead to GL interruption or termination. In IEEE

Re: [Mesa-dev] [PATCH] glsl: don't eliminate texcoords that can be set by GL_COORD_REPLACE

On 18 August 2013 05:23, Ian Romanick i...@freedesktop.org wrote: Since this also fixes an application, do you have any idea what could be done to make a piglit test to reproduce the failure? We have some folks writing piglit tests for us this summer, and this sounds like a good one for them.

Re: [Mesa-dev] [PATCH] glsl: don't eliminate texcoords that can be set by GL_COORD_REPLACE

On 9 August 2013 22:40, Marek Olšák mar...@gmail.com wrote: Tested by examining generated TGSI shaders from piglit/glsl-routing. This fixes the relevant Wine d3d9 test, thanks. No piglit changes on Cayman. Reviewed-by: Henri Verbeet hverb...@gmail.com Tested-by: Henri Verbeet hverb

[Mesa-dev] [PATCH 1/1] mesa: Properly set the fog scale (gl_Fog.scale) to +INF when fog start and end are equal.

isn't very stable to begin with when fog start and end are close together, it seems best to just leave it alone. This fixes a couple of Wine D3D tests. No piglit changes on Cayman. Signed-off-by: Henri Verbeet hverb...@gmail.com --- src/mesa/program/prog_statevars.c |3 +-- 1 file changed, 1

Re: [Mesa-dev] Direct3D 9 state tracker

On 22 July 2013 18:48, Stefan Dösinger stefandoesin...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-07-22 15:39, schrieb Jose Fonseca: It seems to me that this would be more useful if the state tracker targeted not the D3D9 API, but the WDDM D3D9 DDI [2]. Targeting

Re: [Mesa-dev] Do we support front buffer rendering with EGL? Do we want to?

On 3 June 2013 22:16, Kenneth Graunke kenn...@whitecape.org wrote: I don't think we should implement front buffer rendering for EGL unless someone presents a compelling use case. In my mind, front buffer rendering is only something used historically...it has all kinds of caveats about

Re: [Mesa-dev] r600g: status of the r600-sb branch

On 19 April 2013 18:01, Vadim Girlin vadimgir...@gmail.com wrote: The choice of C++ (unlike in my previous branch that used C) was mostly driven by the fact that optimization algorithms usually deal with a lot of different complex data structures, containers, etc, and C++ allows to isolate

Re: [Mesa-dev] r600g: status of the r600-sb branch

On 19 April 2013 16:48, Vadim Girlin vadimgir...@gmail.com wrote: In the previous status update I said that the r600-sb branch is not ready to be merged yet, but recently I've done some cleanups and reworks, and though I haven't finished everything that I planned initially, I think now it's in

Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer

On 12 March 2013 17:46, Ian Romanick i...@freedesktop.org wrote: Right... the extension also adds an attribute that can only be used with glXCreateContextAttribsARB. Yeah, all I was saying is that it probably wouldn't be too hard to word things along the lines of If glXCreateContextAttribsARB()

Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer

On 2 March 2013 00:14, Ian Romanick i...@freedesktop.org wrote: I added some comments, but I think the extension is pretty much fine for at least Wine's purposes. GLX_ARB_create_context and GLX_ARB_create_context_profile are required. It's probably not a big deal since just about everyone

Re: [Mesa-dev] r600g: status of my work on the shader optimization

All the Wine D3D tests now (3931289ab5fc7c7e2ab46e6316e55adc19ec3cfc) pass for me on Cayman. I may be able to do some more testing later, and do e.g. a piglit run. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] r600g: status of my work on the shader optimization

Great, I'll do some testing again when I get the chance. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] r600g: status of my work on the shader optimization

On 24 February 2013 17:07, Vadim Girlin vadimgir...@gmail.com wrote: If you'd like to help me with debugging the issues on cayman, then please read the regression debugging section in the r600-sb branch notes [1] (or possibly more up-to-date source here - [2]), it explains how to find the

Re: [Mesa-dev] r600g: status of my work on the shader optimization

On 14 February 2013 11:42, Christian König deathsim...@vodafone.de wrote: nice work, I think you've made quite a progress here, but on the other hand it should be clear that the LLVM backend is the future and we should concentrate on that. I'm not sure that's really true. My impression is that

Re: [Mesa-dev] r600g: status of my work on the shader optimization

On 14 February 2013 12:28, Christian König deathsim...@vodafone.de wrote: Well apart from a bit strange coding style and the use of SVN, I can't really see any problems that are related to using LLVM as it is. Well, for one, I don't think LLVM believes in stable APIs or shared libraries, and I

Re: [Mesa-dev] [PATCH] gallium/u_blitter: Remove the overlapped blit assert from util_blitter_blit_generic().

On 14 December 2012 09:27, Michel Dänzer mic...@daenzer.net wrote: On Fre, 2012-12-14 at 06:04 +0100, Henri Verbeet wrote: This is used by st_BlitFramebuffer() / r600_blit(), and ARB_fbo allows overlapped blits, even though the result is undefined. No piglit regressions on r600g / CYPRESS

[Mesa-dev] [PATCH] gallium/u_blitter: Remove the overlapped blit assert from util_blitter_blit_generic().

This is used by st_BlitFramebuffer() / r600_blit(), and ARB_fbo allows overlapped blits, even though the result is undefined. No piglit regressions on r600g / CYPRESS. --- src/gallium/auxiliary/util/u_blitter.c | 28 1 files changed, 0 insertions(+), 28 deletions(-)

Re: [Mesa-dev] [PATCH] st/mesa: remove the prefix 'Gallium 0.4 on' from the renderer string

On 11 December 2012 13:57, Marek Olšák mar...@gmail.com wrote: We already have the Mesa version in the version string, isn't that enough to detect Mesa? In theory, although the vendor string would IMO be the expected place for that. ___ mesa-dev

Re: [Mesa-dev] Mesa (master): r600g: Use default mul/mad function for tgsi-to-llvm

On 6 December 2012 21:34, Tom Stellard t...@stellard.net wrote: I asked idr about this on IRC and he said that IEEE rules are required for GLSL = 1.30 and they are compliant, but not required for GLSL 1.30. stringfellow added that the d3d9 spec required 0*anything = 0, which is probably why

Re: [Mesa-dev] Mesa (master): r600g: Use default mul/mad function for tgsi-to-llvm

On 8 December 2012 16:01, Alex Deucher alexdeuc...@gmail.com wrote: What about a mesa specific extension? Most people will be using wine on Linux anyway. Sure, that works for us. Assuming Mesa is interested in a such an extension, of course. ___

Re: [Mesa-dev] [PATCH 2/2] mesa: use the EXT_texture_compression_s3tc enable flag for all S3TC extensions

On 2 November 2012 22:22, Marek Olšák mar...@gmail.com wrote: Yeah. However as far as I know, the desktop GL doesn't have a (good) S3TC extension which doesn't require on-line compression. With what you say, it looks like such an extension would be useful for us. Don't you think it would be

Re: [Mesa-dev] [PATCH] glx/dri2: use uint64_t instead of double to represent time for FPS calculation

On 30 September 2012 21:51, Marek Olšák mar...@gmail.com wrote: Wine or a windows app changes fpucw to 0x7f, causing doubles to be equivalent to floats, which broke the calculation of FPS. For reference, this is done by for example d3d9 when a D3D device is created without D3DCREATE_FPU_PRESERVE

Re: [Mesa-dev] [PATCH 1/3] meta: Implement sensible behavior for BlitFramebuffer with sRGB.

On 1 August 2012 03:04, Eric Anholt e...@anholt.net wrote: Prior to GL 4.2 spec, there was no guidance on how to implement BlitFramebuffer for sRGB. Mesa chose to implement skipping decode and encode, providing a reasonable behavior for sRGB - sRGB or RGB - RGB, but providing something absurd

Re: [Mesa-dev] TBOs: Mesa and i965 sampling support.

On 30 March 2012 03:29, Ian Romanick i...@freedesktop.org wrote: I'm not super excited about GL_EXT_gpu_shader4.  Do we know of any applications that use that EXT and don't use either GLSL 1.30 or GLSL 1.40? Wine will use it for the texture sampling functions with explicit derivatives, but it

Re: [Mesa-dev] unpack functions showing up highly in profiles

On 18 March 2012 17:47, Matt Turner matts...@gmail.com wrote: SC2's call chain for unpack_uint_z_X8_Z24 is unpack_uint_z_X8_Z24  - _mesa_unpack_uint_z_row  - _mesa_readpixels   - intelReadPixels    - copy_tex_sub_image.isra.3     - intelCopyTexSubImage2D      - copyteximage       -

Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?

2012/3/6 Benoit Jacob bja...@mozilla.com: The goal is to help port real-world applications such as games. Besides OpenGL [ES], the other API that is widely used in the real world is Direct3D (9 and 10), so that's what would be the most interesting. I've heard about a Direct3D implementation

Re: [Mesa-dev] [PATCH] mesa: Add unpack_uint_z_row support for floating-point depth buffers

On 1 February 2012 23:12, Brian Paul bri...@vmware.com wrote: +static void +unpack_uint_z_Z32_FLOAT(const void *src, GLuint *dst, GLuint n) +{ +   const float *s = ((const float *)src); More parens than necessary there. The entire cast is unnecessary, IMO. But of course that would apply to

Re: [Mesa-dev] [PATCH] mesa: Loosen glBlitFramebuffer restrictions on depthstencil buffers (v2)

On 20 January 2012 03:24, Eric Anholt e...@anholt.net wrote: So is it also allowed to blit from S8Z24 to Z24S8 ? Could we also allow to blit from RGBA8 to BGRA8 then, please ? That's already allowed. Yeah, but not for multisampled framebuffers, unless RGBA8 and BGRA8 are considered identical

[Mesa-dev] [PATCH 1/1] st/mesa: Use util_blit_pixels_writemask() for depth blits as well in st_copy_texsubimage().

This has no piglit regressions on r600g and softpipe. Signed-off-by: Henri Verbeet hverb...@gmail.com --- src/mesa/state_tracker/st_cb_texture.c | 174 +--- 1 files changed, 91 insertions(+), 83 deletions(-) diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src

Re: [Mesa-dev] Allowing the reading of outputs for some drivers

On 15 November 2011 14:52, Jose Fonseca jfons...@vmware.com wrote: Developer time is important too. And having more code paths shared with other drivers (even at the expense of a few extra CPU cycles every time a shader is created) means that developers has more time to focus on features that

Re: [Mesa-dev] Allowing the reading of outputs for some drivers

On 14 November 2011 14:49, Vadim Girlin vadimgir...@gmail.com wrote: By the way, which drivers do not support reading outputs? I haven't done a full piglit run with llvmpipe, but IIRR the single test mentioned above was also fixed for llvmpipe without this output replacement. IIRC both GLSL IR

Re: [Mesa-dev] Allowing the reading of outputs for some drivers

On 14 November 2011 17:29, Christoph Bumiller e0425...@student.tuwien.ac.at wrote: And r600, I think, just stores them all in TEMP space and exports them in the end, so it's rather a property of the shader backend that the device (I may be wrong though). Instructions generally all work on GPRs

[Mesa-dev] [PATCH] mesa: Also set the remaining draw buffers to GL_NONE when updating just the first buffer in _mesa_drawbuffers().

for output colors beyond n is set to NONE., and this is queryable state. This fixes piglit arb_draw_buffers-state_change. NOTE: This is a candidate for the 7.10 and 7.11 branches. Signed-off-by: Henri Verbeet hverb...@gmail.com --- src/mesa/main/buffers.c | 27 --- 1 files

Re: [Mesa-dev] [PATCH] mesa: Also set the remaining draw buffers to GL_NONE when updating just the first buffer in _mesa_drawbuffers().

On 23 September 2011 01:48, Eric Anholt e...@anholt.net wrote: In the case of n == 1 with more than one bit set, doesn't this stomp the _ColorDrawBufferIndexes[] we just calculated between n and _NumColorDrawBuffers - 1?  Looks like splitting that loop into two would work well. You're right,

Re: [Mesa-dev] RFC: Remove GL_APPLE_client_storage

On 22 September 2011 01:10, Eric Anholt e...@anholt.net wrote: wined3d is the only potential consumer I've ecountered.  I don't think I Yeah, although I'm not entirely convinced of the usefulness of wined3d using the extension either. Apple seems to have their fair share of APPLE_client_storage

Re: [Mesa-dev] Implement NV_fog_distance for Gallium hardware

On 19 September 2011 19:23, Ian Romanick i...@freedesktop.org wrote: Direct3D 9 calls the eye radial fog distance mode range-based fog and Wine's D3D9 implementation will use NV_fog_distance to implement it. Several other open source game engines in Google Code Search use the eye radial fog

Re: [Mesa-dev] [PATCH] meta: fix broken sRGB mipmap generation

On 17 September 2011 19:33, Brian Paul brian.e.p...@gmail.com wrote: From: Brian Paul bri...@vmware.com If we're generating a mipmap for an sRGB texture we need to bypass sRGB-linear conversion.  Otherwise the destination mipmap level (drawn with a textured quad) will have the wrong colors.

Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue

On 9 August 2011 23:45, Marek Olšák mar...@gmail.com wrote: texture, so we'd be noncompliant. Noncompliant is probably better than not working at all. So what do you guys think? In the general case, no. A missing extension is something applications can deal with if they care to, a broken

Re: [Mesa-dev] [PATCH] r600g: Add support for ROUND

On 7 August 2011 19:03, Lauri Kasanen c...@gmx.com wrote: +       /* floor(a + 0.5) */ Why not use RNDNE? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600g: Add support for ROUND

On 8 August 2011 02:24, Jose Fonseca jfons...@vmware.com wrote: There's no wrong or right when there are two equidistant integers -- it's all a matter of convention. But note that rounding to nearest even is a slightly better convention in terms of rounding bias. I.e., not using RNDNE is both

Re: [Mesa-dev] [PATCH] r600g: Add support for ROUND

On 8 August 2011 03:58, Jose Fonseca jfons...@vmware.com wrote: It's subjective. It depends on the expected input distribution, which is effectively impossible to characterize in general. One can easily find datasets where one method gives biased results and the other not, and vice versa.

Re: [Mesa-dev] [PATCH 1/1] mesa: Call updated_drawbuffers() if the buffer count changes in _mesa_drawbuffers().

On 26 July 2011 02:21, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2011 01:23 PM, Henri Verbeet wrote: Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1}, {COLOR0}, {COLOR0, COLOR1}. Is there a piglit test

[Mesa-dev] [PATCH 1/1] mesa: Call updated_drawbuffers() if the buffer count changes in _mesa_drawbuffers().

Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1}, {COLOR0}, {COLOR0, COLOR1}. NOTE: This is a candidate for the 7.10 and 7.11 branches. Signed-off-by: Henri Verbeet hverb...@gmail.com --- src/mesa/main/buffers.c |5 - 1 files changed, 4 insertions(+), 1

Re: [Mesa-dev] [PATCH 1/1] mesa: Call updated_drawbuffers() if the buffer count changes in _mesa_drawbuffers().

On 26 July 2011 01:02, Eric Anholt e...@anholt.net wrote: I don't see that, because the while (buf MaxDrawBuffers) loop would notice the change from COLOR1 - NONE. That loop doesn't happen because n == 1 for {COLOR0} (as opposed to {COLOR0, NONE}). Perhaps we should always explicitly set any

Re: [Mesa-dev] [PATCH 3/3] mesa: Make _mesa_get_compressed_formats match the texture compression specs

On 23 July 2011 10:58, Ian Romanick i...@freedesktop.org wrote: + * explose the 3dc formats through this mechanism. Typo. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] mesa: Make _mesa_get_compressed_formats match the texture compression specs

On 23 July 2011 16:58, Brian Paul brian.e.p...@gmail.com wrote: Also, look for comptaibility Looks like that is actually in the extension spec like that. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] rationale for GLubyte pointers for strings?

On 19 July 2011 21:39, tom fogal tfo...@sci.utah.edu wrote: I think you have misinterpreted my question. Why not just have glGetString's prototype be:  const char* glGetString(GLenum); ? Then (sans the missing const :), your code below would work on *all* platforms, MIPSpro or not, with or

[Mesa-dev] [PATCH 2/2] st/mesa: Handle GL_MAP_INVALIDATE_BUFFER_BIT in st_bufferobj_map_range().

GL_MAP_INVALIDATE_BUFFER_BIT will probably imply that the buffer is in use. Signed-off-by: Henri Verbeet hverb...@gmail.com --- src/mesa/state_tracker/st_cb_bufferobjects.c | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c b

Re: [Mesa-dev] About merging pipe-video to master

2011/7/12 Christian König deathsim...@vodafone.de: it works with my available hardware (no piglit regressions). The changes to the winsys code is about making a bo optional, even when the reg informations says it isn't. This is useful for registers where only a subset of the bits needs to be

Re: [Mesa-dev] About merging pipe-video to master

2011/7/12 Christian König deathsim...@vodafone.de: Am Dienstag, den 12.07.2011, 15:44 +0200 schrieb Henri Verbeet: 2011/7/12 Christian König deathsim...@vodafone.de: +           // TODO get BLEND_CLAMP state from rasterizer state Is this comment still accurate? Yes it is, the very first

Re: [Mesa-dev] [PATCH 1/2] r600g: introduce r600_bc_src_set_abs helper and fix LOG

On 7 July 2011 06:20, Vadim Girlin vadimgir...@gmail.com wrote: -static void r600_bc_src(struct r600_bc_alu_src *bc_src, +static inline void r600_bc_src(struct r600_bc_alu_src *bc_src, This looks like an unrelated change. Personally I think inline is best left up to the compiler to decide in the

Re: [Mesa-dev] [PATCH 2/2] r600g: introduce r600_bc_src_toggle_neg helper and fix SUB LRP

On 7 July 2011 06:20, Vadim Girlin vadimgir...@gmail.com wrote: +static inline void r600_bc_src_toggle_neg(struct r600_bc_alu_src *bc_src) +{ +       bc_src-neg = 1 - bc_src-neg; +} + Not necessarily wrong, but I think bc_src-neg = !bc_src-neg; would be the more common way to write this.

Re: [Mesa-dev] [PATCH 4/5] mesa: Fix a couple of TexEnv unit limits.

On 6 July 2011 22:03, Ian Romanick i...@freedesktop.org wrote: @@ -419,7 +419,7 @@ _mesa_TexEnvfv( GLenum target, GLenum pname, const GLfloat *param )     ASSERT_OUTSIDE_BEGIN_END(ctx);     maxUnit = (target == GL_POINT_SPRITE_NV pname == GL_COORD_REPLACE_NV) -      ?

[Mesa-dev] [PATCH 1/5] mesa: Check the texture against all units in unbind_texobj_from_texunits().

--- src/mesa/main/texobj.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c index 565a3a2..0e84b87 100644 --- a/src/mesa/main/texobj.c +++ b/src/mesa/main/texobj.c @@ -899,7 +899,7 @@ unbind_texobj_from_texunits(struct

[Mesa-dev] [PATCH 2/5] mesa: Allow sampling from units = MAX_TEXTURE_UNITS in shaders.

The total number of units used by a shader is limited to MAX_TEXTURE_UNITS, but the actual indices are only limited by MAX_COMBINED_TEXTURE_IMAGE_UNITS, since they're shared between vertex and fragment shaders. --- src/mesa/main/mtypes.h|2 +- src/mesa/main/shaderapi.c |2 +-

  1   2   >