대부분의 노트북용 그래픽의 경우 데스크탑의 그래픽 카드보다 성능이 낮습니다.

발열, 소비전력 등 때문이죠.

그래서 노트북에는 외장 그래픽 독이 있습니다.

썬더볼트3 같은 인터페이스를 통해 연결하지요.

하지만 노트북 제조사별로 다르게 개발되다 보니, M사의 노트북을 사면 M사의 독만 이용할 수 있습니다.

하지만 이 표준이 제정이 된다면 A사 노트북에 M사 그래픽도 호환이 되고, 반대로 M사 노트북에 A사 그래픽도 사용이 가능해집니다.

역시. AMD는 GPU와 CPU 빼고는 다 맘에 듭니다.

출처 : http://www.bodnara.co.kr/bbs/article.html?num=129230

저의 티스토리 : http://chcola.tistory.com

저의 티스토리 구독하기 : http://chcola.tistory.com/rss

DirectX12(이하 DX12)에 대한 두 그래픽 회사의 입장이 GDC 아젠다를 통해 확인되었다고 합니다.

사실 지금껏 엔비디아 기술이 포함된 게임들 보면 충분히 예측 되었던 입장이긴 합니다.

게임웍스가 포함된 배트맨 아캄 나이트는 그래픽 품질 때문에 게임을 돌릴 수 있는 컴퓨터가 없어 리콜하기도 했었으니깐요.

AMD는 "현 세대 콘솔과 같이, 개발자들에게 하드웨어에 대한 접근 권한을 제공한다"며, 결과적으로 게임 엔진을 통해 멀티 GPU에서 큐 관리와 같은 새로운 컨셉의 작업이 가능해지고, 메모리 관리와 오브젝트 상태 등 효율적인 리소스 관리를 가능하게 할 수 있다고 했습니다.

반면 엔비디아는 개발자들은 CPU 로드 감소와 쓰레드 관리에 있어 높은 수준으로 예측이 가능해야 한다고 했습니다. 추가로 GDC 2016에서 OpenGL 코드 하에서 싱글 쓰레드 CPU의 오버헤드 감소를 위한 OpenGL AZDO 활용과 Vulkan 활용, HBAO+ Ultra, VXAO(Voxel Ambient Occlusion)에 대한 설명이 이어질 것이라고 했습니다.

AMD는 기본 기능에 집중해 추가 성능을, 엔비디아는 확보된 리소스로 그래픽 효과 개선에 집중할 것으로 예상됩니다.

엔비디아의 아이디어가 AMD의 생각보다 좋다고 생각하지만, 너무 과도하게 품질을 올리지 않았나..

Sli나 크로스 파이어 없이 게임이 돌아가질 않아요.

Sli 써보고 느낀건 CPU 사전 렌더링(AMD에선 Flip Que size)을 설정할 수 없어서 저사양 게임 할 때는 Sli  풀고서 했던 기억이 있습니다.

그래서 아무리 품질이 좋아도 단일 GPU에서 풀옵션이 돌아가는 한도 내에서 품질을 올렸으면 합니다.

안그럼 타협을 해야 하잖아요??

그것도 설정 하나 건드릴 때마다 게임 재시작 요구하면 옵션 타협은 5시간 걸리는 경우도 있단 말입니다.

GTA5... 인트로 영상 스킵도 못함

출처 : http://m.bodnara.co.kr/article/view.html?num=128459

저의 티스토리 : http://chcola.tistory.com

저의 티스토리 구독하기 : http://chcola.tistory.com/rss

기술의 원리를 설명하자면.

광통신입니다.

근데 소리는 벽을 진동시키거나 회절하여 벽 뒤에서도 통신이 가능한데, 라이파이가 되려면 빛이 통화해야겠지요

그렇다고 무엇이든 뚫는 빛인 방사선을 쏠 수도 없구요.

그래서 5G에 사용될 기술은 아니랍니다.

단순히 장애물 없는 제한된 장소에서 해킹 걱정 없이 224 Gbps를 사용할 때 필요하다는 점?

아무래도 이건 무손실 음원을 DAC와 통신하거나 애플 장치끼리의 통신에 사용될 것 같습니다.

와이파이를 대체하기는 어려워 보이네요.

아. 공유기가 천장에 있다면 장애물을 지나지 않겠군요.

쨋든 잘만 활용하면 무선 인터넷이 SSD보다 빨라지겠어요.

출처 : http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&oid=031&aid=0000366967&sid1=001

아래의 링크로 가면 와이파이 기술에 대해 알 수 있습니다.

하지만 그 기술에 대해 서술하려고 하는 것은 아닙니다.

제가 올해 22살인데요, 마지막으로 저가 항공이 아닌 비행기를 타본 것은 중학교 1학년

일본 갈 때 탔었습니다.

8년 전인 2008년이네요. 그 때도 1월에 갔었습니다.

그 때 기내에서 노트북으로 무선 인터넷 연결 했던 기억이 납니다.

JAL. Japanese Air Line.

그래서 작년에 해외 여행 간다는 친구한테 기내 와이파이에 대해 이야기 해줬습니다.

스튜어디스한테 와이파이 비밀번호 물으면 알려준다고 말했죠.

그 친구가 여행에서 돌아와서는 그런거 없었다고 했다네요.

그리고 이 뉴스를 접하고 알았습니다.

국내 항공사는 8년 전 일본 항공에서 되던게 아직 안된다는 걸.

우리 나라 항공사에도 빨리 도입 되었으면 좋겠습니다.

출처 : http://m.news.naver.com/read.nhn?mode=LSD&mid=sec&sid1=105&oid=081&aid=0002661665

저의 티스토리 : http://chcola.tistory.com

저의 티스토리 구독하기 : http://chcola.tistory.com/rss

HTML5와 같은 표준을 이용하면 웹에서 게임을 할 수가 있습니다.

컷더로프의 경우도 게임 앱을 다운 받지 않고 할 수 있죠.

게다가 개발자는 안드로이드, iOS 등등에 앱을 따로 만들 필요가 없어집니다.

특히 웹브라우저가 카메라, 자이로스코프 센서, 핀치줌 외에 여러가지 센서를 사용할 수 있습니다.

웹앱의 단점이라면 아무래도 데이터 사용이겠지요.

구글은 웹앱 성능 개선을 위해 기준을 만들었습니다.

1. 터치 입력에 대한 반응을 100ms 미만
2. 60fps
3. 1초 이하의 load time
4. 결과를 얻기 위해 기다리는 시간 50ms 미만

그런데 구글이 기준을 만들고 있는데 반해, 애플은 이러한 부분을 외면하고 있다는 내용입니다.

HTML5 웹앱의 가장 중요한 세가지 서비스워커, 바이브레이션API, CSS터치-액션 인데요,

서비스워커에 대해 애플이 지원할 생각이 없다고 답변했습니다.

서비스워커는 오프라인 상태의 기기에서도 브라우저가 사용자 측의 이벤트에 대응해 작동할 수 있도록 해주는 표준입니다.

출처 : http://www.zdnet.co.kr/news/news_view.asp?artice_id=20160104165613

저의 티스토리 : http://chcola.tistory.com

저의 티스토리 구독하기 : http://chcola.tistory.com/rss

OpenGL을 대체할 로우레벨 API 벌칸의 공식 출시가 16년이 되서야 보게 될 것 같다고 합니다.

크로노스 그룹에 따르면 벌칸 1.0 규격은 이미 확정 되었지만, 실제품에 이식을 위한 최종 피드백 단계에 있고, 관련 드라이버 제공을 위해 파트너사들과 적합성 테스트가 진행 중이라네요.

벌칸은 맨틀의 로우레벨 API를 표방했는데, 다른 점이라면 멀티 플랫폼이라는 점입니다.

안드로이드, 리눅스에도 사용 가능할 것이라고 합니다.

역시 AMD 짱짱맨.

AMD가 윈도 10 멀티 코어 최적화에도 참여했고, DX12의 로우레벨 부분도 AMD의 맨틀이 큰 영향을 주었다고 합니다.

덕분에 안드로이드 같은 모바일 기기에서도 로우레벨을 사용할 수 있겠네요.ㅎㅎ

제품 빼고 다 좋아.

!!!!!

출처 : http://www.bodnara.co.kr/bbs/article.html?num=127781

유황 화합물 배터리를 이용할 경우 현재의 리튬이온 2차전지 대비 40% 용량이 향상된 배터리를 사용할 수 있게 됩니다.

기존 리튬이온 2차전지는 리튬이온 전해액 속 이온이 양극과 음극 사이를 왕복하며 충전을 합니다. 하지만, 이 배터리는 유황 화합물로 이온을 많이 축적할 수 있을 것으로 봅니다.

하지만 재충전을 반복할 수록 유황성분이 전해액에 녹아 수명이 감소합니다.

매체는 소니가 전해액 첨가 재료를 이용해 문제를 해결했다고 전했다고 합니다.

소니는 일체형으로 예쁜 바디(?) 라인(?)을 가진 엑스페리아를 만들어낸다.

엑스페리아 디자인에 윈도폰이면.. ㅎㅎ

쨋든 일체형인만큼 수명이 중요할 것 같다. 문제는 소니는 어차피 아이폰 이상으로 배터리가 간다. 엑스페리아에서 아이폰으로 넘어오면서 보조배터리를 들고 다니기 시작했으니깐. 엑스페리아에선 용량보다 수명이 중요할 것 같으므로 리튬이 더 좋지 않을까 생각해본다.

출처 : http://www.kbench.com/?q=node/158293

이번 GPUOpen에는 제한적으로 제공되던 GPU 접근 권한과 블랙 박스 솔루션을 확대한다네요..

그리고 GPU 직접 제어와 툴, 라이브러리, SDK 등의 오픈 소스 소프트웨어 지원 내용을 포함하고 있어요.

