On 11/25/2011 01:13 AM, Dave Airlie wrote:
I'm honestly shocked to read this, Marek. We deliberately want [your]
driver to be less capable and couldn't care about less about anything
except [our] driver? This is sounding remarkably like a conspiracy
theory, and I really didn't expect that from
On Mon, Nov 28, 2011 at 12:08 AM, Ian Romanick i...@freedesktop.org wrote:
In Mesa, we have four drivers that advertise 4096 uniform components on some
combinations of hardware: i915, i915g, nouveau, and r300g. By putting
resource counting in the driver we have the potential for shaders to
On Fri, Nov 25, 2011 at 1:46 AM, Kenneth Graunke kenn...@whitecape.org wrote:
another, no driver should be crippled ever. I know you couldn't care
less about anything except your driver, but there are people who care.
Marek
I'm honestly shocked to read this, Marek. We deliberately want
- Original Message -
People are being more honest on
IRC than here.
I read some of the IRC logs from the past days, and there were several
saddening statements made in there by several people.
But I wonder if IRC does really bring the most honest side out of people, or
simply their
- Original Message -
While Ian and I may take a more idealist stance (favoring strict
compliance), and you perhaps a more pragmatic view (get more apps
running), we're all working toward the same goal: to build great
OpenGL
drivers and advance the state of the art for open source 3D
I'm honestly shocked to read this, Marek. We deliberately want [your]
driver to be less capable and couldn't care about less about anything
except [our] driver? This is sounding remarkably like a conspiracy
theory, and I really didn't expect that from you.
I think it takes two to tango, and
Am 25.11.2011 09:15, schrieb Jose Fonseca:
- Original Message -
While Ian and I may take a more idealist stance (favoring strict
compliance), and you perhaps a more pragmatic view (get more apps
running), we're all working toward the same goal: to build great
OpenGL drivers and
On Wed, Nov 23, 2011 at 7:25 PM, Ian Romanick i...@freedesktop.org wrote:
Let me paraphrase this a little bit in a way that I think concisely captures
the intention:
We need to work really hard to make things work on older hardware.
I don't think anyone disagrees with that. However, the
By this same logic, malloc should never return NULL because most apps can't
handle it. Instead it should mmap /dev/null and return a pointer to that.
That analogy isn't as far off as it may seem: in both cases the underlying
infrastructure has lied to the application that an operation
On 11/24/11 05:25, Dave Airlie wrote:
On UNIX malloc generally hasn't returned NULL since overcommit was
invented, what happens now is some time in the future
you attempt to use a page and your app dies.
s/UNIX/Linux/ - other Unixes still prefer reliability over random
OOM crashes.
--
On 11/24/2011 04:47 AM, Marek Olšák wrote:
On Wed, Nov 23, 2011 at 7:25 PM, Ian Romanick i...@freedesktop.org wrote:
Let me paraphrase this a little bit in a way that I think concisely captures
the intention:
We need to work really hard to make things work on older hardware.
I don't
On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke kenn...@whitecape.org wrote:
On 11/22/2011 07:27 PM, Marek Olšák wrote:
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick i...@freedesktop.org wrote:
All of this discussion is largely moot. The failure that you're so angry
about was caused by a
On 11/23/2011 05:42 AM, Marek Olšák wrote:
On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke kenn...@whitecape.org
wrote:
On 11/22/2011 07:27 PM, Marek Olšák wrote:
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick i...@freedesktop.org wrote:
All of this discussion is largely moot. The failure
On 11/23/2011 05:42 AM, Marek Olšák wrote:
On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunkekenn...@whitecape.org wrote:
So, again, if the interest is in making more apps succeed, we should
start with varying packing. That's useful all around, and I doubt
anyone can dispute that it's
These are different from hardware limits, because some drivers can correctly
handle higher values than they report in most cases, either due
to driver-specific compiler optimizations, or due to just how the hardware
works internally.
The problem with the linker is that it artifically reduces
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface changes:
- e.g., provide to GLSL compiler infinite/huge limits, while advertising to
the app the pipe driver ones
- or detect the wine process and advertise bigger limits in
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca jfons...@vmware.com wrote:
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface changes:
- e.g., provide to GLSL compiler infinite/huge limits, while advertising to
the app the
- Original Message -
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca jfons...@vmware.com
wrote:
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface
changes:
- e.g., provide to GLSL compiler infinite/huge
On Tue, Nov 22, 2011 at 6:04 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca jfons...@vmware.com
wrote:
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick i...@freedesktop.org wrote:
All of this discussion is largely moot. The failure that you're so angry
about was caused by a bug in the check, not by the check itself. That bug
has already been fixed (commit 151867b).
The exact same check was
On 11/22/2011 07:27 PM, Marek Olšák wrote:
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick i...@freedesktop.org wrote:
All of this discussion is largely moot. The failure that you're so angry
about was caused by a bug in the check, not by the check itself. That bug
has already been fixed
21 matches
Mail list logo
