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 w
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 dumping
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 likely be fairly
busy for at least the nex
bject, the resulting FBO is
incomplete because the sample counts don't match.
Signed-off-by: Henri Verbeet
---
src/mesa/main/teximage.c| 20 ++--
src/mesa/main/teximage.h| 8
src/mesa/main/textureview.c | 12
3 files changed, 26 insertions(+), 14 del
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
consid
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 BufferData/BufferSubData
On 24 October 2017 at 20:13, Fredrik Höglund wrote:
> On Tuesday 24 October 2017, Henri Verbeet wrote:
>> On 24 October 2017 at 16:11, Fredrik Höglund wrote:
>> >> @@ -934,9 +938,18 @@ x11_manage_fifo_queues(void *state)
>> >>
>> >>
On 24 October 2017 at 20:31, Emil Velikov wrote:
> On 17 October 2017 at 15:18, Henri Verbeet wrote:
>> Note that the usage of xcb_poll_for_special_event() requires a version
>> of libxcb that includes commit fad81b63422105f9345215ab2716c4b804ec7986
>> to work properly
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, chain->special_event);
>> -
-off-by: Henri Verbeet
---
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_x11.c b/src/vulkan/wsi/wsi_co
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
mesa-dev@lists.freedesktop.org
https://l
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
https://lists.freedesktop.org/mailman/listinfo/mesa
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Henri Verbeet
---
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 ecdaf91..22b067b 100644
--- a
On 11 June 2017 at 21:56, Marek Olšák wrote:
> On Sun, Jun 11, 2017 at 8:25 PM, Henri Verbeet wrote:
>> As someone downstream of this, I have to say I find the "family" names
>> much more informative than whatever marketing came up with. More
>> importantly h
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
>>> pipe_screen* pscreen)
>>>
>>> static const char* r600_get_chip_nam
On 26 June 2015 at 17:38, Brian Paul 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 value
>
On 27 May 2015 at 19:05, Kenneth Graunke 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 this kind of
On 25 April 2015 at 09:58, Axel Davy 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 | _FPU_MA
On 24 April 2015 at 22:09, Axel Davy 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" : : "
On 18 February 2015 at 00:46, Ilia Mirkin 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 case for hardware that
On 30 January 2015 at 21:34, Axel Davy 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) |
> ((D3DSPR_ADD
On 19 November 2014 01:55, Marek Olšák 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 fixes. I assume
On 19 November 2014 00:26, Emil Velikov 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
> design/coding, or would you be (
On 17 November 2014 21:05, Emil Velikov 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 actual evidence for the (
On 14 November 2014 20:41, Roland Scheidegger 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.)
> I suspect th
On 14 November 2014 18:50, Ilia Mirkin 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 take care of it, a
On 14 November 2014 17:52, Axel Davy 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 backbuffer asked by t
On 14 November 2014 17:42, Jose Fonseca 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 has always
On 14 November 2014 17:37, Ilia Mirkin 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 otherwise you'd
On 14 November 2014 16:36, Ilia Mirkin 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 (d3d9) devices, st
On 14 November 2014 16:21, Ilia Mirkin 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.
___
mesa-dev
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 driver
On 21 August 2014 04:56, Michel Dänzer 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
On 20 August 2014 20:13, Kenneth Graunke 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 in
> their distri
On 19 August 2014 02:50, Kenneth Graunke 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 BRW_CONDITIONAL_
On 24 July 2014 16:55, Marek Olšák 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 since Evergree
On 25 December 2013 14:17, Marek Olšák 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 writes to gl_FragD
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
---
src/mesa/state_tracker/st_mana
This fixes piglit arb_draw_buffers-rt0_none on AMD CEDAR. No piglit
regressions on the same hardware.
Signed-off-by: Henri Verbeet
---
src/mesa/state_tracker/st_cb_clear.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_clear.c
On 16 December 2013 01:37, Marek Olšák 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 convers
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
Cc: 10.0 9.2 9.1
---
src/mesa/drivers/dri/i915/i915_fragprog.c |1 +
1 file
On 30 September 2013 02:18, Dave Airlie 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 wondering is so
On 3 September 2013 13:19, Rico Schüller 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 occurrences (i
On 28 August 2013 12:17, Marek Olšák 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 shaders any
earli
I assume this should have been part of commit
7727fbb7c5d64348994bce6682e681d6181a91e9. This (obviously) fixes a lot tests.
Signed-off-by: Henri Verbeet
---
src/gallium/drivers/r600/r600_shader.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers
On 22 August 2013 00:31, Ian Romanick 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 arithmetic, for
>
On 18 August 2013 05:23, Ian Romanick 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. :)
>
The basic s
there probably 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
---
src/mesa/program/prog_statevars.c |3 +--
1 file change
On 9 August 2013 22:40, Marek Olšák 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
Tested-by: Henr
On 22 July 2013 18:48, Stefan Dösinger 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
>> the DDI would
On 3 June 2013 22:16, Kenneth Graunke 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
> synchronization, doesn't
On 19 April 2013 18:01, Vadim Girlin 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 implementation of all
On 19 April 2013 16:48, Vadim Girlin 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
> a better state an
On 12 March 2013 17:46, Ian Romanick 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() isn't
available
On 2 March 2013 00:14, Ian Romanick 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 implements
these,
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
http://lists.freedesktop.org/mailm
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
On 24 February 2013 17:07, Vadim Girlin 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
> exact shader that ca
For what it's worth, I get a number of failures in the Wine d3d9 tests
on Cayman with this branch (9219c54b5c5a65c269124637a6e654eda4cdbb8e).
I haven't looked at why yet.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.or
On 14 February 2013 12:28, Christian König 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 think some of the bui
On 14 February 2013 11:42, Christian König 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 LLVM has a
number o
On 14 December 2012 09:27, Michel Dänzer 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 /
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(-)
On 11 December 2012 13:57, Marek Olšák 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 mailing list
mesa-dev
On 8 December 2012 16:01, Alex Deucher 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.
___
mesa-dev mailing list
m
On 6 December 2012 21:34, Tom Stellard 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 the hardware
On 2 November 2012 22:22, Marek Olšák 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 nice if the Ope
On 30 September 2012 21:51, Marek Olšák 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 set. In the ge
On 1 August 2012 03:04, Eric Anholt 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 for mixin
On 30 March 2012 03:29, Ian Romanick 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 can also use ARB_sh
On 18 March 2012 17:47, Matt Turner 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
> - shared_dispatc
2012/3/6 Benoit Jacob :
> 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 on top of Gall
On 1 March 2012 16:50, Marek Olšák wrote:
> Hi Eric,
>
> this commit breaks StarCraft II running on Wine traced by apitrace
> on r600g. Wine is most probably stuck in a deadlock. It prints these
> error messages:
>
> err:seh:setup_exception_record stack overflow 2412 bytes in thread
> 0024 eip 004
On 1 February 2012 23:12, Brian Paul 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
the o
On 20 January 2012 03:24, Eric Anholt 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 (ARB_fbo)
This has no piglit regressions on r600g and softpipe.
Signed-off-by: Henri Verbeet
---
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/mesa
On 15 November 2011 14:52, Jose Fonseca 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 can
> yield sub
On 14 November 2011 17:29, Christoph Bumiller
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 (and a couple of special
On 14 November 2011 14:49, Vadim Girlin 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 and Mesa IR took
On 4 October 2011 00:41, Eric Anholt wrote:
> They're both implemented the same in GLSL IR (since round() has
> undefined behavior for n + 0.5). The specification of the C function
> in use here is a bit unclear: rint(3) says that nearbyint() is like
> rint() in that it uses the current rounding
On 23 September 2011 01:48, Eric Anholt 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, how about s
raw buffer for
output colors beyond 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
---
src/mesa/main/buffers.c | 27 ---
1 fi
On 22 September 2011 01:10, Eric Anholt 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 related bugs as
On 19 September 2011 19:23, Ian Romanick 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 mode if it is
On 17 September 2011 19:33, Brian Paul wrote:
> From: Brian Paul
>
> 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.
> If we can't turn of sRGB->linear
On 9 August 2011 23:45, Marek Olšák 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 extension isn't.
___
On 8 August 2011 03:58, Jose Fonseca 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. And if one takes
On 8 August 2011 02:24, Jose Fonseca 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 likely to be
On 7 August 2011 19:03, Lauri Kasanen 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
On 26 July 2011 02:21, Ian Romanick 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}.
>
>
On 26 July 2011 01:02, Eric Anholt 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 remaining
buff
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
---
src/mesa/main/buffers.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
On 23 July 2011 16:58, Brian Paul 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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 23 July 2011 10:58, Ian Romanick 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
On 19 July 2011 21:39, tom fogal 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 without a c
pical case GL_MAP_INVALIDATE_BUFFER_BIT will probably
imply that the buffer is in use.
Signed-off-by: Henri Verbeet
---
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
-by: Henri Verbeet
---
src/glx/dri_common.c |2 +-
src/glx/glxext.c | 11 +++
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index bac0c9e..e7dba5a 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -388,7
2011/7/12 Christian König :
> Am Dienstag, den 12.07.2011, 15:44 +0200 schrieb Henri Verbeet:
>> 2011/7/12 Christian König :
>> > + // TODO get BLEND_CLAMP state from rasterizer state
>> Is this comment still accurate?
> Yes it is, the very first generation of
2011/7/12 Christian König :
> 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 informed about a bo r
2011/7/11 Christian König :
> So what do you guys think about it?
>
I didn't look much at the rest of the changes, but some of the changes
for r600g (diff attached) look a bit questionable. Could you take a
look at those to see if they're really all intentional and correct
before merging?
r600g.d
1 - 100 of 189 matches
Mail list logo