이는 엔비디아의 게임 웍스와 유사한 프로그램이라고 하네요. 비주얼 이펙트, 드라이버 유틸리티, 트러블 슈팅 툴까지 소스가 공개된데요.

 이 모든 것은 16년 1월에 GitHub를 통해서 공개된다는 군요!!

그 부분은 잘 모르겠지만, 오픈 소스 덕분에 개발자들의 AMD GPU 활용도가 높아질 것 같아요.

게다가 HSA kernel과 runtime까지 공개되는군요.

흐음.. 드라이버 유틸리티까지??

그럼 RadeonPro 같은 소프트웨어가 많이 나올 수 있다는 의미인 것 같네요?

AMD는 프리싱크도 그렇고, 이런 오픈이 참 맘에 들어요.

암드 그래픽은 없으면서 게이밍 모니터는 죄다 AMD용.

G-Sync는 없고, FreeSync만 한가득!!

출처 : http://www.bodnara.co.kr/bbs/article.html?num=127604

방금 옵테론 관련 글 쓰면서 도대체 HSA가 무엇일까 싶으신 분들이 많은 겁니다.

HSA는 메모리 통합을 목적으로 하는 기관입니다.

CPU는 하나의 코어가 하나의 일을 하며, 쿼드코어라면 4개의 일을 동시에 할 수 있습니다.

그러나 GPU는 다릅니다. 하나의 작업을 수많은 프로세서가 나눠서 처리합니다.

그래서 CPU는 직렬 컴퓨팅이라고 할 수 있고, GPU는 병렬 컴퓨팅이라고 할 수 있습니다.

그래서 GPU는 굉장한 성능을 보여줍니다. 하지만, 이는 단일 작업에 한할 뿐입니다.

그래서 CPU와 GPU는 필요한 부분이 다르고, 하나의 작업이라도 CPU와 GPU가 필요에 따라 연산할 필요가 있습니다.

현재는 CPU가 처리하던 작업을 GPU가 하려면 시스템 메모리의 내용을 GPU 메모리로 복사해야합니다. GPU가 처리하는 것이 시간을 단축 시킬수 있음에도, 시스템 메모리에서 그래픽 메모리로 복사하는 과정을 포함시키면 GPU가 처리했을 땐 더 오래걸러서 CPU로 처리하곤 합니다. 이러다보니 시간이 걸리고 전력 소모량이 증가합니다.

HSA는 메모리가 통합되어 GPU와 CPU가 하나의 메모리를 사용합니다. 다시말해 GPU와 CPU가 얼마든지 바꾸어가며 처리할 수 있게됩니다. 소수 연산이나 몇몇은 CPU보다 GPU가 처리하는 것이 우수합니다. 퀵싱크나 엔비디아 CUDA가 나온 이유지요. HSA가 되면 영상이나 3D 같은 것들 외에도 얼마든지 GPU가 처리하고, GPU가 하던일도 언제든지 CPU가 처리할 수 있게 해줍니다. 이때 CPU와 GPU 중 무엇이 적합한지는 프로그래머가 아닌 컴퓨터가 판단합니다. 따라서 성능이 1.5배가 되기 위해 프로그램 라인수는 줄어들지요.

페이스북 서버가 HSA가 일부적용되었는데 발열, 전력 소모량도 확연히 감소하고 시간도 단축되었다고 합니다.

우리 주변에서 가장 흔히 볼수 있는 HSA 제품은 PS4입니다.
cpu는 저전력 옥타코어 정도이고 그래픽도 7970m급이지요. 그러나 메모리는 CPU와 GPU 모두 GDDR5급 8기비바이트 메모리가 장착되어있습니다.
엔하위키에 보면 그정도 성능에 1080p해상도 60프레임을 권장하는 소니가 이상하다고 씌여있는데, 모르는 소리입니다. 'CPU가 후지고 GPU도 좋은편이 아니다'라고 평가하는 것부터가 절못되었죠. PS4는 '정수연산 CPU가 옥타코어고 소수연산 CPU가 7970m급이다'라고 보는 것이 맞습니다.


현재 PC들을 보면 소수연산은 최대한 그래픽에게 맡기는 방향으로 가고 있습니다. 그렇기에 AMD CPU는 너무 앞서있다는 평가를 받지요. AMD CPU는 분명 DX9(DirectX9)를 사용하는 게임에선 저급할겁니다. 옥타코어를 사도 소수연산은 4쓰레드 밖에 없으니깐요. 그러나 dx11이나 dx12, openCL이 함께 이루어진다면 CPU는 소수연산은 하지 않게 될겁니다. 그렇다면 소수연산을 줄여서 정수연산을 8코어 16코어로 늘리는 편이 이득이지요.

그래서 인텔은 아무리 소수연산이 좋아도 openCL 벤치마킹에선 쿼드코어고 AMD는 300개 정도의 코어를 가졌기 때문에 그렇게 큰 결과의  차이가 발생했던 것입니다.

저의 티스토리 : http://chcola.tistory.com

저의 티스토리 구독하기 : http://chcola.tistory.com/rss