Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Did you forget a "/s" tag? Because that pretty much sounds like ten years of AMD history!


Intel can afford to throw much more money at the problem. AMD can't even get their drivers straight for years now, apart from the gaming use case. I really see a chance for Intel.


Unless things have improved recently, Intel‘s graphics drivers are not that great on Windows.

I really wish someone would give Nvidia some effective competition, but I just don’t see that being Intel.


Regarding Arc, I agree, the drivers were a nightmare at release, but I'm fairly confident that was just a very rushed release because arc was already way behind schedule, and things will get better. The old UHD i915 drivers were (are) pretty solid, let's hope that's where Arc is aimed at, plus maybe all those gaming-focused bells and whistles as an optional feature.


Not sure if this has ever improved, back in the day Intel drivers were known to lie about their OpenGL capabilities, stating supported, when the feature was actually emulated in software.


If they only say their driver supports the feature, that technically is not lying, is it?

And what do you expect the driver to say instead?

Also, for graphics cards, I expect every feature requires some work from the driver. It’s not as if OpenGL is a hardware interface.


It is, because the drivers are only supposed to tell about what is actually supported on the hardware, via the capabilities queries.

A critical feature for game engines to actually decide what features to use, otherwise instead of 60 FPS, you might get single digit FPS.


So, educate me.

https://www.saschawillems.de/creations/opengl-hardware-capab... claims:

“The “OpenGL hardware capability viewer” (short “glCapsViewer) a multi-platform client-side application that reads out all important hardware capabilities of the current OpenGL-implementation present on your system”

Reading its source (https://github.com/SaschaWillems/glCapsViewer/blob/85ee6ab68...), I get the impression it does that by calling either of:

  - glGetIntegerv
  - glGetInteger64v
  - glGetIntegeri_v
  - glGetProgramivARB
  - glGetFloatv
  - glGetString
I think https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGet.... documents all those functions.

I don’t see any occurrence of ‘hardware’ on that page. Looking at the data collected by that tool (example: http://opengl.gpuinfo.org/displayreport.php?id=10016), and checking some of the capabilities listed, I can find all I looked at on that page (https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGet....), so I don’t think that tool uses other methods to obtain information (I didn’t read its full source code, though)

Also:

1) https://registry.khronos.org/OpenGL/specs/gl/glspec46.core.p... doesn’t mention ‘capabilities’, doesn’t mention ‘hardware’ much, and even says

“While an implementation of OpenGL may be hardware dependent, the Specification is independent of any specific hardware on which it is implemented. We are concerned with the state of graphics hardware only when it corresponds precisely to GL state.”

2) https://community.khronos.org/t/determining-hardware-opengl-... asks “I am trying to find a way for my program to determine (during run time) whether the graphics card supports OpenGL hardware acceleration, and how much RAM is installed on the graphics card”

and

https://community.khronos.org/t/determining-hardware-opengl-... replies: “Sorry, there’s no way in OpenGL to do what you want. You’ll just have to trust the driver to do the right thing.”

Of course, that last reply may be incorrect, but from what I found, I think it is correct.

So, what’s going on? Is the spec unclear about the glGet functions? Am I overlooking a call that _does_ return hardware info? As I said: educate me.

(And of course, “implemented in hardware” does not guarantee anything about performance.)


That is the thing Intel drivers did not do the right thing, versus what AMD, NVidia, and all now gone 3D vendors.


Their drivers have improved enough that for the old OpenGL/DX9 games they are emulating it's able to just brute force it's way to acceptable performance since those games are really old usually.


I've had ATI/AMD cards for more years than not since 2004. And in my personal experience, I have maybe once had a driver issue on an X800. I know sometimes they struggle with new cards, but is it really still a thing?


graphics drivers are some of the most complex pieces of software running on any PC with lines of code running into millions easily. yes, driver issues are most definitely 'a thing' for all GPU manufacturers.


I don't think they meant drivers with respect to gaming, but I could of misunderstood. I think it is more in the context of GPGPU.


No even gaming I was constantly bombarded with driver crash and quitting the unsaved game




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: